Bug 971398

hi 
you've entered a bug in a component wrong this is a java library
please search the right component which generated this problem
regards

sorry - someone beat me to it - I entered ssh/sshd originally and bugzilla changed it to sslext - but it is right NOW

It works for me. Is there anything specific in the /var/log/secure file? 
Could you paste your server's /etc/ssh/sshd_config or an output of the '/usr/sbin/sshd -T' command? What specifically is your openssh version - 'rpm -q openssh{,-server}'?

Created attachment 758141 [details]
from target server

This is a plain vanilla distribution file.

Ah shoot - bugzilla lost all my other comments when I attached a file. I will learn someday. Here is the rest of what you asked for.

This machine was just built from the net install of fedora18, followed by a "yum -y update". No ssh or sshd configuration changes were made. Attached config file. I looked at all and see nothing to alarm me, but I am no expert here.

Rest follows:

[root@studentwriterscoach ray]# rpm -q openssh{,-server}
openssh-6.1p1-8.fc18.x86_64
openssh-server-6.1p1-8.fc18.x86_64

[root@studentwriterscoach ray]# /usr/sbin/sshd -T
port 22
protocol 2
addressfamily any
listenaddress 0.0.0.0:22
listenaddress [::]:22
usepam 1
serverkeybits 1024
logingracetime 120
keyregenerationinterval 3600
x11displayoffset 10
maxauthtries 6
maxsessions 10
clientaliveinterval 0
clientalivecountmax 3
permitrootlogin yes
ignorerhosts yes
ignoreuserknownhosts no
rhostsrsaauthentication no
hostbasedauthentication no
hostbasedusesnamefrompacketonly no
rsaauthentication yes
pubkeyauthentication yes
kerberosauthentication no
kerberosorlocalpasswd yes
kerberosticketcleanup yes
gssapiauthentication yes
gssapicleanupcredentials yes
gssapikeyexchange no
gssapistrictacceptorcheck yes
gssapistorecredentialsonrekey no
passwordauthentication yes
kbdinteractiveauthentication no
challengeresponseauthentication no
printmotd yes
printlastlog yes
x11forwarding yes
x11uselocalhost yes
strictmodes yes
tcpkeepalive yes
permitemptypasswords no
permituserenvironment no
uselogin no
compression delayed
gatewayports no
showpatchlevel no
usedns yes
allowtcpforwarding yes
useprivilegeseparation sandbox
kerberosusekuserok yes
pidfile /var/run/sshd.pid
xauthlocation /usr/bin/xauth
versionaddendum 
loglevel INFO
syslogfacility AUTHPRIV
authorizedkeysfile .ssh/authorized_keys
hostkey /etc/ssh/ssh_host_rsa_key
hostkey /etc/ssh/ssh_host_dsa_key
acceptenv LANG
acceptenv LC_CTYPE
acceptenv LC_NUMERIC
acceptenv LC_TIME
acceptenv LC_COLLATE
acceptenv LC_MONETARY
acceptenv LC_MESSAGES
acceptenv LC_PAPER
acceptenv LC_NAME
acceptenv LC_ADDRESS
acceptenv LC_TELEPHONE
acceptenv LC_MEASUREMENT
acceptenv LC_IDENTIFICATION
acceptenv LC_ALL
acceptenv LANGUAGE
acceptenv XMODIFIERS
authenticationmethods
subsystem sftp /usr/libexec/openssh/sftp-server
maxstartups 10:30:100
permittunnel no
ipqos lowdelay throughput
permitopen any

More information that may help:

My machine is fedora 18 patched fully, the two boxes that I am failing to connect to are also. The two that ssh works properly with are fedora 12 (scheduled to be updated in next couple weeks).
The id_rsa and id_rsa.pub files were generated on my machine using fedora 14.
So the authorized_keys files on all other boxes are "old".

I saved the current id_rsa files here and generated new ones hoping that this problem might be related to old vs new key generation, then copied to authorized_keys on one of the fedora 18 boxes. Then I re-booted here before testing the keys. It did not help at all and with the new keys in place here, I went back to "agent admitted failure ..." on the "old" machines (old authorized_keys files so OK to error).

So I restored my old id_rsa files; remote authorized_keys; and rebooted.

I am back to things working from me (fedora 18) to old fedora boxes but failing miserably with boxes that are at the same release and patch level as me.

Darn - I hoped I had it (I could live with waiting on updating to new fedora - those two boxes are less important). Of course, others would have had the problem but we would know what it was.

one more clue (perhaps) - from /var/log/messages

Jun 13 08:25:34 rainbow gnome-keyring-daemon[1576]: Gkm: unsupported key algorithm in certificate: 1.2.840.10045.2.1

Don't know if this is related or a red herring.

I'm still not able to reproduce your issue and since it seems that you are the only one with this problem, I would think that it's a configuration problem.

How does your privileges at files ~/.ssh/* look like? They should be similar to:
drwx------. test test unconfined_u:object_r:ssh_home_t:s0 .ssh/

-rw-------. test test unconfined_u:object_r:ssh_home_t:s0 authorized_keys
-rw-------. test test unconfined_u:object_r:ssh_home_t:s0 id_rsa
-rw-r--r--. test test unconfined_u:object_r:ssh_home_t:s0 id_rsa.pub


If you move your .ssh on the client and the server away, create a new ssh keypair 
and copy your the new key to the server using ssh-copy-id, will the pubkey authentication work for you? 

You could also change the LogLevel to DEBUG on the server and watch /var/log/secure log gile.

Server machine that is failing (fedora 18 x86_64):

ls -l .ssh; ls -ld .ssh
total 16
-rw-r--r--. 1 ray staff  393 Jun 12 08:07 authorized_keys
-rw-------. 1 ray staff 1679 Mar  4  2012 id_rsa
-rw-r--r--. 1 ray staff  409 Mar  4  2012 id_rsa.pub
-rw-r--r--. 1 ray staff 3202 Jun 11 15:48 known_hosts
drwxr-xr-x. 2 ray staff 4096 Jun 12 08:07 .ssh


Server machine that works fine
 (older Linux - 2.6.18-164.11.1.el5xen #1 SMP Wed Jan 6 13:43:33 EST 2010 x86_64 GNU/Linux):

ls -l .ssh; ls -ld .ssh
total 16
-rw------- 1 ray staff  393 Mar  6  2012 authorized_keys
-rw------- 1 ray staff 1675 Mar  4  2012 id_rsa
-rw-r--r-- 1 ray staff  402 Mar  4  2012 id_rsa.pub
-rw-r--r-- 1 ray staff 3665 Mar  6  2012 known_hosts
drwxr-xr-x 2 ray staff 4096 Mar  6  2012 .ssh


my client machine (also fedora 18 x86_64):
ls -l .ssh; ls -ld .ssh
total 20
-rw-r--r--. 1 ray staff  426 Mar 10  2011 config
-rw-------. 1 ray staff 1766 Feb 11  2011 id_rsa
-rw-r--r--. 1 ray staff  393 Feb 11  2011 id_rsa.pub
-rw-r--r--. 1 ray staff 5616 Jun 12 14:16 known_hosts
drwx------. 2 ray staff 4096 Jun 12 08:08 .ssh

----------------now set failing server to:
mv .ssh .ssh_old
mkdir .ssh; chmod 700 .ssh

used sftp to copy id_rsa.pub to above dir as authorized keys
 and finally:

ls -l .ssh; ls -ld .ssh
total 4
-rw-------. 1 ray staff 393 Jun 19 09:34 authorized_keys
drwx------. 2 ray staff 4096 Jun 19 09:35 .ssh

Signed on and it requested my password.

---------------

ONE more things - I now copied using ssh-copy-id after removing the above .ssh dir.

IT WORKED - god bless - I always used sftp to copy the file before and it worked.

 ls -l .ssh; ls -ld .ssh
total 4
-rw-------. 1 ray staff 393 Jun 19 09:45 authorized_keys
drwx------. 2 ray staff 4096 Jun 19 09:45 .ssh

THE MORAL OF THIS STORY IS THAT ONE MUST USE "ssh-copy-id" and not sftp to make this - heaven knows why as all looks identical and that used to work - but it is great. Sorry that I did not know about this before.