SSH-Key authentication fails
Solution 1
This will usually resolve most SSH authorized key permission issues on the server side, assuming someone didn't make additional changes to the permissions.
# paste these into an SSH session that server (probably from
# another user account or root)
# change this to YOUR username on the server.
UN=example
# paste these lines verbatim:
sudo chown $UN:$UN /home/$UN/{.,.ssh/,.ssh/authorized_keys}
sudo chmod u+rwX,go-rwX,-t /home/$UN/{.ssh/,.ssh/authorized_keys}
sudo chmod go-w /home/$UN/
(This is how Userify1 does it in the "shim" script to fix any permission issues automatically based on changes in the user's web dashboard.)
If your admin created the .ssh/ directory or .ssh/authorized_keys file as root (which is most commonly how this becomes broken), then having the file owned by another user (even if root!) isn't allowed.
Solution 2
I had the exact same problem on two servers: a Linux running Debian stretch and on a NAS (Synology DS715)
it turned out that in both cases, the home directory permissions on the server were wrong
the auth.log on the server was very helpful
Authentication refused: bad ownership or modes for directory /home/cyril
on the Linux, it had the write/group bit on (drwxrwxr--x), so I had to remove at least the write on group (chmod g-w ~/) and then it worked
on the Synology, for whatever reason, there was a sticky bit
drwx--x--x+ 4 toto users 4096 Jan 6 12:11 /var/services/homes/toto
I had to change it with
chmod -t ~/
and I could then connect without a password
Solution 3
When using CentOS 7, and I'm confident applies to other Linux OS's using sshd as well. With root access, you can determine more about why authentication may be failing. To do this:
- Enable logging for the
sshd
daemon:sudo vi /etc/ssh/sshd_config
- Under logging uncomment:
SyslogFacility AUTH LogLevel INFO
- Change
LogLevel
fromINFO
toDEBUG
- Save and exit
- Restart the SSH daemon with
sudo systemctl restart sshd
- Watch the messages file
tail -l /var/log/messages
- Using another terminal, attempt to connect with ssh
- Attempt to connect with
ssh
- Review the authentication log for the exact cause
For example, I was experiencing some of the same problems as mentioned above.
Authentication refused: bad ownership or modes for file /home/user/.ssh/authorized_keys
Using these steps I was able to confirm the problem was permissions on the authorized_keys
file. By setting chmod 644
on the authorized_keys
file of my user, the problem was fixed.
Solution 4
It looks like the permissions on your .ssh
folder didn't copy+paste correctly. Could you please add it again?
If strict mode is enabled then we have to make sure .ssh
has the correct permissions of:
-
.ssh/
should have perms0700/rwx------
-
.ssh/*.pub
files should be644/rw-r--r--
-
.ssh/*
(other files in .ssh)0600/rw-------
How do things look for you permission-wise?
Solution 5
I've had a similar problem, where the ssh connection tries key ~/.ssh/id_rsa
before unexpectedly stopping on:
debug3: receive packet: type 51
debug1: Authentications that can continue: publickey,gssapi-keyex,gssapi-with-mic,password
In my case, it was due to an old public key file lying around in the .ssh
directory:
[gitlab-runner@validation-k8s-1 ~]$ ll .ssh/id_rsa*
total 16
-rw------- 1 gitlab-runner gitlab-runner 1675 Sep 18 18:02 id_rsa --> new private key
-rw-r--r--. 1 gitlab-runner gitlab-runner 423 Jun 12 13:51 id_rsa.pub --> old public key
Moving/deleting the id_rsa.pub
from the .ssh
directory solved the problem.
From what I understand: when there is a public key present on the client-side, SSH 1st validates the private key against it. If it fails, it won't try to use the private key to connect remotely.
I sent an e-mail to the openssh mailing list: https://lists.mindrot.org/pipermail/openssh-unix-dev/2016-April/035048.html.
Related videos on Youtube
Tim
Updated on September 18, 2022Comments
-
Tim over 1 year
I'm trying to ssh into a CentOS server which I have no control over.. the admin has added my public key to the server and insists the fault lies with me but I can't figure out what is wrong.
Config in .ssh:
tim@tim-UX31A:~$ cat ~/.ssh/config User root PasswordAuthentication no IdentityFile ~/.ssh/id_rsa
Permission on my key-files:
tim@tim-UX31A:~$ ls -l ~/.ssh/id_rsa* -rw------- 1 tim tim 3326 Okt 20 17:28 /home/tim/.ssh/id_rsa -rw-r--r-- 1 tim tim 746 Okt 20 17:28 /home/tim/.ssh/id_rsa.pub
Connection log which I can't make any sense of:
tim@tim-UX31A:~$ ssh -vvv [email protected] OpenSSH_7.2p2 Ubuntu-4ubuntu2.1, OpenSSL 1.0.2g 1 Mar 2016 debug1: Reading configuration data /home/tim/.ssh/config debug1: Reading configuration data /etc/ssh/ssh_config debug1: /etc/ssh/ssh_config line 19: Applying options for * debug2: resolving "10.0.12.28" port 22 debug2: ssh_connect_direct: needpriv 0 debug1: Connecting to 10.0.12.28 [10.0.12.28] port 22. debug1: Connection established. debug1: identity file /home/tim/.ssh/id_rsa type 1 debug1: key_load_public: No such file or directory debug1: identity file /home/tim/.ssh/id_rsa-cert type -1 debug1: Enabling compatibility mode for protocol 2.0 debug1: Local version string SSH-2.0-OpenSSH_7.2p2 Ubuntu-4ubuntu2.1 debug1: Remote protocol version 2.0, remote software version OpenSSH_6.6.1 debug1: match: OpenSSH_6.6.1 pat OpenSSH_6.6.1* compat 0x04000000 debug2: fd 3 setting O_NONBLOCK debug1: Authenticating to 10.0.12.28:22 as 'root' debug3: hostkeys_foreach: reading file "/home/tim/.ssh/known_hosts" debug3: record_hostkey: found key type ECDSA in file /home/tim/.ssh/known_hosts:3 debug3: load_hostkeys: loaded 1 keys from 10.0.12.28 debug3: order_hostkeyalgs: prefer hostkeyalgs: [email protected],[email protected],[email protected],ecdsa-sha2-nistp256,ecdsa-sha2-nistp384,ecdsa-sha2-nistp521 debug3: send packet: type 20 debug1: SSH2_MSG_KEXINIT sent debug3: receive packet: type 20 debug1: SSH2_MSG_KEXINIT received debug2: local client KEXINIT proposal debug2: KEX algorithms: [email protected],ecdh-sha2-nistp256,ecdh-sha2-nistp384,ecdh-sha2-nistp521,diffie-hellman-group-exchange-sha256,diffie-hellman-group-exchange-sha1,diffie-hellman-group14-sha1,ext-info-c debug2: host key algorithms: [email protected],[email protected],[email protected],ecdsa-sha2-nistp256,ecdsa-sha2-nistp384,ecdsa-sha2-nistp521,[email protected],[email protected],ssh-ed25519,rsa-sha2-512,rsa-sha2-256,ssh-rsa debug2: ciphers ctos: [email protected],aes128-ctr,aes192-ctr,aes256-ctr,[email protected],[email protected],aes128-cbc,aes192-cbc,aes256-cbc,3des-cbc debug2: ciphers stoc: [email protected],aes128-ctr,aes192-ctr,aes256-ctr,[email protected],[email protected],aes128-cbc,aes192-cbc,aes256-cbc,3des-cbc debug2: MACs ctos: [email protected],[email protected],[email protected],[email protected],[email protected],[email protected],[email protected],hmac-sha2-256,hmac-sha2-512,hmac-sha1 debug2: MACs stoc: [email protected],[email protected],[email protected],[email protected],[email protected],[email protected],[email protected],hmac-sha2-256,hmac-sha2-512,hmac-sha1 debug2: compression ctos: none,[email protected],zlib debug2: compression stoc: none,[email protected],zlib debug2: languages ctos: debug2: languages stoc: debug2: first_kex_follows 0 debug2: reserved 0 debug2: peer server KEXINIT proposal debug2: KEX algorithms: [email protected],ecdh-sha2-nistp256,ecdh-sha2-nistp384,ecdh-sha2-nistp521,diffie-hellman-group-exchange-sha256,diffie-hellman-group-exchange-sha1,diffie-hellman-group14-sha1,diffie-hellman-group1-sha1 debug2: host key algorithms: ssh-rsa,ecdsa-sha2-nistp256 debug2: ciphers ctos: aes128-ctr,aes192-ctr,aes256-ctr,arcfour256,arcfour128,[email protected],[email protected],[email protected],aes128-cbc,3des-cbc,blowfish-cbc,cast128-cbc,aes192-cbc,aes256-cbc,arcfour,[email protected] debug2: ciphers stoc: aes128-ctr,aes192-ctr,aes256-ctr,arcfour256,arcfour128,[email protected],[email protected],[email protected],aes128-cbc,3des-cbc,blowfish-cbc,cast128-cbc,aes192-cbc,aes256-cbc,arcfour,[email protected] debug2: MACs ctos: [email protected],[email protected],[email protected],[email protected],[email protected],[email protected],[email protected],[email protected],[email protected],hmac-md5,hmac-sha1,[email protected],[email protected],hmac-sha2-256,hmac-sha2-512,hmac-ripemd160,[email protected],hmac-sha1-96,hmac-md5-96 debug2: MACs stoc: [email protected],[email protected],[email protected],[email protected],[email protected],[email protected],[email protected],[email protected],[email protected],hmac-md5,hmac-sha1,[email protected],[email protected],hmac-sha2-256,hmac-sha2-512,hmac-ripemd160,[email protected],hmac-sha1-96,hmac-md5-96 debug2: compression ctos: none,[email protected] debug2: compression stoc: none,[email protected] debug2: languages ctos: debug2: languages stoc: debug2: first_kex_follows 0 debug2: reserved 0 debug1: kex: algorithm: [email protected] debug1: kex: host key algorithm: ecdsa-sha2-nistp256 debug1: kex: server->client cipher: [email protected] MAC: <implicit> compression: none debug1: kex: client->server cipher: [email protected] MAC: <implicit> compression: none debug3: send packet: type 30 debug1: expecting SSH2_MSG_KEX_ECDH_REPLY debug3: receive packet: type 31 debug1: Server host key: debug3: hostkeys_foreach: reading file "/home/tim/.ssh/known_hosts" debug3: record_hostkey: found key type ECDSA in file /home/tim/.ssh/known_hosts:3 debug3: load_hostkeys: loaded 1 keys from 10.0.12.28 debug1: Host '10.0.12.28' is known and matches the ECDSA host key. debug1: Found key in /home/tim/.ssh/known_hosts:3 debug3: send packet: type 21 debug2: set_newkeys: mode 1 debug1: rekey after 134217728 blocks debug1: SSH2_MSG_NEWKEYS sent debug1: expecting SSH2_MSG_NEWKEYS debug3: receive packet: type 21 debug2: set_newkeys: mode 0 debug1: rekey after 134217728 blocks debug1: SSH2_MSG_NEWKEYS received debug2: key: /home/tim/.ssh/id_rsa (0x55ee619ab2b0), explicit, agent debug2: key: /home/tim/.ssh/id_rsa (0x55ee619bcfa0), agent debug2: key: tim@Tim-UX31A-Debian (0x55ee619b9370), agent debug3: send packet: type 5 debug3: receive packet: type 6 debug2: service_accept: ssh-userauth debug1: SSH2_MSG_SERVICE_ACCEPT received debug3: send packet: type 50 debug3: receive packet: type 51 debug1: Authentications that can continue: publickey,gssapi-keyex,gssapi-with-mic,password debug3: start over, passed a different list publickey,gssapi-keyex,gssapi-with-mic,password debug3: preferred gssapi-keyex,gssapi-with-mic,publickey,keyboard-interactive debug3: authmethod_lookup gssapi-keyex debug3: remaining preferred: gssapi-with-mic,publickey,keyboard-interactive debug3: authmethod_is_enabled gssapi-keyex debug1: Next authentication method: gssapi-keyex debug1: No valid Key exchange context debug2: we did not send a packet, disable method debug3: authmethod_lookup gssapi-with-mic debug3: remaining preferred: publickey,keyboard-interactive debug3: authmethod_is_enabled gssapi-with-mic debug1: Next authentication method: gssapi-with-mic debug1: Unspecified GSS failure. Minor code may provide more information No Kerberos credentials available debug1: Unspecified GSS failure. Minor code may provide more information No Kerberos credentials available debug1: Unspecified GSS failure. Minor code may provide more information debug1: Unspecified GSS failure. Minor code may provide more information No Kerberos credentials available debug2: we did not send a packet, disable method debug3: authmethod_lookup publickey debug3: remaining preferred: keyboard-interactive debug3: authmethod_is_enabled publickey debug1: Next authentication method: publickey debug1: Offering RSA public key: /home/tim/.ssh/id_rsa debug3: send_pubkey_test debug3: send packet: type 50 debug2: we sent a publickey packet, wait for reply debug3: receive packet: type 51 debug1: Authentications that can continue: publickey,gssapi-keyex,gssapi-with-mic,password debug1: Offering RSA public key: /home/tim/.ssh/id_rsa debug3: send_pubkey_test debug3: send packet: type 50 debug2: we sent a publickey packet, wait for reply debug3: receive packet: type 51 debug1: Authentications that can continue: publickey,gssapi-keyex,gssapi-with-mic,password debug1: Offering RSA public key: tim@Tim-UX31A-Debian debug3: send_pubkey_test debug3: send packet: type 50 debug2: we sent a publickey packet, wait for reply debug3: receive packet: type 51 debug1: Authentications that can continue: publickey,gssapi-keyex,gssapi-with-mic,password debug2: we did not send a packet, disable method debug1: No more authentication methods to try. Permission denied (publickey,gssapi-keyex,gssapi-with-mic,password).
-
Kyle H over 7 yearsFrom the lids, it looks like the key is sent, but no response is ever received. -Are you supposed to log in as root, or do you log in as tim and then use sudo? Sometimes ssh login as root is disabled. -What are the permissions of the .ssh directory itself? -Do you have the right server? Is dns resolving properly? -You could make the keys again, and then use ssh-copy-id to manually copy the new public key to the authorized_keys file. Just in case the key got corrupt somehow.
-
Tim over 7 yearsThanks for trying to help! permissions on my .ssh folder are: drwx------ 2 tim tim 4096 Okt 20 22:13 .ssh. Loggin in as root is correct - it actually worked a couple of weeks ago before I reformatted my computer. The admin says he has added the new keys correctly but I really don't know how it could be my fault at this point
-
Zina over 7 yearsAs @KyleH mentioned, have you tried with
ssh [email protected]
as the log mentions Kerberos the CentOS server could be Domain Integrated (AD, IPA, ...). You have to find out what user you are supposed to use. Ask the administrator. We for example are using IPA so we enable users to connect to certain servers with their IPA domain account and key pair and if necessary they can sudo. No root access :)
-
-
Tim over 7 yearsPermissions on my home folder (tim) are 755 (drwxr-xr-x) and permissions on the .ssh folder itself are 700 (drwx). id_rsa is 600 and .pub file is 644 .. :/ thanks again, hope the info helps
-
Kyle H over 7 yearsI have ssh working to many servers. My home directory is drwxr-xr-x (0755), .ssh is rwx------ (0700), inside .ssh my pub key is -rw-r--r-- (0644), and the rest in that folder are -rw------- (0600). So, your permissions are good and it should pass Strict Host checking. What is in your /etc/ssh_config file? Anything in ~/.ssh/config? I have had ssh key creation for one reason or another not work even though there were no errors. Can you try using ssh-keygen to regenerate your keys, ssh-copy-id to copy your pub key to the remote server that has password authentication turned on?
-
Tim over 7 yearsUnfortunately I have no access to the server but I will try to get the admin to copy my pub key to the server again on monday.. I copied the contents of the config files to pastebin: pastebin.com/eEaVMcvt - thanks again for your help!
-
Kyle H over 7 yearsYou're welcome. I'm happy to help! I also enjoy problem solving and especially helping others with Linux. There is one odd line in your ssh-config that could cause issues where it's at. What is the ip 10.0.12.28?
-
fatal_error over 7 years@KyleH is right.. that's almost certainly the issue. I added another answer that shows how to fix it with root access. If you control your homedir, you can possibly fix it yourself, but of course you'd have to be able to log in :)
-
fatal_error over 7 yearsTim, also just realized what @KyleH was pointing out... if you are trying to log in as root to 10.0.12.28, then that's probably the cause of your breakage (and also a net negative from a security perspective). Often /etc/ssh/sshd_config disallows root login as well. If you comment out that line, you'll log in as your regular username instead, and then you can sudo to root.
-
Charles Duffy almost 7 yearsIf this were the problem, the client wouldn't have tried to send the key to the server in the first place; the log given in the question is explicit that it does.
-
Charles Duffy almost 7 yearsFrom the log in the question, the key is loaded into the OP's agent -- if permissions were bad, they wouldn't have been able to load it (and the filesystem permissions aren't rechecked when sending an agent-based key, so that couldn't possibly be the issue).
-
fatal_error almost 7 years@CharlesDuffy perms on the server-side, not client.
-
fatal_error over 6 yearsThis corrects the server side issue. You are correct that the client side is ok.
-
Brett Zamir over 5 yearsYour answer flagged me to my different, but also user-related, case of my trying to log in when the home directory I had given was more nested than the one I was logging in with... Great to have fixed, thanks!
-
Stéphane over 5 yearsThanks for that
chmod -t
... I ended up with:admin@SYN:~$ ls -ald . .ssh .ssh/* drwxr-xr-x 6 admin users 4096 Jan 10 15:54 . drwx------ 2 admin users 4096 Jan 10 15:54 .ssh -rwx------ 1 admin users 401 Jan 10 15:54 .ssh/authorized_keys -rw------- 1 admin users 1679 Jan 10 15:49 .ssh/id_rsa -rwxr--r-- 1 admin users 396 Jan 10 15:49 .ssh/id_rsa.pub -rwx------ 1 admin users 396 Jan 10 10:04 .ssh/known_hosts
-
Daniel Harris almost 5 yearsThis finally solved my problem. Spent hours trying to figure out why my public/private keys weren't being accepted.
-
David Tonhofer over 4 yearsYeaaahhhh. SERIOUSLY! I would never have look at that.
openssh-8.0p1-5.fc30.x86_64
btw. I had the public key from the earlier server with the same name as the new one lying around,fedora@(baloo).sshkey.pub
, which goes withfedora@(baloo).sshkey
passed on the command line with the-i
option. Authentication failed with the new server key found in the newfedora@(baloo).sshkey
- an RSA key. -
zaTricky almost 4 yearsNice. Using restorecon is the right way to fix selinux-related problems. Also see serverfault.com/questions/849631/… for related troubleshooting steps
-
Riley Scott Jacob over 3 yearsUgh -- what a silly error. This fixed my issue after hours of searching, thanks.
-
szegheo over 3 years@KyleH thank you so much, this led me to success after sucking with it all the day...
-
Petr Losev almost 3 yearsthank you, nothing above but this one worked for me
-
fsbflavio over 2 yearsThis works for identifing the error, thanks. but to solve I've to set permissions as folow: #chmod g-w /home/your_user #chmod 700 /home/your_user/.ssh #chmod 600 /home/your_user/.ssh/authorized_keys as describet here: daveperrett.com/articles/2010/09/14/ssh-authentication-refused
-
chrowe over 2 yearsThis seems like more than should need to be done. What if people don't want to change the ownership and permissions for everything in their home directory?
-
PJ Brunet over 2 yearsI looked it up, packet type 51 is defined as 'SSH_MSG_USERAUTH_FAILURE' (per rfc 4250).
-
Holger Böhnke over 2 yearsI had to
chmod g-w $username
as well. Because of a mistypedrsync
command the home dir itself got group writable. That too must not be. -
fatal_error over 2 years@HolgerBöhnke great point, added that.
-
Holger Böhnke over 2 yearsNice, that looks good. One small remark, the users home usually has
755
(drwxr-xr-x
). For ssh to work it simply must not havew
for group and other. So a separate chown might be less intrusive:chmod go-w /home/$UN
. This just removes thew
from group and other, on the home dir itself. The above command quite correctly does not change the homedir itself, because there's no dot.
within the braces. If it would, it would removerx
from the homedir as well, which probably is not desired. -
fatal_error about 2 years@HolgerBöhnke another great point, added that too.
-
Muhammad Rivan Febrian about 2 yearsGreat suggestion. RedHat users can look at this file:
/var/log/secure
-
Admin almost 2 yearsI got similar error:
User xxx not allowed because shell fish does not exist
-
Admin almost 2 years+1 This simple answer did the trick in my case