|Summary:||net-misch/openssh-5.4_p1 sshd_config AuthorizedKeysFile path no longer relative to user's home|
|Product:||Gentoo Linux||Reporter:||Eric N. Vander Weele <ericvw>|
|Component:||[OLD] Core system||Assignee:||Gentoo's Team for Core System packages <base-system>|
|Severity:||minor||CC:||aidanamarks, bertrand, gentoo, notordoktor|
|Package list:||Runtime testing required:||---|
Description Eric N. Vander Weele 2010-03-11 07:05:44 UTC
It appears the behavior of the AuthorizedKeysFile option in sshd_config has changed interpreting the path value from relative to absolute. Reproducible: Always Steps to Reproduce: 1. Include ``AuthorizedKeysFile .ssh/authorized_keys'' in sshd_config 2. Reload/restart sshd 3. ssh back into box Actual Results: sshd public key authentication looks at /.ssh/authorized_keys and fails for public key authentication because the file doesn't exist. (Verified by looking at -ddd output). Expected Results: Successful public key authentication. I am not sure if this is a documentation error on openssh or bug. If it is man page documentation error, the man page should be updated with this new behavior or update the default value that is being used. Otherwise I would consider this a bug and Gentoo users should be notified of these changes in the ebuild logs.
Comment 1 Doktor Notor 2010-03-11 15:28:36 UTC
Try this instead: AuthorizedKeysFile %h/.ssh/authorized_keys And yeah, I can't see it documented anywhere. Also, this bug's severity is not minor but rather critical. If you rely on keys only, you are locked out of your boxes without console access. :-(((
Comment 2 Paul Hartman 2010-03-13 01:03:39 UTC
(In reply to comment #1) > Try this instead: AuthorizedKeysFile %h/.ssh/authorized_keys Thanks, that works for me, too. > And yeah, I can't see it documented anywhere. Also, this bug's severity is not > minor but rather critical. If you rely on keys only, you are locked out of your > boxes without console access. :-((( Yep, it's what happened to me today... luckily it's just my home PC so I only had to wait until I returned home to fix it.
Comment 3 SpanKY 2010-03-13 01:31:26 UTC
nothing indicates that it should have changed behavior. the man page is quite clear on the expected behavior: After expansion, AuthorizedKeysFile is taken to be an absolute path or one relative to the user's home directory. The default is ".ssh/authorized_keys".
Comment 4 Doktor Notor 2010-03-13 06:09:17 UTC
(In reply to comment #3) > nothing indicates that it should have changed behavior. the man page is quite > clear on the expected behavior: Yeah, as said... undocumented. I am definitely not hallucinating though: http://omgili.com/mailinglist/cygwin/cygwin/com/hn8gjjci51doughgmaneorg.html http://permalink.gmane.org/gmane.os.cygwin/116572
Comment 5 Graham Murray 2010-03-13 07:41:38 UTC
(In reply to comment #1) > > And yeah, I can't see it documented anywhere. Also, this bug's severity is not > minor but rather critical. If you rely on keys only, you are locked out of your > boxes without console access. :-((( > Only if you have uncommented the line. If you leave the AuthorizedKeyFile option commented, it still uses ~/.ssh/authorized_keys the same as previous versions.
Comment 6 Doktor Notor 2010-03-13 08:17:07 UTC
(In reply to comment #5) > If you leave the AuthorizedKeyFile option commented, it still uses > /.ssh/authorized_keys the same as previous versions. Well, that's just because the default value translates to that. If you have uncommented/customized this line, then you are screwed. So, the only reason why more people are not screaming are probably b/c - almost noone touches the default AuthorizedKeysFile configuration (or default SSH configuration in general) - some other distros ship with %h/.ssh/authorized_keys in the config file (IIRC Ubuntu does) Either way, relative path such as foo/bar definitely no longer works as expected and documented in 5.4
Comment 7 Miguel R. Caudevilla 2010-03-14 19:01:40 UTC
IMHO gentoo should apply a patch in this issue.
Comment 8 SpanKY 2010-03-23 20:03:07 UTC
wishing for a patch doesnt make one magically appear
Comment 9 Miguel R. Caudevilla 2010-03-23 20:39:16 UTC
(In reply to comment #8) > wishing for a patch doesnt make one magically appear > I'm not a developer of gentoo, it isn't my job to do it... On the other hand, I could apply a patch and make an attachment, but it wouldn't be the first time I do it and that no one applies the solution to the official tree. So I'm really sorry but neither I'm going to waste my time again, nor want to waste my time discussing about this issue...
Comment 10 SpanKY 2010-03-23 20:47:17 UTC
Gentoo isnt anyone's "job". open source moves forward because random people contribute their random time.
Comment 11 Miguel R. Caudevilla 2010-03-23 23:56:49 UTC
Then... why you bother in writing "job" between quotation marks? o_O
Comment 12 SpanKY 2010-03-29 05:16:44 UTC
if you insist on being useless, go somewhere else. we have no use for "contributions" such as yours.
Comment 13 SpanKY 2010-03-29 05:42:44 UTC
added the fix from upstream to 5.4_p1-r1. seems to work for me. http://sources.gentoo.org/net-misc/openssh/files/openssh-5.4_p1-relative-AuthorizedKeysFile.patch?rev=1.1
Comment 14 Miguel R. Caudevilla 2010-03-29 09:32:32 UTC
Oh! A patch magically appeared.... thanks!