SSHD Gives error could not open Authorized Keys, although permissions seem correct

问题:

I'm unable to login to SSH because of the following error in /var/log/secure (according to the debug logs):

Dec 19 18:01:05 hostname sshd[25119]: debug1: trying public key file /root/.ssh/authorized_keys Dec 19 18:01:05 hostname sshd[25119]: debug1: Could not open authorized keys '/root/.ssh/authorized_keys': Permission denied

I have the following permissions set on root

chmod 700 ~/.ssh chmod 600 ~/.ssh/authorized_keys chmod go-wrx ~

ls -lah gives the following output for those directories:

drwx------.   6 root root 4.0K Dec 19 17:46 root drwx------.  2 root root 4.0K Dec 19 17:41 .ssh -rw-------. 1 root root  416 Dec 19 17:12 authorized_keys

I know the key I'm using is correct, as I just setup another server with it without any problems.

I'm running: CentOS release 6.4 (Final)

I've added my sshd config in case there's something misconfigured in there that might be causing the issue:

#       $OpenBSD: sshd_config,v 1.80 2008/07/02 02:24:18 djm Exp $  # This is the sshd server system-wide configuration file.  See # sshd_config(5) for more information.  # This sshd was compiled with PATH=/usr/local/bin:/bin:/usr/bin  # The strategy used for options in the default sshd_config shipped with # OpenSSH is to specify options with their default value where # possible, but leave them commented.  Uncommented options change a # default value.  #Port 22 #AddressFamily any #ListenAddress 0.0.0.0 #ListenAddress ::  # Disable legacy (protocol version 1) support in the server for new # installations. In future the default will change to require explicit # activation of protocol 1 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 DEBUG  # Authentication:  #LoginGraceTime 2m PermitRootLogin yes StrictModes no #MaxAuthTries 6 #MaxSessions 10  RSAAuthentication yes PubkeyAuthentication yes AuthorizedKeysFile      .ssh/authorized_keys #AuthorizedKeysCommand none #AuthorizedKeysCommandRunAs nobody  # 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 #KerberosUseKuserok yes  # GSSAPI options #GSSAPIAuthentication no GSSAPIAuthentication yes #GSSAPICleanupCredentials yes GSSAPICleanupCredentials yes #GSSAPIStrictAcceptorCheck yes #GSSAPIKeyExchange no  # Set this to 'yes' to enable PAM authentication, account processing, # and session processing. If this is enabled, PAM authentication will # be allowed through the ChallengeResponseAuthentication and # PasswordAuthentication.  Depending on your PAM configuration, # PAM authentication via ChallengeResponseAuthentication may bypass # the setting of "PermitRootLogin without-password". # If you just want the PAM account and session checks to run without # PAM authentication, then enable this but set PasswordAuthentication # and ChallengeResponseAuthentication to 'no'. #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 AcceptEnv XMODIFIERS  #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 no #PidFile /var/run/sshd.pid #MaxStartups 10:30:100 #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

Any ideas would be much appreciated.

回答1:

If the permissions are correct, SELinux might still be preventing sshd from opening the file.

Try fixing the labels inside the .ssh directory (and maybe $HOME):

restorecon -FRvv ~/.ssh

(I'm intentionally not suggesting disabling SELinux or setting it to the permissive mode.)

回答2:

I was struggling to use key authentication as well.

Could not open authorized keys '/home/myUserName/.ssh/authorized_keys2': Permission denied

Had checked all the above things when I ended up here (first link on google). I realize that this is an old post but I will add it here in case somebody else has the same problem as me and end up here.

I had owner of the authorized_keys file to "root", so changing it with:

chown myUserName authorized_keys2

Solved it for me.

回答3:

A couple ideas to check:

• Can you cat authorized_keys? What does the file look like?
• Is your sshd configured to allow root login? This is generally frowned upon,
• Are you doing it as root or as a sudoer?

回答4:

1. Don't do chmod on ~/.ssh/.... Try to write the exact path: /root/.ssh/..., since sometimes (when using su etc), the ~ can be setup incorrectly. Check and post the permissions again for the full path without using ~ in the command.

2. Once you are absolutely sure the permissions are OK, check if your sshd is actually running under user root: ps -A u | grep sshd.

回答5:

A couple of things to double-check:

1. Are you sure you copied the PUBLIC key to the authorized_keys, not the private key? :-)
2. Do cat -tv authorized_keys. Any ^M characters at the end of each line? Do a dos2unix on authorized_keys
3. Did you restart the ssh daemon after making configuration changes?

回答6:

I encountered this same issue and got it solved by changing both .ssh and authorized_keys's owner at the same time: chown MyUsername:Myusername .ssh chown MyUsername:Myusername .ssh/authorized_keys

Thanks to @niclaslindgren.

And BTW, it's no matter with whether there is ^M in authorized_keys or not, I had tested and proved it, it works with both the ways

回答7:

In case if SELinux enabled:

$ getenforce Enforcing

to temporary enable pub-key ssl login for nonstandard user home directory location run:

$ sudo chcon -t ssh_home_t /srv/jenkins/.ssh/authorized_keys /srv/jenkins/.ssh  $ ls -ldZ /srv/jenkins/.ssh/authorized_keys /srv/jenkins/.ssh/ drwxr-xr-x. jenkins jenkins system_u:object_r:ssh_home_t:s0  /srv/jenkins/.ssh/ -rw-r--r--. jenkins jenkins system_u:object_r:ssh_home_t:s0  /srv/jenkins/.ssh/authorized_keys

See https://linux.die.net/man/8/ssh_selinux for the details.

To make SELinux settings permanent run:

$ sudo semanage fcontext -a -t ssh_home_t /srv/jenkins/.ssh/authorized_keys $ sudo semanage fcontext -a -t ssh_home_t /srv/jenkins/.ssh $ sudo restorecon -R -v /srv/jenkins/.ssh/

You hit this if you on modern RHEL, Oracle Linux, CentOS.

转载请标明出处:SSHD Gives error could not open Authorized Keys, although permissions seem correct

文章来源: SSHD Gives error could not open Authorized Keys, although permissions seem correct