From Bugzilla Helper: User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.7.3) Gecko/20040910 Description of problem: In attempting to configure netdump, I noticed that (even after doing "service netdump propagate") when starting netdump, ssh asked for user netdump@netdumpserver's password. While the system was booting this, of course, fails so the service fails to start. :-( After some research (more than I'd like to admit), I discovered that if I, on the netdump server, renamed "/var/crash/.ssh/authorized_keys2" to "/var/crash/.ssh/authorized_keys" then ssh would accept sessions based just on the public key. My guess is that the "propagate" option needs to be updated to put the client's public key in "authorized_keys" instead of "authorized_keys2". Version-Release number of selected component (if applicable): netdump-0.7.7-2 and openssh-3.6.1p2-18 How reproducible: Always Steps to Reproduce: 1. configure netdump using the instructions on http://www.redhat.com/support/wpapers/redhat/netdump/index.html 2. note that when starting the client (service netdump start) it asks for user netdump's password again (first sign of trouble) 3. when booting note that netdump fails to start due to lack of password Actual Results: After a reboot, netdump didn't start because a password was required Expected Results: ssh should not have prompted for password, netdump should have started Additional info:
Jeff, can you explain this?
Note that openssh-3.6.1p2-18 was the original RHEL3 version, although it's been superceded in RHEL3-U2, U4, U4 and will be again in U6. But since nobody on the planet has ever reported this kind of problem, I don't have a clue...
3.0E openssh-3.6.1p2-18 3.0E-U2 openssh-3.6.1p2-33.30.1 3.0E-U4 openssh-3.6.1p2-33.30.3 3.0E-U5 openssh-3.6.1p2-33.30.4 3.0E-U6 openssh-3.6.1p2-33.30.6 (proposed)
So I guess you're thinking it's an openssh problem? I upgraded to: openssh-3.6.1p2-33.30.4 and I still see the issue: authorized_keys2 is not taken into account, only authorized_keys Note that the ssh man page says nothing about authorized_keys2 (only authorized_keys).
authorized_keys2 has been deprecated since the release of 3.0. However, the file should still be read by openssh. If you could *downgrade* your openssh package, and try with that, I'd appreciate it. If that fixes the problem, we'll file a regression against openssh. This is not the sort of thing that should change in an update release. Thanks for your patience on this.
Dave reminded me that the original report was against the 3.6.1p2-18. Please, give us the version of openssh on the server side, as that is what matters in this case.
The 2 machines (client and server) always have the same version of everything on them--they live their lives as a "mated pair." (When I upgraded the openssh as noted above, I did them both at the same time.) Do you (still) want me to try an older version (of openssh)? If so, any particular one?
No need to downgrade. I'll note that we've never heard of this problem before, so I'm inclined to believe it is specific to your environment. Do you do any special sshd configuration on your server? Could you attach your server's /etc/ssh/sshd_config file, please? Also attach the client's /etc/ssh/ssh_config file. Thanks.
Created attachment 118124 [details] my sshd_config Hmm, this file appears to be a mess. I didn't change it but maybe it was modified before I got there. (I'm not sure how to get a binary RPM for AS3 so I don't know how to check what the file originally looked like.) I note that it says: AuthorizedKeysFile .ssh/authorized_keys but if I comment that out I still get the same behavior. Predictably, if I change it to "authorized_keys2" then it'll use that file but not "authorized_keys". (But that doesn't seem right since, well, that file's not even documented.)
BTW, how do I change the state of this bug out of NEEDINFO? It looks like that happened automatically before but I don't actually have the option.
(Ah, okay then. Don't know what I did...)
Simply comment the AuthorizedKeysFile line out. If you set it explicitly, it won't look for authorized_keys2. This should resolve the problem, as I was able to reproduce the problem in a test environment. Please update the bug when you have test results. Thanks!
Well, I have a system with: openssh-server-3.6.1p2-33.30.6 and the AuthorizedKeysFile line is commented out and both files (authorized_keys and authorized_keys2) are read. I see (based on my older comments) that previously this didn't work so maybe the .6 update fixed it? Or maybe I forgot to restart sshd when I tried that before... Ergh, hope not. Anyway, if sshd_config defaults to having that line commented out, I'm okay with closing the bug. (Though since the "authorized_keys2" file is deprecated, shouldn't netdump use the non-deprecated file?)
I just checked the package, and it does have the AuthorizedKeysFile line commented out by default. Moving forward, netdump is being phased out in favor of kdump. As such, it isn't high priority to change the behaviour at this time.