Bug 166715 - netdump propogate puts public key in authorized_keys2 file instead of authorized_keys (starting netdump requires password)
netdump propogate puts public key in authorized_keys2 file instead of authori...
Product: Red Hat Enterprise Linux 3
Classification: Red Hat
Component: netdump (Show other bugs)
i386 Linux
medium Severity medium
: ---
: ---
Assigned To: Jeffrey Moyer
Depends On:
  Show dependency treegraph
Reported: 2005-08-24 16:56 EDT by Jeff Morriss
Modified: 2007-11-30 17:07 EST (History)
1 user (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Last Closed: 2006-04-26 14:58:03 EDT
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---

Attachments (Terms of Use)
my sshd_config (2.41 KB, text/plain)
2005-08-25 17:16 EDT, Jeff Morriss
no flags Details

  None (edit)
Description Jeff Morriss 2005-08-24 16:56:56 EDT
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:

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:
Comment 1 Dave Anderson 2005-08-24 17:20:11 EDT

Jeff, can you explain this?

Comment 2 Dave Anderson 2005-08-24 17:26:24 EDT

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...
Comment 3 Dave Anderson 2005-08-24 17:30:15 EDT
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)
Comment 4 Jeff Morriss 2005-08-25 08:45:50 EDT
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
Comment 5 Jeffrey Moyer 2005-08-25 09:02:07 EDT
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.
Comment 7 Jeffrey Moyer 2005-08-25 09:12:39 EDT
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.
Comment 8 Jeff Morriss 2005-08-25 11:48:28 EDT
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?
Comment 9 Jeffrey Moyer 2005-08-25 11:54:22 EDT
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.

Comment 10 Jeff Morriss 2005-08-25 17:16:33 EDT
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.)
Comment 11 Jeff Morriss 2005-09-07 11:59:37 EDT
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.
Comment 12 Jeff Morriss 2005-09-07 12:20:17 EDT
(Ah, okay then.  Don't know what I did...)
Comment 13 Jeffrey Moyer 2006-04-17 15:05:49 EDT
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.

Comment 14 Jeff Morriss 2006-04-24 04:17:26 EDT
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?)
Comment 15 Jeffrey Moyer 2006-04-26 14:58:03 EDT
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.

Note You need to log in before you can comment on or make changes to this bug.