Red Hat Bugzilla – Full Text Bug Listing
|Summary:||ssh logins via authorized_keys2 using both rsa and dsa public keys generated by ssh-keygen fail to auto authenticate|
|Product:||[Fedora] Fedora||Reporter:||sal <sal2>|
|Component:||openssh||Assignee:||Nalin Dahyabhai <nalin>|
|Status:||CLOSED NOTABUG||QA Contact:||Brian Brock <bbrock>|
|Fixed In Version:||Doc Type:||Bug Fix|
|Doc Text:||Story Points:||---|
|Last Closed:||2004-03-05 15:54:53 EST||Type:||---|
|oVirt Team:||---||RHEL 7.3 requirements from Atomic Host:|
Description sal 2004-03-04 23:08:23 EST
From Bugzilla Helper: User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.6) Gecko/20040113 Description of problem: On a server running fedora core 1 I type in the following commands which have always worked fine in the past (IP numbers changed): [root@local /]#ssh-keygen -t dsa -f ~/.ssh/id_dsa [root@local /]#scp ~/.ssh/id_dsa.pub firstname.lastname@example.org:~/.ssh/ [root@local /]#ssh email@example.com [root@remote /]#cat /root/.ssh/id_dsa.pub >> /root/.ssh/authorized_keys2 However, on side by side tests, when the remote machine is running redhat9 everythings works fine and I can ssh from the source machine into the destination server without supplying a password. However, whenever the destination server is running Fedora Core 1, I am still prompted for a password. I've tried this on 8 different destination servers, and the only time I have problems is when the destination server is running Fedora Core 1. I've gone through /etc/ssh/sshd_config thouroghly, and found nothing odd. Out of desperation, I've tried using rsa keys along with the dsa keys in both the authorized_keys and authorized_keys files. Any ideas? Version-Release number of selected component (if applicable): How reproducible: Always Steps to Reproduce: 1.[root@local /]#ssh-keygen -t dsa -f ~/.ssh/id_dsa 2.[root@local /]#scp ~/.ssh/id_dsa.pub firstname.lastname@example.org:~/.ssh/ 3.[root@local /]#ssh email@example.com 4.[root@remote /]#cat /root/.ssh/id_dsa.pub >> /root/.ssh/authorized_keys2 5. [root@remote /]#exit 6.[root@local /]#ssh firstname.lastname@example.org Actual Results: I have to supply the root password to complete the login Expected Results: I should have automatically been logged in via the dsa public key value sitting in the /root/.ssh/authorized_keys2 file Additional info:
Comment 1 Bart Martens 2004-03-05 01:33:50 EST
openssh-clients-3.6.1p2-19 openssh-3.6.1p2-19 openssh-server-3.6.1p2-19 grep authorized_keys /etc/ssh/sshd_config I don't see any reference to authorized_keys2 in man ssh. Here it works with ~/.ssh/authorized_keys so without the "2". Does this solve your problem?
Comment 2 sal 2004-03-05 15:39:33 EST
Sadely, I still have the problems... For a little more info, both the source and destination Fedora servers are running: openssh-clients-3.6.1p2-19 openssh-3.6.1p2-19 openssh-server-3.6.1p2-19 The source machine uses a public IP. All of the destination servers (one RH8, a few RH9 and the rest fedora 1) I tested with are behind a RH9 NAT firewall. Consistently, the RH9 and RH8 boxes work fine, and the Fedora core 1 machines fail to auto authenticate. Steps that I took yesterday and did not work: I've edited the /etc/ssh/sshd_config file and added authorized_keys2 instead of authorized_keys I've put the id_dsa.pub contents into both /root/.ssh/authorized_keys /root/.ssh/authorized_keys2. I've put the id_rsa.pub contents into both /root/.ssh/authorized_keys /root/.ssh/authorized_keys2. However, since I posted this perceived bug yesterday, I've done more testing and discovered that if both the Fedora machines have public IP's, then everything works as expected. Is it possible that my problem is resulting from the destination machines behind the NAT firewall not being assigned the actual IP number that the source machine is calling? Would something like a host file entry allow me to work around the unexpected behaviour of Fedora 1? (I imagine that the fedora machine's are safer as a result of this behavoir, but I still need to auto authenticate for my rsync scripts to work properly) I'll continue to look for a workaround, but I sure would appreciate it if an expert could shed some light on what might be happening in the background to cause this behaviour.
Comment 3 sal 2004-03-05 15:54:53 EST
Please close this bug. The problem was on our side. One of my coworkers has chmod'd the /root folder to another user on our fedora servers! I didn't notice this until 1pm today. I'm sorry to have wasted all your time...