Red Hat Bugzilla – Bug 166715
netdump propogate puts public key in authorized_keys2 file instead of authorized_keys (starting netdump requires password)
Last modified: 2007-11-30 17:07:08 EST
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
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
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-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
Note that the ssh man page says nothing about authorized_keys2 (only
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
Created attachment 118124 [details]
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:
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.
Well, I have a system with:
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.