Bug 117544 - ssh logins via authorized_keys2 using both rsa and dsa public keys generated by ssh-keygen fail to auto authenticate
ssh logins via authorized_keys2 using both rsa and dsa public keys generated ...
Product: Fedora
Classification: Fedora
Component: openssh (Show other bugs)
i686 Linux
medium Severity medium
: ---
: ---
Assigned To: Nalin Dahyabhai
Brian Brock
Depends On:
  Show dependency treegraph
Reported: 2004-03-04 23:08 EST by sal
Modified: 2007-11-30 17:10 EST (History)
2 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Last Closed: 2004-03-05 15:54:53 EST
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---

Attachments (Terms of Use)

  None (edit)
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)

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 root@
[root@local /]#ssh root@

[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:

Steps to Reproduce:
1.[root@local /]#ssh-keygen -t dsa -f ~/.ssh/id_dsa
2.[root@local /]#scp ~/.ssh/id_dsa.pub root@
3.[root@local /]#ssh root@
4.[root@remote /]#cat /root/.ssh/id_dsa.pub >> /root/.ssh/authorized_keys2
5. [root@remote /]#exit
6.[root@local /]#ssh root@

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

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: 

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

I've put the id_rsa.pub contents into both /root/.ssh/authorized_keys

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...

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