Bug 971398 - auto authentication using publickey silently fails
auto authentication using publickey silently fails
Product: Fedora
Classification: Fedora
Component: openssh (Show other bugs)
Unspecified Unspecified
unspecified Severity unspecified
: ---
: ---
Assigned To: Petr Lautrbach
Fedora Extras Quality Assurance
Depends On:
  Show dependency treegraph
Reported: 2013-06-06 08:32 EDT by Ray Holme
Modified: 2013-06-19 09:52 EDT (History)
5 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Last Closed: 2013-06-19 09:52:58 EDT
Type: Bug
Regression: ---
Mount Type: ---
Documentation: ---
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---

Attachments (Terms of Use)
log of patch level of all three machines, plus log of "ssh -v" where failure happens (3.00 KB, text/plain)
2013-06-06 08:32 EDT, Ray Holme
no flags Details
from target server (4.27 KB, text/plain)
2013-06-07 08:09 EDT, Ray Holme
no flags Details

  None (edit)
Description Ray Holme 2013-06-06 08:32:06 EDT
Created attachment 757652 [details]
log of patch level of all three machines, plus log of "ssh -v" where failure happens

Description of problem: using ssh from a fully patched fedora18 box to another fully patched fedora18 box fails using publickey - same scenario works fine from fedora18 ssh'ing to an older fedora release

Version-Release number of selected component (if applicable):
OpenSSH_6.1p1, OpenSSL 1.0.1e-fips 11 Feb 2013

How reproducible: totally

Steps to Reproduce:
1. set up publickey on second box, set permissions of files
2. ssh to box (or sftp)

Actual results: end up using password to get in

Expected results: normally after first time pop-up for password, login or ftp usage requires no login

Additional info: I am attaching a log from "ssh -v" from failed target and a successful target - the logs were cut down to the the immediate vicinity of the bug.
Comment 1 gil cattaneo 2013-06-06 09:38:53 EDT
you've entered a bug in a component wrong this is a java library
please search the right component which generated this problem
Comment 2 Ray Holme 2013-06-06 12:45:29 EDT
sorry - someone beat me to it - I entered ssh/sshd originally and bugzilla changed it to sslext - but it is right NOW
Comment 3 Petr Lautrbach 2013-06-07 06:30:48 EDT
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}'?
Comment 4 Ray Holme 2013-06-07 08:09:19 EDT
Created attachment 758141 [details]
from target server

This is a plain vanilla distribution file.
Comment 5 Ray Holme 2013-06-07 08:14:05 EDT
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}

[root@studentwriterscoach ray]# /usr/sbin/sshd -T
port 22
protocol 2
addressfamily any
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
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_ALL
acceptenv LANGUAGE
acceptenv XMODIFIERS
subsystem sftp /usr/libexec/openssh/sftp-server
maxstartups 10:30:100
permittunnel no
ipqos lowdelay throughput
permitopen any
Comment 6 Ray Holme 2013-06-12 08:36:47 EDT
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.
Comment 7 Ray Holme 2013-06-13 10:10:47 EDT
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.
Comment 8 Petr Lautrbach 2013-06-19 07:36:31 EDT
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.
Comment 9 Ray Holme 2013-06-19 09:52:58 EDT
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.

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