bugzilla-daemon at bugzilla.mindrot.org
2011-Oct-30 18:02 UTC
[Bug 1947] New: Log authorized_keys format issues and refuse to accept keys
https://bugzilla.mindrot.org/show_bug.cgi?id=1947 Bug #: 1947 Summary: Log authorized_keys format issues and refuse to accept keys Classification: Unclassified Product: Portable OpenSSH Version: 5.8p1 Platform: All OS/Version: All Status: NEW Severity: normal Priority: P2 Component: sshd AssignedTo: unassigned-bugs at mindrot.org ReportedBy: dave at treblig.org I was trying to add a command="blah" limit on a key in .ssh/authorized_keys for the first time in many years; and a few problems struck me: 1) When I screwed up there was no log to say that it hit a badly formatted line in authorized_keys 2) A simple error - e.g. putting a line break after the command="..." part and before the key resulted in a key with no restriction. So I suggest if you find a command="....." or other option section that should be with a key and there is no key, then it should be logged that you hit it and you should stop reading the authorized_keys file because something is wrong. Ideally you should carry on reading the authorized_keys to check its validity, even once you hit a valid entry, that way you can spot other screwups - e.g. in my case I first misread the man page to think I was supposed to put the command="..." on the following line. OK, so you're not going to be able to catch all screwups; but it should be pretty paranoid. -- Configure bugmail: https://bugzilla.mindrot.org/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are watching the assignee of the bug.
bugzilla-daemon at bugzilla.mindrot.org
2011-Dec-02 00:16 UTC
[Bug 1947] Log authorized_keys format issues and refuse to accept keys
https://bugzilla.mindrot.org/show_bug.cgi?id=1947 Damien Miller <djm at mindrot.org> changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |djm at mindrot.org --- Comment #1 from Damien Miller <djm at mindrot.org> 2011-12-02 11:16:13 EST --- It's a bit of a balance between providing safety and not locking people out of their hosts - an accidental ":wq" somewhere or a truncated key line shouldn't IMO be treated as fatal. OTOH, there should be some feedback in sshd logs about failures here. -- Configure bugmail: https://bugzilla.mindrot.org/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are watching the assignee of the bug. You are watching someone on the CC list of the bug.
bugzilla-daemon at bugzilla.mindrot.org
2011-Dec-03 18:12 UTC
[Bug 1947] Log authorized_keys format issues and refuse to accept keys
https://bugzilla.mindrot.org/show_bug.cgi?id=1947 --- Comment #2 from Dr. David Alan Gilbert <dave at treblig.org> 2011-12-04 05:12:02 EST --- I agree it's a trade off, but I think I'd like to have the choice to have a machine set up to be paranoid and make it fail with a bad line; either to fail on any problem or something like requiring every line to explicitly state anything that's allowed. I also think there may be intermediates of paranoid and permissive - e.g. maybe if you see a command="..." with no key then you could ignore the next key. It would take some thinking about though. Dave -- Configure bugmail: https://bugzilla.mindrot.org/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are watching the assignee of the bug. You are watching someone on the CC list of the bug.
Possibly Parallel Threads
- Signed bit field; int have_hotplug_status_watch:1
- Signed bit field; int have_hotplug_status_watch:1
- Signed bit field; int have_hotplug_status_watch:1
- Rsync, SSH and authorized_keys problem
- [Bug 1326] New: Allow non-public-key credentials in authorized_keys file ( Kerberos, etc.)