Bug 597621

Summary: openssh default config AuthorizedKeysFile entry considers home directory to be "/"
Product: [Fedora] Fedora Reporter: Thomas Spear <Speeddymon>
Component: opensshAssignee: Jan F. Chadima <jchadima>
Status: CLOSED DUPLICATE QA Contact: Fedora Extras Quality Assurance <extras-qa>
Severity: medium Docs Contact:
Priority: low    
Version: 13CC: Colin.Simpson, jchadima, mgrepl, tmraz
Target Milestone: ---   
Target Release: ---   
Hardware: All   
OS: Linux   
Fixed In Version: Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of: Environment:
Last Closed: 2010-05-29 18:49:05 EDT Type: ---
Regression: --- Mount Type: ---
Documentation: --- CRM:
Verified Versions: Category: ---
oVirt Team: --- RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---

Description Thomas Spear 2010-05-29 16:21:16 EDT
Description of problem:
Upon installation of openssh-server, I modified the configuration to allow authentication via public key file. The default AuthorizedKeysFile entry reads:

AuthorizedKeysFile    .ssh/authorized_keys

This worked fine in FC12 x86, but in FC13 x86_64 (clean install, not upgrade), this does not work. When password and all other authentication methods are disabled, and running sshd -d on an alternate port, I see the following on the server end when attempting to connect from a client with pubkeys:

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

After commenting the AuthorizedKeysFile entry in my sshd_config file, and restarting sshd, I am able to connect with no problem with pubkeys.

Version-Release number of selected component (if applicable):

How reproducible:

Steps to Reproduce:
1. Set PasswordAuthentication no
2. Set RSAAuthentication yes
3. Set AuthorizedKeysFile .ssh/authorized_keys
4. sshd -p (insert random port number here) -d
5. Allow inbound connections on said port number in firewall (and SELinux if needed)
6. Connect from remote host with pubkeys and immediately receive disconnect
7. Check in the window where sshd was run manually and see the debug1 line pasted above among other lines in the output.
Actual results:
No supported authentication methods available

Expected results:
Connect and able to use ssh

Additional info:
Comment 1 Colin.Simpson 2010-05-29 18:17:43 EDT
Duplicate of bug #595935 ?
Comment 2 Thomas Spear 2010-05-29 18:49:05 EDT
Yes, marking as dup

*** This bug has been marked as a duplicate of bug 595935 ***