Bug 598814 - Public Key authentication on ssh fails
Public Key authentication on ssh fails
Status: CLOSED CURRENTRELEASE
Product: Red Hat Enterprise Linux 6
Classification: Red Hat
Component: openssh (Show other bugs)
6.0
All Linux
low Severity high
: rc
: ---
Assigned To: Jan F. Chadima
Miroslav Vadkerti
:
Depends On: 595935
Blocks:
  Show dependency treegraph
 
Reported: 2010-06-02 01:30 EDT by Jan F. Chadima
Modified: 2012-10-29 03:31 EDT (History)
12 users (show)

See Also:
Fixed In Version: openssh-5.3p1-17
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of: 595935
Environment:
Last Closed: 2010-11-10 16:17:02 EST
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:


Attachments (Terms of Use)

  None (edit)
Description Jan F. Chadima 2010-06-02 01:30:49 EDT
+++ This bug was initially created as a clone of Bug #595935 +++

Description of problem: I've setup (RSA)public key authentication via SSH for Fedora 12. When I upgraded to 13, Fedora refused to accept public key authentication and instead forced me to use password authentication which I usually turn off.


Version-Release number of selected component (if applicable):
OpenSSH 5.4p1 OpenSSL 1.0.0-fips 29 March 2010

How reproducible:
It happens every time for me so far. 

Steps to Reproduce:
1. upgrade machine on which you want to login via ssh to Fedora 13
2. use ssh w/public key authentication
3.
  
Actual results: asks me for password, if I disable password authentication it won't let me login via ssh


Expected results: should bypass asking for password and let me login


Additional info: I checked the permissions are 700 on my ~/.ssh directory, my authorized_keys2 is as expected, sshd_config reflects the proper authorized_keys2 file( ".ssh/authorized_keys2"). Running ssh -v user@host only tells me that ssh has run out of authorization options and if PasswordAuthentication is set to "yes", it will then ask me for a password, if not it fails with "Permission denied (publickey)."

--- Additional comment from jchadima@redhat.com on 2010-05-26 02:16:02 EDT ---

may you paste here the your sshd_config and the ssh -v and sshd -v outputs?

--- Additional comment from tmraz@redhat.com on 2010-05-26 02:40:58 EDT ---

Also please try to run restorecon -r -v -F as root on the .ssh directory.

--- Additional comment from meme23@ehrichweiss.com on 2010-05-26 09:41:47 EDT ---

sshd_config:


#Port 22
#AddressFamily any
#ListenAddress 0.0.0.0
#ListenAddress ::

Protocol 2

# HostKey for protocol version 1
#HostKey /etc/ssh/ssh_host_key
# HostKeys for protocol version 2
#HostKey /etc/ssh/ssh_host_rsa_key
#HostKey /etc/ssh/ssh_host_dsa_key

# Lifetime and size of ephemeral version 1 server key
#KeyRegenerationInterval 1h
#ServerKeyBits 1024

# Logging
# obsoletes QuietMode and FascistLogging
#SyslogFacility AUTH
SyslogFacility AUTHPRIV
#LogLevel INFO

# Authentication:

#LoginGraceTime 2m
#PermitRootLogin yes
#StrictModes yes
#MaxAuthTries 6
#MaxSessions 10

#RSAAuthentication yes
PubkeyAuthentication yes
AuthorizedKeysFile	.ssh/authorized_keys2

# For this to work you will also need host keys in /etc/ssh/ssh_known_hosts
#RhostsRSAAuthentication no
# similar for protocol version 2
#HostbasedAuthentication no
# Change to yes if you don't trust ~/.ssh/known_hosts for
# RhostsRSAAuthentication and HostbasedAuthentication
#IgnoreUserKnownHosts no
# Don't read the user's ~/.rhosts and ~/.shosts files
#IgnoreRhosts yes

# To disable tunneled clear text passwords, change to no here!
#PasswordAuthentication yes
#PermitEmptyPasswords no
PasswordAuthentication yes

# Change to no to disable s/key passwords
#ChallengeResponseAuthentication yes
ChallengeResponseAuthentication no

# Kerberos options
#KerberosAuthentication no
#KerberosOrLocalPasswd yes
#KerberosTicketCleanup yes
#KerberosGetAFSToken no

# GSSAPI options
#GSSAPIAuthentication no
#GSSAPIAuthentication yes
#GSSAPICleanupCredentials yes
#GSSAPICleanupCredentials yes


UsePAM no
#UsePAM yes

# Accept locale-related environment variables
AcceptEnv LANG LC_CTYPE LC_NUMERIC LC_TIME LC_COLLATE LC_MONETARY LC_MESSAGES
AcceptEnv LC_PAPER LC_NAME LC_ADDRESS LC_TELEPHONE LC_MEASUREMENT
AcceptEnv LC_IDENTIFICATION LC_ALL LANGUAGE
 
#AllowAgentForwarding yes
#AllowTcpForwarding yes
#GatewayPorts no
#X11Forwarding no
X11Forwarding yes
#X11DisplayOffset 10
#X11UseLocalhost yes
#PrintMotd yes
#PrintLastLog yes
#TCPKeepAlive yes
#UseLogin no
#UsePrivilegeSeparation yes
#PermitUserEnvironment no
#Compression delayed
#ClientAliveInterval 0
#ClientAliveCountMax 3
#ShowPatchLevel no
#UseDNS yes
#PidFile /var/run/sshd.pid
#MaxStartups 10
#PermitTunnel no
#ChrootDirectory none

# no default banner path
#Banner none

# override default of no subsystems
Subsystem	sftp	/usr/libexec/openssh/sftp-server

# Example of overriding settings on a per-user basis
#Match User anoncvs
#	X11Forwarding no
#	AllowTcpForwarding no
#	ForceCommand cvs server

--- Additional comment from meme23@ehrichweiss.com on 2010-05-26 09:49:49 EDT ---

Re: ssh -v and sshd -v, I'm assuming you're talking about running them on the affected host but I would think you'd be more interested in ssh -v being run on my client machine as I connect to the affected host, if you need that, I'll include it at the very bottom..

ssh -v:
OpenSSH_5.4p1, OpenSSL 1.0.0-fips 29 Mar 2010

sshd -v:
OpenSSH_5.4p1, OpenSSL 1.0.0-fips 29 Mar 2010

ssh -v user@host:(note, I have password authentication turned on right now)

OpenSSH_5.3p1, OpenSSL 1.0.0-fips-beta4 10 Nov 2009
debug1: Reading configuration data /etc/ssh/ssh_config
debug1: Applying options for *
debug1: Connecting to x.x.x.x [x.x.x.x] port 22.
debug1: Connection established.
debug1: identity file /home/user/.ssh/identity type -1
debug1: identity file /home/user/.ssh/id_rsa type 1
debug1: identity file /home/user/.ssh/id_dsa type -1
debug1: Remote protocol version 2.0, remote software version OpenSSH_5.4
debug1: match: OpenSSH_5.4 pat OpenSSH*
debug1: Enabling compatibility mode for protocol 2.0
debug1: Local version string SSH-2.0-OpenSSH_5.3
debug1: SSH2_MSG_KEXINIT sent
debug1: SSH2_MSG_KEXINIT received
debug1: kex: server->client aes128-ctr hmac-md5 none
debug1: kex: client->server aes128-ctr hmac-md5 none
debug1: SSH2_MSG_KEX_DH_GEX_REQUEST(1024<1024<8192) sent
debug1: expecting SSH2_MSG_KEX_DH_GEX_GROUP
debug1: SSH2_MSG_KEX_DH_GEX_INIT sent
debug1: expecting SSH2_MSG_KEX_DH_GEX_REPLY
debug1: Host 'x.x.x.x' is known and matches the RSA host key.
debug1: Found key in /home/user/.ssh/known_hosts:17
debug1: ssh_rsa_verify: signature correct
debug1: SSH2_MSG_NEWKEYS sent
debug1: expecting SSH2_MSG_NEWKEYS
debug1: SSH2_MSG_NEWKEYS received
debug1: SSH2_MSG_SERVICE_REQUEST sent
debug1: SSH2_MSG_SERVICE_ACCEPT received
debug1: Authentications that can continue: publickey,password
debug1: Next authentication method: publickey
debug1: Offering public key: /home/user/.ssh/id_rsa
debug1: Authentications that can continue: publickey,password
debug1: Trying private key: /home/user/.ssh/identity
debug1: Trying private key: /home/user/.ssh/id_dsa
debug1: Next authentication method: password
user@x.x.x.x's password:
debug1: Authentication succeeded (password).
debug1: channel 0: new [client-session]
debug1: Requesting no-more-sessions@openssh.com
debug1: Entering interactive session.
debug1: Sending environment.
debug1: Sending env XMODIFIERS = @im=none
debug1: Sending env LANG = en_US.UTF-8
.............

--- Additional comment from meme23@ehrichweiss.com on 2010-05-26 09:53:12 EDT ---

OH, and 'restorecon -r -v -F' seemed to have no effect. I'm using SELinux but only in permissive mode right now since I'm not an expert at its use at the moment.

--- Additional comment from jchadima@redhat.com on 2010-05-26 10:33:15 EDT ---

Can you provide sshd -v -v -v on the server please?

--- Additional comment from meme23@ehrichweiss.com on 2010-05-26 11:49:50 EDT ---

Jan, sshd -v -v -v gives the same output as ssh -v..
"OpenSSH_5.4p1, OpenSSL 1.0.0-fips 29 Mar 2010"

--- Additional comment from curriegrad2004@gmail.com on 2010-05-27 00:19:58 EDT ---

I am experiencing the same problem here too. What is the ETA on the fix for this issue?

--- Additional comment from tmraz@redhat.com on 2010-05-27 02:41:27 EDT ---

You have to stop the sshd on the server and run:
/usr/sbin/sshd -ddd and then try to connect to the server to attempt the publickey authentication.
Then attach the output produced by sshd.

--- Additional comment from curriegrad2004@gmail.com on 2010-05-27 03:08:00 EDT ---

Found out that sshd is looking for authorized keys in '//.ssh/'.

I can't attach any output as I can't seem to find a way to get sshd to log to a file.

--- Additional comment from curriegrad2004@gmail.com on 2010-05-27 03:14:57 EDT ---

Managed to dump an output of this issue:

debug2: load_server_config: filename /etc/ssh/sshd_config
debug2: load_server_config: done config len = 634
debug2: parse_server_config: config /etc/ssh/sshd_config len 634
debug3: /etc/ssh/sshd_config:34 setting SyslogFacility AUTHPRIV
debug3: /etc/ssh/sshd_config:45 setting RSAAuthentication yes
debug3: /etc/ssh/sshd_config:46 setting PubkeyAuthentication yes
debug3: /etc/ssh/sshd_config:47 setting AuthorizedKeysFile .ssh/authorized_keys
debug3: /etc/ssh/sshd_config:64 setting PasswordAuthentication yes
debug3: /etc/ssh/sshd_config:68 setting ChallengeResponseAuthentication no
debug3: /etc/ssh/sshd_config:78 setting GSSAPIAuthentication yes
debug3: /etc/ssh/sshd_config:80 setting GSSAPICleanupCredentials yes
debug3: /etc/ssh/sshd_config:94 setting UsePAM yes
debug3: /etc/ssh/sshd_config:97 setting AcceptEnv LANG LC_CTYPE LC_NUMERIC LC_TIME LC_COLLATE LC_MONETARY LC_MESSAGES
debug3: /etc/ssh/sshd_config:98 setting AcceptEnv LC_PAPER LC_NAME LC_ADDRESS LC_TELEPHONE LC_MEASUREMENT
debug3: /etc/ssh/sshd_config:99 setting AcceptEnv LC_IDENTIFICATION LC_ALL LANGUAGE
debug3: /etc/ssh/sshd_config:100 setting AcceptEnv XMODIFIERS
debug3: /etc/ssh/sshd_config:106 setting X11Forwarding yes
debug3: /etc/ssh/sshd_config:129 setting Subsystem sftp /usr/libexec/openssh/sftp-server
debug1: sshd version OpenSSH_5.4p1
debug3: Not a RSA1 key file /etc/ssh/ssh_host_rsa_key.
debug1: read PEM private key done: type RSA
debug1: private host key: #0 type 1 RSA
debug3: Not a RSA1 key file /etc/ssh/ssh_host_dsa_key.
debug1: read PEM private key done: type DSA
debug1: private host key: #1 type 2 DSA
debug1: rexec_argv[0]='/usr/sbin/sshd'
debug1: rexec_argv[1]='-ddd'
debug3: oom_adjust_setup
Set /proc/self/oom_adj from 0 to -17
debug2: fd 3 setting O_NONBLOCK
debug1: Bind to port 22 on 0.0.0.0.
Server listening on 0.0.0.0 port 22.
debug2: fd 4 setting O_NONBLOCK
debug3: sock_set_v6only: set socket 4 IPV6_V6ONLY
debug1: Bind to port 22 on ::.
Server listening on :: port 22.
debug3: fd 5 is not O_NONBLOCK
debug1: Server will not fork when running in debugging mode.
debug3: send_rexec_state: entering fd = 8 config len 634
debug3: ssh_msg_send: type 0
debug3: send_rexec_state: done
debug1: rexec start in 5 out 5 newsock 5 pipe -1 sock 8
debug1: inetd sockets after dupping: 3, 3
Connection from 2001:470:c06d:1000:fd8e:17d:c751:8e7c port 58755
debug1: Client protocol version 2.0; client software version PuTTY_Local:_Feb__7_2009_23:49:51
debug1: no match: PuTTY_Local:_Feb__7_2009_23:49:51
debug1: Enabling compatibility mode for protocol 2.0
debug1: Local version string SSH-2.0-OpenSSH_5.4
debug2: fd 3 setting O_NONBLOCK
debug2: Network child is on pid 19201
debug3: preauth child monitor started
debug3: mm_request_receive entering
debug3: privsep user:group 74:495
debug1: permanently_set_uid: 74/495
debug1: list_hostkey_types: ssh-rsa,ssh-dss
debug1: SSH2_MSG_KEXINIT sent
debug1: SSH2_MSG_KEXINIT received
debug2: kex_parse_kexinit: diffie-hellman-group-exchange-sha256,diffie-hellman-group-exchange-sha1,diffie-hellman-group14-sha1,diffie-hellman-group1-sha1
debug2: kex_parse_kexinit: ssh-rsa,ssh-dss
debug2: kex_parse_kexinit: aes128-ctr,aes192-ctr,aes256-ctr,arcfour256,arcfour128,aes128-cbc,3des-cbc,blowfish-cbc,cast128-cbc,aes192-cbc,aes256-cbc,arcfour,rijndael-cbc@lysator.liu.se
debug2: kex_parse_kexinit: aes128-ctr,aes192-ctr,aes256-ctr,arcfour256,arcfour128,aes128-cbc,3des-cbc,blowfish-cbc,cast128-cbc,aes192-cbc,aes256-cbc,arcfour,rijndael-cbc@lysator.liu.se
debug2: kex_parse_kexinit: hmac-md5,hmac-sha1,umac-64@openssh.com,hmac-ripemd160,hmac-ripemd160@openssh.com,hmac-sha1-96,hmac-md5-96
debug2: kex_parse_kexinit: hmac-md5,hmac-sha1,umac-64@openssh.com,hmac-ripemd160,hmac-ripemd160@openssh.com,hmac-sha1-96,hmac-md5-96
debug2: kex_parse_kexinit: none,zlib@openssh.com
debug2: kex_parse_kexinit: none,zlib@openssh.com
debug2: kex_parse_kexinit:
debug2: kex_parse_kexinit:
debug2: kex_parse_kexinit: first_kex_follows 0
debug2: kex_parse_kexinit: reserved 0
debug2: kex_parse_kexinit: diffie-hellman-group-exchange-sha256,diffie-hellman-group-exchange-sha1,diffie-hellman-group14-sha1,diffie-hellman-group1-sha1
debug2: kex_parse_kexinit: ssh-rsa,ssh-dss
debug2: kex_parse_kexinit: aes256-ctr,aes256-cbc,rijndael-cbc@lysator.liu.se,aes192-ctr,aes192-cbc,aes128-ctr,aes128-cbc,blowfish-ctr,blowfish-cbc,3des-ctr,3des-cbc,arcfour256,arcfour128
debug2: kex_parse_kexinit: aes256-ctr,aes256-cbc,rijndael-cbc@lysator.liu.se,aes192-ctr,aes192-cbc,aes128-ctr,aes128-cbc,blowfish-ctr,blowfish-cbc,3des-ctr,3des-cbc,arcfour256,arcfour128
debug2: kex_parse_kexinit: hmac-sha1,hmac-sha1-96,hmac-md5
debug2: kex_parse_kexinit: hmac-sha1,hmac-sha1-96,hmac-md5
debug2: kex_parse_kexinit: none,zlib
debug2: kex_parse_kexinit: none,zlib
debug2: kex_parse_kexinit:
debug2: kex_parse_kexinit:
debug2: kex_parse_kexinit: first_kex_follows 0
debug2: kex_parse_kexinit: reserved 0
debug2: mac_setup: found hmac-sha1
debug1: kex: client->server aes256-ctr hmac-sha1 none
debug2: mac_setup: found hmac-sha1
debug1: kex: server->client aes256-ctr hmac-sha1 none
debug1: SSH2_MSG_KEX_DH_GEX_REQUEST_OLD received
debug3: mm_request_send entering: type 0
debug3: monitor_read: checking request 0
debug3: mm_answer_moduli: got parameters: 1024 4096 8192
debug3: mm_choose_dh: waiting for MONITOR_ANS_MODULI
debug3: mm_request_receive_expect entering: type 1
debug3: mm_request_receive entering
debug3: mm_request_send entering: type 1
debug3: mm_choose_dh: remaining 0
debug1: SSH2_MSG_KEX_DH_GEX_GROUP sent
debug2: monitor_read: 0 used once, disabling now
debug3: mm_request_receive entering
debug2: dh_gen_key: priv key bits set: 260/512
debug2: bits set: 2030/4096
debug1: expecting SSH2_MSG_KEX_DH_GEX_INIT
debug2: bits set: 2107/4096
debug3: mm_key_sign entering
debug3: mm_request_send entering: type 5
debug3: monitor_read: checking request 5
debug3: mm_answer_sign
debug3: mm_key_sign: waiting for MONITOR_ANS_SIGN
debug3: mm_request_receive_expect entering: type 6
debug3: mm_request_receive entering
debug3: mm_answer_sign: signature 0x18d7048(271)
debug3: mm_request_send entering: type 6
debug1: SSH2_MSG_KEX_DH_GEX_REPLY sent
debug2: kex_derive_keys
debug2: set_newkeys: mode 1
debug2: cipher_init: set keylen (16 -> 32)
debug1: SSH2_MSG_NEWKEYS sent
debug1: expecting SSH2_MSG_NEWKEYS
debug2: monitor_read: 5 used once, disabling now
debug3: mm_request_receive entering
debug2: set_newkeys: mode 0
debug2: cipher_init: set keylen (16 -> 32)
debug1: SSH2_MSG_NEWKEYS received
debug1: KEX done
debug1: userauth-request for user ircproxy service ssh-connection method none
debug1: attempt 0 failures 0
debug3: mm_getpwnamallow entering
debug3: mm_request_send entering: type 7
debug3: mm_getpwnamallow: waiting for MONITOR_ANS_PWNAM
debug3: mm_request_receive_expect entering: type 8
debug3: mm_request_receive entering
debug3: monitor_read: checking request 7
debug3: mm_answer_pwnamallow
debug3: Trying to reverse map address 2001:470:c06d:1000:fd8e:17d:c751:8e7c.
reverse mapping checking getaddrinfo for cg4l3001.smb.curriegrad2004.ca [2001:470:c06d:1000:fd8e:17d:c751:8e7c] failed - POSSIBLE BREAK-IN ATTEMPT!
debug2: parse_server_config: config reprocess config len 634
debug3: mm_answer_pwnamallow: sending MONITOR_ANS_PWNAM: 1
debug3: mm_request_send entering: type 8
debug2: input_userauth_request: setting up authctxt for ircproxy
debug3: mm_start_pam entering
debug3: mm_request_send entering: type 50
debug3: mm_inform_authserv entering
debug3: mm_request_send entering: type 3
debug3: mm_inform_authrole entering
debug3: mm_request_send entering: type 4
debug2: input_userauth_request: try method none
debug2: monitor_read: 7 used once, disabling now
debug3: mm_request_receive entering
debug3: monitor_read: checking request 50
debug1: PAM: initializing for "ircproxy"
debug1: userauth-request for user ircproxy service ssh-connection method publickey
debug1: attempt 1 failures 0
debug2: input_userauth_request: try method publickey
debug1: test whether pkalg/pkblob are acceptable
debug3: mm_key_allowed entering
debug3: mm_request_send entering: type 21
debug3: mm_key_allowed: waiting for MONITOR_ANS_KEYALLOWED
debug3: mm_request_receive_expect entering: type 22
debug3: mm_request_receive entering
debug1: PAM: setting PAM_RHOST to "2001:470:c06d:1000:fd8e:17d:c751:8e7c"
debug1: PAM: setting PAM_TTY to "ssh"
debug2: monitor_read: 50 used once, disabling now
debug3: mm_request_receive entering
debug3: monitor_read: checking request 3
debug3: mm_answer_authserv: service=ssh-connection, style=
debug2: monitor_read: 3 used once, disabling now
debug3: mm_request_receive entering
debug3: monitor_read: checking request 4
debug3: mm_answer_authrole: role=
debug2: monitor_read: 4 used once, disabling now
debug3: mm_request_receive entering
debug3: monitor_read: checking request 21
debug3: mm_answer_keyallowed entering
debug3: mm_answer_keyallowed: key_from_blob: 0x18d97f8
debug1: temporarily_use_uid: 500/500 (e=0/0)
debug1: trying public key file //.ssh/authorized_keys
debug1: restore_uid: 0/0
debug1: temporarily_use_uid: 500/500 (e=0/0)
debug1: trying public key file //.ssh/authorized_keys
debug1: restore_uid: 0/0
Failed publickey for ircproxy from 2001:470:c06d:1000:fd8e:17d:c751:8e7c port 58755 ssh2
debug3: mm_answer_keyallowed: key 0x18d97f8 is not allowed
debug3: mm_request_send entering: type 22
debug2: userauth_pubkey: authenticated 0 pkalg ssh-rsa
debug3: mm_request_receive entering

--- Additional comment from jchadima@redhat.com on 2010-05-27 04:13:02 EDT ---

The problem is with the home directory of the user with uid 500. 
debug1: trying public key file //.ssh/authorized_keys
It means that sshd supose that the home is /.
Can you check the /etc/passwd, wheather there is valid home directory.

--- Additional comment from curriegrad2004@gmail.com on 2010-05-27 04:23:28 EDT ---

There is a home directory for userid 500 on my system as per /etc/passwd:
ircproxy:x:500:500::/home/ircproxy:/bin/bash

--- Additional comment from jchadima@redhat.com on 2010-05-27 07:23:58 EDT ---

Is the home directory accessible by the user?

--- Additional comment from curriegrad2004@gmail.com on 2010-05-27 10:23:18 EDT ---

(In reply to comment #14)
> Is the home directory accessible by the user?    

Yes, the directory is definitely accessible by the user.

--- Additional comment from meme23@ehrichweiss.com on 2010-05-27 11:22:34 EDT ---

I'm clipping just the most valuable input from /usr/sbin/sshd -ddd:

debug1: trying public key file /root/.ssh/authorized_keys2
debug1: Could not open keyfile '/root/.ssh/authorized_keys2': Permission denied


This appeared after I accidentally replaced ".ssh/authorized_keys2" with "~/.ssh/authorized_keys2". I got the same output as "curriegrad" above when I used my stock sshd_config.

So upon seeing that I tried to hard code my key path in and now it works so it's got something to do with how the path is being processed as "curriegrad" had stated above.

--- Additional comment from curriegrad2004@gmail.com on 2010-05-27 14:55:42 EDT ---

As suggested by meme23, adding a ~ to the configuration where it allows pub key authentication, OpenSSH now does authenticate with the public keys stored in the authorized_keys file, but only for the root user.

I also agree with meme23 that there is a problem with the way that OpenSSH parses the filepaths.

--- Additional comment from liciofernando@gmail.com on 2010-05-28 15:50:59 EDT ---

I had the same problem and I've commented the line 
AuthorizedKeysFile     .ssh/authorized_keys
It was uncommented, now it is working. 
Anyway, it doesn't look as a normal behaviour.

--- Additional comment from curriegrad2004@gmail.com on 2010-05-28 16:54:48 EDT ---

(In reply to comment #18)
> I had the same problem and I've commented the line 
> AuthorizedKeysFile     .ssh/authorized_keys
> It was uncommented, now it is working. 
> Anyway, it doesn't look as a normal behaviour.    

Thanks for your suggestion. It seems like it's been fixed for now with that configuration change you've suggested.

--- Additional comment from csimpson@csl.co.uk on 2010-05-29 18:15:44 EDT ---

Yeah I get this too, was this behaviour expected to change between F12 and F13.

--- Additional comment from Speeddymon@gmail.com on 2010-05-29 18:49:05 EDT ---

*** Bug 597621 has been marked as a duplicate of this bug. ***

--- Additional comment from Speeddymon@gmail.com on 2010-05-29 18:51:10 EDT ---

I would say this is not expected. Every other openssh server I have ever used, including one on my arm-based terastation has AuthorizedKeysFile .ssh/authorized_keys and works fine.

On a side note, commenting the AuthorizedKeysFile entry IMO is more proper than adding ~/ to the front of the entry.

--- Additional comment from Speeddymon@gmail.com on 2010-05-29 18:57:41 EDT ---

I'd like to recommend that the regression keyword be added to this bug.

--- Additional comment from meme23@ehrichweiss.com on 2010-05-29 19:10:33 EDT ---

Thomas, the ~/ was simply me changing settings to see how they affected the behavior and I decided to check to see if that was suddenly required in this version; it was not intended as anything other than a test.

--- Additional comment from csimpson@csl.co.uk on 2010-05-30 07:44:47 EDT ---

I'd imagine the double slash // indicates a variable between the two slashes is set to null.

debug1: trying public key file //.ssh/authorized_keys

I'd guess either the function to get the user homedir isn't returning properly or the value isn't ending up in this final variable passed into the function constructing this string.

--- Additional comment from updates@fedoraproject.org on 2010-05-31 06:32:57 EDT ---

openssh-5.4p1-3.fc13 has been submitted as an update for Fedora 13.
http://admin.fedoraproject.org/updates/openssh-5.4p1-3.fc13

--- Additional comment from jchadima@redhat.com on 2010-05-31 06:34:06 EDT ---

Please test and provide feedback.

--- Additional comment from meme23@ehrichweiss.com on 2010-05-31 10:10:28 EDT ---

Didn't work here. Same behavior though I haven't checked the debug output to be certain.

--- Additional comment from updates@fedoraproject.org on 2010-05-31 14:17:26 EDT ---

openssh-5.4p1-3.fc13 has been pushed to the Fedora 13 testing repository.  If problems still persist, please make note of it in this bug report.
 If you want to test the update, you can install it with 
 su -c 'yum --enablerepo=updates-testing update openssh'.  You can provide feedback for this update here: http://admin.fedoraproject.org/updates/openssh-5.4p1-3.fc13

--- Additional comment from csimpson@csl.co.uk on 2010-05-31 19:34:41 EDT ---

openssh-5.4p1-3.fc13 now works for me.

--- Additional comment from jpirko@redhat.com on 2010-06-01 08:08:28 EDT ---

I confirm this solves the issue for me.
Comment 2 RHEL Product and Program Management 2010-06-03 05:55:20 EDT
This request was evaluated by Red Hat Product Management for inclusion in a Red
Hat Enterprise Linux major release.  Product Management has requested further
review of this request by Red Hat Engineering, for potential inclusion in a Red
Hat Enterprise Linux Major release.  This request is not yet committed for
inclusion.
Comment 4 Miroslav Vadkerti 2010-08-13 04:45:44 EDT
VERIFIED as fixed in openssh-5.3p1-19.el6:

Created RHTS test for this issue:
/CoreOS/openssh/Regression/bz598814-Public-Key-authentication-fails

::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::
:: [   LOG    ] :: Test
::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::
:: [   PASS   ] :: Running './ssh.exp'
:: [   PASS   ] :: File '/tmp/tmp.nmCYHWwhIs' should contain 'Accepted publickey'
:: [   LOG    ] :: Duration: 6s
:: [   LOG    ] :: Assertions: 2 good, 0 bad
:: [   PASS   ] :: RESULT: Test
Comment 5 releng-rhel@redhat.com 2010-11-10 16:17:02 EST
Red Hat Enterprise Linux 6.0 is now available and should resolve
the problem described in this bug report. This report is therefore being closed
with a resolution of CURRENTRELEASE. You may reopen this bug report if the
solution does not work for you.

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