Bug 595935

Summary:	Public Key authentication on ssh fails
Product:	[Fedora] Fedora	Reporter:	meme23
Component:	openssh	Assignee:	Jan F. Chadima <jchadima>
Status:	CLOSED ERRATA	QA Contact:	Fedora Extras Quality Assurance <extras-qa>
Severity:	high	Docs Contact:
Priority:	low
Version:	13	CC:	Colin.Simpson, curriegrad2004, jchadima, jpirko, liciofernando, mgrepl, Speeddymon, tmraz
Target Milestone:	---	Keywords:	Regression
Target Release:	---
Hardware:	All
OS:	Linux
Whiteboard:
Fixed In Version:	openssh-5.4p1-3.fc13	Doc Type:	Bug Fix
Doc Text:		Story Points:	---
Clone Of:
Clones:	598814 (view as bug list)		Environment:
Last Closed:	2010-06-10 19:14:08 UTC	Type:	---
Regression:	---	Mount Type:	---
Documentation:	---	CRM:
Verified Versions:		Category:	---
oVirt Team:	---	RHEL 7.3 requirements from Atomic Host:
Cloudforms Team:	---	Target Upstream Version:
Embargoed:
Bug Depends On:
Bug Blocks:	598814

Description meme23 2010-05-25 23:26:59 UTC

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

Comment 1 Jan F. Chadima 2010-05-26 06:16:02 UTC

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

Comment 2 Tomas Mraz 2010-05-26 06:40:58 UTC

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

Comment 3 meme23 2010-05-26 13:41:47 UTC

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

Comment 4 meme23 2010-05-26 13:49:49 UTC

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's password:
debug1: Authentication succeeded (password).
debug1: channel 0: new [client-session]
debug1: Requesting no-more-sessions
debug1: Entering interactive session.
debug1: Sending environment.
debug1: Sending env XMODIFIERS = @im=none
debug1: Sending env LANG = en_US.UTF-8
.............

Comment 5 meme23 2010-05-26 13:53:12 UTC

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.

Comment 6 Jan F. Chadima 2010-05-26 14:33:15 UTC

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

Comment 7 meme23 2010-05-26 15:49:50 UTC

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

Comment 8 curriegrad2004 2010-05-27 04:19:58 UTC

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

Comment 9 Tomas Mraz 2010-05-27 06:41:27 UTC

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.

Comment 10 curriegrad2004 2010-05-27 07:08:00 UTC

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.

Comment 11 curriegrad2004 2010-05-27 07:14:57 UTC

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.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.se
debug2: kex_parse_kexinit: hmac-md5,hmac-sha1,umac-64,hmac-ripemd160,hmac-ripemd160,hmac-sha1-96,hmac-md5-96
debug2: kex_parse_kexinit: hmac-md5,hmac-sha1,umac-64,hmac-ripemd160,hmac-ripemd160,hmac-sha1-96,hmac-md5-96
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: 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.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.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

Comment 12 Jan F. Chadima 2010-05-27 08:13:02 UTC

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.

Comment 13 curriegrad2004 2010-05-27 08:23:28 UTC

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

Comment 14 Jan F. Chadima 2010-05-27 11:23:58 UTC

Is the home directory accessible by the user?

Comment 15 curriegrad2004 2010-05-27 14:23:18 UTC

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

Yes, the directory is definitely accessible by the user.

Comment 16 meme23 2010-05-27 15:22:34 UTC

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.

Comment 17 curriegrad2004 2010-05-27 18:55:42 UTC

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.

Comment 18 Licio Fonseca 2010-05-28 19:50:59 UTC

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.

Comment 19 curriegrad2004 2010-05-28 20:54:48 UTC

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

Comment 20 Colin.Simpson 2010-05-29 22:15:44 UTC

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

Comment 21 Thomas Spear 2010-05-29 22:49:05 UTC

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

Comment 22 Thomas Spear 2010-05-29 22:51:10 UTC

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.

Comment 23 Thomas Spear 2010-05-29 22:57:41 UTC

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

Comment 24 meme23 2010-05-29 23:10:33 UTC

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.

Comment 25 Colin.Simpson 2010-05-30 11:44:47 UTC

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.

Comment 26 Fedora Update System 2010-05-31 10:32:57 UTC

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

Comment 27 Jan F. Chadima 2010-05-31 10:34:06 UTC

Please test and provide feedback.

Comment 28 meme23 2010-05-31 14:10:28 UTC

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

Comment 29 Fedora Update System 2010-05-31 18:17:26 UTC

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

Comment 30 Colin.Simpson 2010-05-31 23:34:41 UTC

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

Comment 31 Jiri Pirko 2010-06-01 12:08:28 UTC

I confirm this solves the issue for me.

Comment 32 meme23 2010-06-03 14:11:00 UTC

Ok, I must have needed a reboot or something because now it works fine.

Comment 33 Fedora Update System 2010-06-10 19:13:59 UTC

openssh-5.4p1-3.fc13 has been pushed to the Fedora 13 stable repository.  If problems still persist, please make note of it in this bug report.