Why am I still getting a password prompt with ssh with public key authentication?

Question

I'm working from the URL I found here:

http://web.archive.org/web/20160404025901/http://jaybyjayfresh.com/2009/02/04/logging-in-without-a-password-certificates-ssh/

My ssh client is Ubuntu 64 bit 11.10 desktop and my server is Centos 6.2 64 bit. I have followed the directions. I still get a password prompt on ssh.

I'm not sure what to do next.

output from the command you're giving to ssh with the -v flag? should be similar to this http://pastebin.com/xxe57kxg — Rob, Apr 16 '12 at 14:48
assuming you've got root access to the server, /var/log/auth.log will tell you why the login is failing. — UtahJarhead, Apr 17 '12 at 04:05
@UtahJarhead: On the CentOS server, it's likely to be in /var/log/secure. — Dennis Williamson, Oct 02 '13 at 20:36
In my case there was an incorrect entry in the hosts file so I wasn't connecting to the machine that I thought I was. — steamer25, Jan 31 '14 at 22:33
I had the same Problem. Caused by not using copy-ssh-id but vi and copy pasting the key. However (it is an ssh-rsa ley) the first s of "ssh" was not copied (likely the mouse did not select it). Took me now an hour to figure that, (facepalm) — Angel O'Sphere, Nov 03 '15 at 16:19
In my case it was the newer version of Ubuntu that didn't accept the old key type: http://superuser.com/questions/962918/pubkeyacceptedkeytypes-and-ssh-dsa-key-type — Dave, Aug 09 '16 at 14:30
@AngelO'Sphere so weird but that was my same problem too. I read your comment and thought "nah, but might as well check." Sure enough, missing the first "s" in "ssh." Thanks a lot pbcopy! — cfx, Aug 24 '16 at 19:57
@UtahJarhead My remote server makes no mention whatsoever of a remote key attempt. It just looks like a normal password login. — felwithe, Mar 14 '18 at 17:02
If you aren't using the default public keys (id_rsa etc.), then you might need to add your key (the one you have copied to the server) to the current session - ssh-add your_key_name, enter the passphrase, if any. — sandiejat, Aug 13 '18 at 13:42
Interesting, the chmod 0700 was the answer, but when I did ssh -v on the client side it didn't indicate an error related to why the key wasn't accepted, it just said it was trying password next even though my client sent a public key. How do they expect us to diagnose issues with no error information from the server? — void.pointer, Sep 19 '18 at 18:39
I don't have enough reputation to post an answer. Setting ACL for administrators_authorized_keys worked for me: PubKey Auth not working #1306 — Qwerty, Jan 31 '20 at 15:23
chmod 700 fixed it. Why would I have to do this on CentOS but not Ubuntu? — Arrow_Raider, Feb 24 '22 at 19:43
I changed mode bits to 750 for authorized_keys and it resolved the issue. — Shawyan Azdam, Nov 16 '22 at 14:54
I don't have enough rep to answer, but in my case, the problem turned out to be none described on this page. If you are using a newer ssh client (e.g. OpenSSH_8.9p1) with an older openssh server (e.g. OpenSSH_6.7p1) with an RSA keypair, try doing ssh -v user@remotehost on the client side. If it shows no mutual signature algorithm when attempting public key authentication, then the problem is likely that the server is using an older (insecure) signature algorithm that is now deprecated in the newer client. Using a ed25519 keypair at the client (instead of RSA) solves the problem. — mti2935, Nov 25 '22 at 16:33

score 862 · Accepted Answer · edited Apr 13 '17 at 12:36

862

Make sure the permissions on the ~/.ssh directory and its contents are proper. When I first set up my ssh key auth, I didn't have the ~/.ssh folder properly set up, and it yelled at me.

Your home directory ~, your ~/.ssh directory and the ~/.ssh/authorized_keys file on the remote machine must be writable only by you: rwx------ and rwxr-xr-x are fine, but rwxrwx--- is no good¹, even if you are the only user in your group (if you prefer numeric modes: 700 or 755, not 775).
If ~/.ssh or authorized_keys is a symbolic link, the canonical path (with symbolic links expanded) is checked.
Your ~/.ssh/authorized_keys file (on the remote machine) must be readable (at least 400), but you'll need it to be also writable (600) if you will add any more keys to it.
Your private key file (on the local machine) must be readable and writable only by you: rw-------, i.e. 600.
Also, if SELinux is set to enforcing, you may need to run restorecon -R -v ~/.ssh (see e.g. Ubuntu bug 965663 and Debian bug report #658675; this is patched in CentOS 6).

¹ _{Except on some distributions (Debian and derivatives) which have patched the code to allow group writability if you are the only user in your group.}

edited Apr 13 '17 at 12:36

Community

1

answered Apr 17 '12 at 15:28

Rob

9,057

1

I think if you test, you'll find that the public key file just has to be readable by the owner (400), and then only during ssh-copy-id or similar. Similarly, the authorized_keys file mode check only tests that it is not world or group writeable. It can be 400, too, if you don't need to add more keys to it, or 600 if you do. I didn't feel comfortable making factual changes to your answer beyond the one typo fix, so I'll leave the edits to you. – Warren Young Apr 17 '12 at 16:16
@WarrenYoung no matter how many times I set it up, I always forget about ssh-copy-id. I've only had to set the ~/.ssh directory before. – Rob Apr 18 '12 at 15:04
@Rob: beware that ssh-copy-id doesn't exist everywhere. Particularly on older machines, you still have to do it by hand. – Warren Young Apr 18 '12 at 17:08
55

Thank you very much for pointing out restorecon. I've been scratching my head at precisely this issue for a while now. – Richard Barrell Dec 03 '12 at 14:56
42

Oddly enough, I was having problems with an account a friend set up on his VPS getting pubkey auth working. I thought all the permissions were correct, but it's important to remember that /home/USER must be 700 or 755 – Rob Jan 25 '13 at 19:22
3

Also remember to check the owner and group settings, I used RSYNC to copy over an authorized_keys file and didn't notice that owner/group was set to 1000 instead of root! – nak Feb 16 '13 at 17:23
18

also, add -v to your ssh command to see what happens with that key. ssh -v user@host. – 300D7309EF17 Feb 17 '14 at 19:38
Using CentOS 6.4, I still had to use the restorecon command to make it work. – Wim Deblauwe Jul 14 '14 at 09:21
1

I found that the permissions on the authorized_keys file were -rw-rw-r-- and worked just fine until I added www-data into my group and then problems begun. Changing the permissions to -rw------- fixed the problem immediately. Seems the group permissions are ignored unless there is another user in your group. (Ubuntu 15.04) – Andy Fusniak May 05 '15 at 07:02
Learned so much from this very straight forward answer about user permissions and groups. Thank you. – racl101 Jun 22 '15 at 19:36
3

It may also be necessary to run restorecon -R -v ~/ to restore the context on your home directory. Some context settings on my home directory were off from the defaults and despite trying all the other suggestions here and in other posts for over two hours, I still could not connect to my server via SSH public key authentication until I thought to also run restorecon on my home ~/ directory after seeing the suggestions here to run it on ~/.ssh! Hope this helps someone else. – bluebinary Jul 09 '15 at 06:13
6

I also had to make sure my ~ itself, $HOME, was appropriately secure. It was originally 775 for some reason. chmod 700 $HOME did the trick. – Ahmed Fasih Oct 03 '15 at 13:39
28

chmod -R 700 ~/.ssh worked for me to meet the constraints of this answer (RHEL 7) – scottysseus Nov 16 '15 at 20:33
1

for me selinux was the issue. Note: to see if selinux is set use sestatus and to disable it vi /etc/selinux/config and set to disabled – Jeff Sheffield May 05 '16 at 16:25
Due to changes with ssh version 7.0, I had to add "PubkeyAcceptedKeyTypes=+ssh-dss" to my ssh server's sshd_config file. It's just a stopgap measure until I can redo my keys to be RSA keys as DSA keys will be going away. – Marnix A. van Ammers Aug 10 '16 at 00:13
1

Something that helped me: on the remote machine, needed to change ~/.ssh/authorized_key permissions to 600.
chmod 600 ~/.ssh/authorized_keys.

Originally had -rw-r--r--.
– mojo1mojo2 Aug 17 '16 at 01:51
2

restorecon didn't work for me, however this did: chcon -R unconfined_u:object_r:user_home_t:s0 /path/to/users/homedirectory/.ssh/ – phansen Nov 15 '16 at 21:49
1

Check that you haven't generated your authorized_keys on windows with CRLF line endings! – rgvcorley Nov 24 '16 at 14:35
1

I had an oddball home directory (/data/jenkins) that restorecon didn't fix since it wasn't under /home. I had to manually sudo chcon --reference=~/.ssh/authorized_keys /data/jenkins/.ssh/authorized_keys. Throwing that out there in case somebody gets that problem. – Aaron D. Marasco Jan 11 '17 at 21:08
For the newcomers; if you've done the chmod-s correctly and it still doesn't work, make sure your user also owns both ~/.ssh and ~/.ssh/authorized_keys. Check by passing for example sudo ls -l ~/.ssh and if necessary fix it with sudo chown username ~/.ssh. Fix both the directory and the file, re-do chmods, then you should be good. – Vegard May 09 '17 at 21:41
+1 for restorecon -R -v ~/.ssh in case of selinux enabled environment! – Prasanna Oct 09 '17 at 09:17
Also note that Putty's private key file format is different than SSH command's format. In my case even I had no password on my ppk file, SSH command was keep asking me its password, but then I realized that it was the ppk file I use for putty, I also had one (same private key) in SSH format and it worked. Note that I was trying to connect to Ubuntu server from Windows – endo64 Jul 18 '18 at 13:17
I understand that my private key should be readable, but why should it be writable? – Ed Peguillan III Sep 01 '18 at 17:04
I have checked all of these and it is still not working. Any idea what else I can do. (I did not do the last one because it did not seem to apply and restorecon was not installed. Should I install it. I don't know what SELinux is and I would think it is not set to enforcing but how can I check? – Kvothe Oct 10 '18 at 15:29
Also ensure that the key in ~/.ssh/authorized_keys is correct, and is on a single line as expected by ssh. – devius Dec 07 '18 at 12:06
Checked all my permissions, they look fine. Trying to use a windows openssh client to connect to a centOS host. logs here: https://gist.github.com/Groostav/0dd117be4042951ee6890325a66eddc4 Any help appreciated. – Groostav Jun 11 '19 at 21:21
Applying this fixed the issue on Fedora 30 too – djhworld Jul 26 '19 at 16:03
The problem for me was that the home directory was 770 and that resulted in that the .ssh/authorized_keys was never read, I changed it to 700 and now it works – cjohansson Oct 01 '19 at 05:26
@nak thanks for the suggestion. I aborted a usermod operation (intended to change user id so that my user accounts on all machines have the same user id) half way after realizing I needed to disable nfs first. My home directory thus was not set properly to be owned by the new user id. – John Jiang Nov 27 '19 at 19:37
I checked all of these and then after the debug method didn't find it I realized that I'd spelt the file authorised_keys - whoops. Only one accepted spelling! – GreenReaper Jan 01 '20 at 11:23
In my case, I mistakenly put the public key to the ~/.ssh/knowns_hosts file, rather than ~/.ssh/authorized_keys file. – Chris.Zou Jan 05 '20 at 01:28
Still the case in 2020 – Hildy Mar 09 '20 at 22:09
restorecon -R -v ~/.ssh works for me in Centos 8 – ikandars Aug 16 '20 at 02:55
My remote machine had incorrect permissions (777) on my home directory. Its an experimental set up. – Ankur Agarwal Sep 27 '20 at 05:57
In my case, I forgot I had limited the ssh users in /etc/ssh/sshd_config to just one user AllowUsers <username>. D'oh! – ckhatton Mar 22 '21 at 10:19
restorecon -R -v ~/.ssh worked for me in RHEL 8.4 – Nabeel Shaikh Jun 03 '22 at 10:24
I am not sure which step fixed for me, but I also did systemctl stop sshd and systemctl start sshd and after that it worked. – Debashish Sep 14 '22 at 08:09
I had the exact same issue and the solution was not found neither in accepted answer nor in its comment so here it is: in certain configuration, you are maybe required to associate the key file with the host name/ip. this is done by adding an entry to ~/.ssh/config which is approximately host 192.153.24.3 AddKeysToAgent yes IdentityFile ~/.ssh/relevant_private_key – Nir O. Jan 04 '23 at 20:01
in my case SSH version on remote was different and I was using ssh key using ed25519. Switching to new keys based on good old RSA fixed it for me. – RasikaSam Aug 09 '23 at 01:10

Tgr · Answer 2 · 2019-01-25T01:09:09.030

237

If you have root access to the server, the easy way to solve such problems is to run sshd in debug mode, by issuing something like /usr/sbin/sshd -d -p 2222 on the server (full path to sshd executable required, which sshd can help) and then connecting from the client with ssh -p 2222 user@host. This will force the SSH daemon to stay in the foreground and display debug information about every connection. Look for something like

debug1: trying public key file /path/to/home/.ssh/authorized_keys
...
Authentication refused: bad ownership or modes for directory /path/to/home/

If it isn't possible to use an alternative port, you can temporarily stop the SSH daemon and replace it with one in debug mode. Stopping the SSH daemon does not kill existing connections so it is possible to do this through a remote terminal, but somewhat risky - if the connection does get broken somehow at a time when the debug replacement is not running, you are locked out of the machine until you can restart it. The commands required:

service ssh stop
/usr/sbin/sshd -d
#...debug output...
service ssh start

(Depending on your Linux distribution, first / last line might be systemctl stop sshd.service / systemctl start sshd.service instead.)

edited Jan 25 '19 at 01:09

answered Nov 12 '12 at 07:55

Tgr

2,780

5

I just tried this... and it works fine when I'm running sshd -d, but fails once I actually run service sshd start. I'm sure it's simple, but I'm not a Linux guru. Any thoughts? – N Rohler Nov 30 '12 at 05:18
3

For reference, this post explains the SELinux solution that addressed my problem. – N Rohler Nov 30 '12 at 05:36
3

I was also having trouble with getting public key authentication to work and I was pretty sure that directory permissions wasn't the problem. After running SSH in debug mode, I quickly found out that I was wrong and permissions were the problems. – SameOldNick May 14 '14 at 05:36
4

Great advice, my user folder was with the wrong permissions. – gdfbarbosa Dec 18 '14 at 10:23
Best answer to help troubleshooting – DARK_DUCK May 24 '15 at 11:47
I had a similiar problem in Centos 7. Debug (/usr/sbin/sshd -d) shows "trying public key file /path/to/home/.ssh/authorized_keys2". The problem is in Centos7 filename has to be authorized_keys2 instead of authorized_keys. – TOUDIdel Sep 22 '15 at 13:45
2

Thank you. Of all reasons, my user wasn't allowed to log in because the shell specified by ansible (/bin/zsh) on user creation didn't exist. I never would have guessed that. – chishaku Oct 27 '15 at 00:56
My output looks normal "accepted publickey" etc, but I still get prompted https://gist.github.com/parkan/38ce87b3ad2e37694427
Bizarrely, I'm also prompted for https://the-hostname, even though it never appears as a http remote, only ssh
– Arkadiy Kukarkin Nov 12 '15 at 18:10
1

thanks a lot, this debug mode solved my case ("bad ownership"), some of my scripts mistakenly changed my /root ownership to 1000:1000, which I hadn't notice. – gpanda Dec 02 '15 at 00:28
@appleater I had tried everything but with no luck until I found this post. "Learn a man to fish...". Thanks a lot. I also had "bad ownership" in /root. – stratis Dec 14 '15 at 10:55
1

+1 because this answer teaches you how to fish vs just giving you a fish. – Gavin Miller Mar 31 '16 at 17:49
1

Is this dangerous? If you accidentally close your ssh session, you're locked out? – Hatshepsut Jun 09 '16 at 20:13
2

@Hatshepsut, yes (although you can always just restart the machine). As I said, if you can access other ports, you can just run a second SSH daemon without stopping the normal one, that's definitely less trouble. – Tgr Jun 10 '16 at 08:36
This is the right answer, it's better when you can understand the internal problem by yourself. – calbertts Apr 23 '17 at 16:15
1

@Tgr can we make /usr/sbin/sshd -d -p 2222 and ssh -p 2222 user@host the first command proposed on the answer, without service ssh stop, for greater safety? – Ciro Santilli OurBigBook.com Aug 13 '17 at 07:11
@CiroSantilli刘晓波死六四事件法轮功 done. – Tgr Aug 13 '17 at 14:10
I agree that starting another sshd instance on an alternate port is a very good troubleshooting technique. I would add that unless run with root permissions, this sshd will likely fail since /etc/ssh/ssh_host_*_key will not be readable -- use sudo /usr/sbin/sshd -d -p 2222 – MikeV Oct 02 '18 at 22:44
For some systems (such as CentOS 7), you need systemctl stop sshd.service and systemctl start sshd.service to control the sshd instead of using the service command. – FriendFX Nov 05 '18 at 01:10
My problem was caused by SELinux not being set up for my home directory being shared via NFS. See https://serverfault.com/a/894291/123289 for details and a solution. Thanks to @NRohler for the link to the question. – FriendFX Nov 05 '18 at 01:36
You can check the logs by grep 'sshd' /var/log/auth.log first – Ji Fang Dec 10 '18 at 22:30
This answer pointed me to the light. Then I remembered I had been tinkering with permissions a couple of days before. I owe you big time – ffflabs Nov 27 '20 at 03:34
In my case, the issue was due to wrong key encoding and wrong username:
edit ssh config

vi /etc/ssh/sshd_config #add line: LogLevel DEBUG3

restart sshd

systemctl restart sshd

log

cat /var/log/auth.log

error found:

sshd[3778]: debug1: Could not open authorized keys '/home/user/.ssh/authorized_keys2': No such file or No such file or directory

look for keys encoding in output

ssh-keygen -l -f ~/.ssh/authorized_keys

Therefore

ssh-keygen -t ed25519 -a 256 -f ~/.ssh/id_production

connect to my server

ssh -i ~/.ssh/id_production root@IP_address works
– Kelvin May 16 '21 at 11:46
1

Instead of temporarily stopping the SSH daemon, you can also create a tunnel through port 22 ssh -L 2222:localhost:2222 and then ssh localhost:2222 from another shell to debug. Both commands should be ran on the client. – Igor ostrovsky Feb 13 '22 at 18:19
1

This helps. Looking through the log messages I spotted Authentication refused: bad ownership or modes for /home/tom. Bingo. Turns out that group write was turned on for my home dir on the server. – Tom Russell Apr 24 '22 at 16:00

score 65 · Answer 3 · edited Mar 27 '15 at 23:59

65

Is your home dir encrypted? If so, for your first ssh session you will have to provide a password. The second ssh session to the same server is working with auth key. If this is the case, you could move your authorized_keys to an unencrypted dir and change the path in ~/.ssh/config.

What I ended up doing was create a /etc/ssh/username folder, owned by username, with the correct permissions, and placed the authorized_keys file in there. Then changed the AuthorizedKeysFile directive in /etc/ssh/config to :

AuthorizedKeysFile    /etc/ssh/%u/authorized_keys

This allows multiple users to have this ssh access without compromising permissions.

edited Mar 27 '15 at 23:59

Totor

20,040

answered Sep 23 '12 at 09:31

cee

659

4

ubuntu doc in it: https://help.ubuntu.com/community/SSH/OpenSSH/Keys#Troubleshooting – Fab V. Mar 12 '14 at 07:32
4

This answer is a salient one & helped me - for anyone wondering if this is the issue - you may see "pam_ecryptfs: Passphrase file wrapped" in your auth.log; somehow that wasn't enough to prompt me to remember the homedir was encrypted. Also you may find first logon asks for a passwords, subsequent sessions don't (since it's decrypted whilst the other sessions open). – pacifist Jun 20 '14 at 08:21
1

Holy crap I've searched wayyyy to long to resolve that issue, tank you so much ! – h3. Feb 13 '15 at 17:33
WRONG... Don't give inaccurate or bad advice. It's not nice. Why do you hate people looking for help?
kali@kali2:~/.ssh$ ssh -oKexAlgorithms=+diffie-hellman-group1-sha1 root@10.11.1.136 /home/kali/.ssh/config: line 4: Bad configuration option: authorizedkeysfile /home/kali/.ssh/config: terminating, 1 bad configuration options
– Zack A Jul 11 '20 at 16:23
@ZackA don't be so angry, mate, you put that config in the wrong file. The AuthorizedKeysFile has to go in the file in your ssh server side config. In an Ubuntu server, I have in a pickyourownname.conf file inside the /etc/ssh/ssh_config.d/ directory. – Rubén Cabrera Jun 23 '21 at 19:57

score 63 · Answer 4 · edited May 17 '13 at 09:04

63

Just try these following commands

ssh-keygen

Press Enter key till you get the prompt
ssh-copy-id -i root@ip_address

(It will once ask for the password of the host system)
ssh root@ip_address

Now you should be able to login without any password

edited May 17 '13 at 09:04

Anthon

79,293

answered May 17 '13 at 08:46

Ravindra

747

3

On which server? – Alkanshel Jun 17 '14 at 19:47
3

@Amalgovinus Obviously you run this on the client, not the machine you're connecting to - you don't want a copy of your private key on the server! :) – nevelis Sep 24 '14 at 16:09
14

Please note that generally, allowing remote root logins is not a recommended security practice. – arielf Jun 22 '15 at 18:21
4

@nevelis: If it was obvious to them, they wouldn't have asked. Some people are new to ssh-keygen and they might not understand where the public and private keys are. That's why they're here. – Michael Scheper Oct 19 '21 at 01:47
2

Just elaborating on this answer: I was reluctant to use ssh-copy-id because I wasn't familiar with it; I've always just copied the .pub file, and when it didn't work, tried debugging it with ssh -v. But today, after half an hour of frustration, I thought what the hell, try using this utility instead. And then it just started working. I had to clear some unwanted keys from authorized_keys on my remote machine, but in the end it saved a lot of hassle. Sometimes the easy way really is better. – Michael Scheper Oct 19 '21 at 01:48
@MichaelScheper That's some solid feedback after 7 years :) Cheers. – nevelis Oct 23 '21 at 07:08
This is black magic. – Gabriel Oct 30 '21 at 18:06
I did it manually and it didn't work, but using ssh-copy-id worked. I would have to investigate why!, thanks – damuz91 Nov 24 '22 at 12:04
I did this on rocky linux, and it still asks for my password. I even used ssh -i path to specify the id file. Password works, but I would rather not use one. – majorgear Nov 06 '23 at 22:15

score 52 · Answer 5 · edited Nov 07 '13 at 01:08

52

After copying keys to the remote machine and putting them inside the authorized_keys you've got to do something like this:

ssh-agent bash
ssh-add ~/.ssh/id_dsa or id_rsa

edited Nov 07 '13 at 01:08

slm

369,824

answered Nov 07 '13 at 00:16

gusior

637

1

Actually no you don't. ssh automatically uses ~/.ssh/id_rsa (or id_dsa) without having to use a key agent. – phemmer Nov 07 '13 at 01:29
13

This can still be helpful advice if one was to specify a differently named key in ~/.ssh/config (e.g. on host *.mydomain.org...IdentityFile ~/.ssh/some_limited_use.pub -- ssh-add ~/.ssh/some_limited_use.pub). – 89c3b1b8-b1ae-11e6-b842-48d705 Feb 03 '14 at 12:11
1

This has solved my problem with getting password prompt after adding a key. As 89c3b1b8-b1ae-11e6-b842-48d705 pointed out, the reason to run these commands manually was a non-standard name of a key file. – Mikhail Lisakov Sep 18 '18 at 11:40
2

As pointed out by above in the comments, if you are using any key besides the default key, it is not added by default to the ssh agent. So be sure to check the key you want to use is in the agent's keychain: ssh-add -L – James Mar 11 '19 at 17:58
1

I had to do ssh-add ~/.ssh/id_rsa Thanks a ton! – Simon Polak Apr 13 '20 at 11:59
This is the only solution that worked for me. Thanks! – Eelco van Vliet Jul 01 '21 at 09:50

score 48 · Answer 6 · answered Jul 03 '12 at 07:34

48

I faced challenges when the home directory on the remote does not have correct privileges. In my case the user changed the home dir to 777 for some local access with in the team. The machine could not connect with ssh keys any longer. I changed the permission to 744 and it started to work again.

answered Jul 03 '12 at 07:34

Sahil

581

11

We had this problem too - 755 on the home dirs fixed it – davidfrancis Jul 18 '12 at 14:52
I had permissions set to 777 and it was ignored, thanks!!! – ka_lin Jul 04 '16 at 13:56
Same here. Thanks. Was scratching my head for a while, wtf was happening. – Marcin Oct 27 '18 at 06:40
Yes see the answer here for further detail https://unix.stackexchange.com/questions/205842/unable-to-login-with-ssh-rsa-key#answer-428848 – Tim Feb 19 '19 at 03:53
2

This may well be the answer for people who have done the key generation correctly yet are still getting prompted for a password. – Fergie Feb 21 '19 at 12:37
It's worth (on target machine) doing a 'sudo tail -f /var/log/secure' - I got a 'Dec 4 16:54:47 idp sshd[1492]: Authentication refused: bad ownership or modes for file /home/dazed/.ssh/authorized_keys'. Setting via 'chmod 600 /home/dazed/.ssh/authorized_keys' worked – Dazed Dec 04 '19 at 16:59
This was the issue with me too. Thanks – Ankur Agarwal Sep 27 '20 at 02:14
On my Linux CentOS Linux release 7.9.2009 (Core) I have to put 700 to the server home dir, it was 740. Thanks a lot guys ! – JPBlanc Apr 18 '23 at 10:19

score 30 · Answer 7 · answered Nov 06 '14 at 09:34

We ran into the same problem and we followed the steps in the answer. But it still did not work for us. Our problem was that login worked from one client but not from another (the .ssh directory was NFS mounted and both clients were using the same keys).

So we had to go one step further. By running the ssh command in verbose mode you get a lot of information.

ssh -vv user@host

What we discovered was that the default key (id_rsa) was not accepted and instead the ssh client offered a key matching the client hostname:

debug1: Offering public key: /home/user/.ssh/id_rsa                                    
debug2: we sent a publickey packet, wait for reply                                        
debug1: Authentications that can continue: publickey,gssapi-keyex,gssapi-with-mic,password
debug1: Offering public key: /home/user/.ssh/id_dsa                                    
debug2: we sent a publickey packet, wait for reply                                        
debug1: Authentications that can continue: publickey,gssapi-keyex,gssapi-with-mic,password
debug1: Offering public key: user@myclient                                          
debug2: we sent a publickey packet, wait for reply                                        
debug1: Server accepts key: pkalg ssh-rsa blen 277

Obviously this will not work from any other client.

So the solution in our case was to switch the default rsa key to the one that contained user@myclient. When a key is default, there is no checking for client name.

Then we ran into another problem, after the switch. Apparently the keys are cached in the local ssh agent and we got the following error on the debug log:

'Agent admitted failure to sign using the key'

This was solved by reloading the keys to the ssh agent:

ssh-add

score 17 · Answer 8 · answered Sep 08 '14 at 18:44

17

SELinux on RedHat/CentOS 6 has an issue with pubkey authentication, probably when some of the files are created selinux is not setting its ACLs correctly.

To manually fix the SElinux ACLs for the root user:

restorecon -R -v /root/.ssh

answered Sep 08 '14 at 18:44

David Mackintosh

961

using openssh client on windows I was able to ssh root@mymachine into a CentOS6 mymachine without issue, but I have a lower-privilage user that I'd prefer to use, but ssh regularUser@mymachine still prompts me for a password. thoughts? – Groostav Nov 11 '18 at 10:06

score 14 · Answer 9 · edited Jul 19 '22 at 09:24

14

It would be SSH misconfiguration at server end. Server side sshd_config file has to be edited, it is located in /etc/ssh/sshd_config.

In that file, change variables

yes to no for ChallengeResponseAuthentication, PasswordAuthentication, UsePAM
no to yes for PubkeyAuthentication

(Link to original source is now pointing to spam and was removed).

edited Jul 19 '22 at 09:24

AdminBee

22,803

answered Jun 03 '14 at 10:13

nish

149

1

As in comments to question check the /var/log/secure or /var/log/auth.log. In my case I see "User xxx from xxx not allowed because not listed in AllowUsers" "input_userauth_request: invalid user xxx [preauth]" ( and "rexec line 35: Deprecated option ServerKeyBits" in /var/log/messages although I dunno what that is). To resolve vi /etc/ssh/sshd_config, add user xxx to AllowUsers list, service sshd restart *** BEWARE restarting sshd service with bad sshd_config might lock you out of a box!? ***. That worked. – gaoithe Jan 03 '19 at 12:30

score 8 · Answer 10 · answered Dec 16 '14 at 10:44

I ran into a similar problem and followed the steps using the debug mode.

/usr/sbin/sshd -d

This showed the following result

debug1: trying public key file /root/.ssh/authorized_keys
debug1: fd 4 clearing O_NONBLOCK
Authentication refused: bad ownership or modes for directory /root
debug1: restore_uid: 0/0
debug1: temporarily_use_uid: 0/0 (e=0/0)
debug1: trying public key file /root/.ssh/authorized_keys2
debug1: Could not open authorized keys '/root/.ssh/authorized_keys2': No such file or directory
debug1: restore_uid: 0/0
Failed publickey for root from 135.250.24.32 port 54553 ssh2
debug1: userauth-request for user root service ssh-connection method gssapi-with-mic

It was really confusing

[root@sys-135 ~]# ls -l /
drwxrwxrwx.   2 root root     4096 Dec 14 20:05 bin
drwxrwxrwx.   5 root root     1024 May  6  2014 boot
drwxrwxrwx.   2 root root     4096 Dec  2  2013 cgroup
drwxrwxrwx.  10 root root     1024 Sep 25 23:46 data
drwxrwxrwx. 124 root root    12288 Dec 16 10:26 etc
drwxrwxrwx.  11 root root     4096 Jan 14  2014 lib
drwxrwxrwx.   9 root root    12288 Dec 14 20:05 lib64
drwxrwxrwx.   2 root root    16384 Jan 10  2014 lost+found
drwxrwxrwx.   2 root root     4096 Jun 28  2011 media
drwxr-xr-x.   2 root root        0 Dec 10 14:35 misc
drwxrwxrwx.   2 root root     4096 Jun 28  2011 mnt
drwxrwxrwx.   4 root root     4096 Nov 24 23:13 opt
dr-xr-xr-x. 580 root root        0 Dec 10 14:35 proc
drwxrwxrwx.  45 root root     4096 Dec 16 10:26 root

It showed the root directory had permissions for every one. We changed it so that others would not have permissions.

[root@sys-135 ~]# chmod 750 /root

The key authentication started working.

I have same issue. Yesterday, I issued rsync -av ./root/ root@THE_HOST:/root to upload some files from my local working directory, then, this issue occurs (in fact, at first I didn't notice it. After cron jobs in other hosts fails in the next morning, I started digging the reason). The rsync -av ./root/ root@THE_HOST:/root command changed the owner and permission of the /root directory of the remote host. Fixed the permission, problem solved. — LiuYan 刘研, Jun 13 '15 at 03:41
Failed publickey for root from 135.250.24.32 port 54553 ssh2 I get same message and issue when I forgot to add the pubkey to a host authorized_keys. Adding this comment as in my case, I usually realize my mistake after I checked the debug and all the permissions plus config files #:o< — tuk0z, Sep 17 '16 at 21:48

marc · Answer 11 · 2023-03-14T14:00:46.283

In the past I came across some tutorials that describe how to achieve a ssh password-less setup, but some are sadly wrong.
Let's start over again, and check every step:

FROM CLIENT - Generate key: ssh-keygen -t rsa
Public and private key (id_rsa.pub and id_rsa) will be automatically stored in the ~/.ssh/ directory.
Setup will be easier if you use an empty passphrase. If you are not willing to do that, then still follow this guide, but also check the bullet point below.
FROM CLIENT - Copy public key to server : ssh-copy-id user@server
Client public key will be copied to server's location ~/.ssh/authorized_keys.
FROM CLIENT - Connect to server: ssh user@server

Now, if it's still not working after the described 3 steps, lets try the following:

Check ~/.ssh folder permissions in client and server machine.
Check /etc/ssh/sshd_config in the server to ensure that RSAAuthentication, PubkeyAuthentication and UsePAM options aren't disabled, they can be enabled by default with yes.
If you entered a passphrase while generating your client key, then you may try ssh-agent & ssh-add to achieve password-less connections in your session.
Check the contents of /var/log/auth.log on the server to find the issue why key authentication is skipped at all.

Thanks for listing out the steps! I got to "ssh-copy-id user@server" and realized that I had originally copied over the wrong public key. — Design.Garden, Apr 15 '19 at 18:42
In your first bullet, it should read "check ~/.ssh folder permissions on client and server for the client and server users" — RichVel, Oct 24 '19 at 05:20

score 7 · Answer 12 · edited Jun 05 '15 at 01:53

7

Ensure that AuthorizedKeysFile points to the right location, use %u as a placeholder for username:

# /etc/ssh/sshd_config
AuthorizedKeysFile /home/%u/authorized_keys

It may be that you just need to uncomment the line:

AuthorizedKeysFile .ssh/authorized_keys

Mind that you must reload ssh service for the changes to take place:

service sshd reload

edited Jun 05 '15 at 01:53

Community

1

answered Jul 01 '13 at 15:41

Dziamid

171

score 6 · Answer 13 · edited Jun 03 '14 at 19:31

6

One thing that I had wrong was the ownership on my home directory on the server system. The server system was set to default:default so I:

chown -R root:root /root

And it worked. Another Cheap workaround is to Disable StrictModes: StirctModes no. in sshd_config. This will at least tell you if the key exchange and connection protocols are good. Then you can go hunt the bad permissions.

edited Jun 03 '14 at 19:31

Anthon

79,293

answered Jun 03 '14 at 18:36

Will

71

Me too. Look at the messages in /var/log/secure. I saw a message: "Authentication refused: bad ownership or modes for directory" ($HOME). Make sure there isn't write access to $HOME to Group or Other. I'd never have found this if I didn't have unauthorized root access to the server.... – SoloPilot May 06 '18 at 15:43

Steven C. Howell · Answer 14 · 2020-08-10T13:30:16.340

6

After checking the permissions, and trying several other solutions listed here, I finally just removed the ssh directory on the server, then setup my public key again.

Server commands:

rm -rf ~/.ssh

Local commands:

ssh-copy-id user@192.168.1.1        # where <user> is your username and <192.168.1.1> is the server IP

edited Aug 10 '20 at 13:30

answered May 06 '16 at 19:27

Steven C. Howell

487

Exactly what I finished by doing (after checking everything above!) but localy on the host and then It started working. I unfortunetly will never know why it didn't. Thanks. – Pozinux Jan 09 '20 at 22:25
1

debuging and understanding is always good, but when you need the things working NOW - this is it. – faceless Aug 09 '20 at 18:47

score 5 · Answer 15 · edited Feb 15 '19 at 17:50

5

At server:

$ ls -lh /home
$ sudo chmod 700 /home/$USER

It was directory permission issue. It was 777 at server, so I changed it back to 700. This fixed my issue with ssh password less login failure even after copying $USER/.ssh/id_rsa.pub to server $USER/.ssh/authorized_keys.

edited Feb 15 '19 at 17:50

slm

369,824

answered Aug 10 '18 at 21:31

fastrizwaan

197

See also https://www.daveperrett.com/articles/2010/09/14/ssh-authentication-refused/ – Olumide Sep 30 '19 at 14:23

cowlinator · Answer 16 · 2021-11-19T03:10:46.247

If both the private key and the username/password authentication methods are accepted by the server, and then if the private key fails, it will simply fall back to prompting for a username/password without displaying any error.

You can use the -vvv flag to determine if a private key was even attempted, (and which keys specifically), and why the key(s) are failing. Example: ssh -T -vvv myHost.com. Alternatively, you can use LogLevel DEBUG3 in ~/.ssh/config.

A common failure is that the server rejects the key. In that case, you will see something like this:

debug1: Next authentication method: publickey
debug1: Trying private key: /c/Users/myUsername/.ssh/id_rsa
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,password
debug1: Next authentication method: password
myUsername@myServer.com's password:

According to the official spec for the SSH protocol (RFC 4252), the authentication packets have the following values:

SSH_MSG_USERAUTH_REQUEST    50
SSH_MSG_USERAUTH_FAILURE    51
SSH_MSG_USERAUTH_SUCCESS    52

This means that debug3: receive packet: type 51 indicates that the server rejected the key.

score 5 · Answer 17 · answered Apr 10 '13 at 10:09

5

In /etc/selinux/config file changing SELINUX to disabled from enforcing made passwordless ssh work successfully.

Earlier I am able to do it on one way. Now from bothways I am able to do passwordless ssh.

answered Apr 10 '13 at 10:09

chinna

51

score 4 · Answer 18 · answered Apr 16 '12 at 14:44

4

Two comments: this will overwrite the original file. I'd just copy the public key generated and do something like:

cat your_public_key.pub >> .ssh/authorized_keys

This will append the key you want to use to the pre-existing list of keys. Also, some systems use the file authorized_keys2, so it's a good idea to make a hard link pointing between authorized_keys and authorized_keys2, just in case.

answered Apr 16 '12 at 14:44

Wojtek

2,330

Yeah, I noticed that too about the overwrite, but I didn't have any, so it didn't matter. I created a symlink to the authorized_keys2 but that didn't help. – Thom Apr 16 '12 at 14:46
Also, check the file/directory permissions. They are described on the website you provided. – Wojtek Apr 16 '12 at 15:00
3

your ~/.ssh dir must be 700 your private key file must be 600 your public key file must be 644 your auth file (on the remote) must be 644 – Rob Apr 16 '12 at 15:03
@Rob that was the problem. If you'd post that as an answer, I'd accept it. – Thom Apr 17 '12 at 09:08

score 4 · Answer 19 · answered Apr 19 '18 at 14:44

I was having the exact same problem with PuTTY connecting to an Ubuntu 16.04 machine. It was puzzling because PuTTY's pscp program was working fine with the same key (and the same key worked in PuTTY to connect to another host).

Thanks to the valuable comment from @UtahJarhead, I checked my /var/log/auth.log file and found the following:

sshd[17278]: userauth_pubkey: key type ssh-dss not in PubkeyAcceptedKeyTypes [preauth]

It turns out that newer versions of OpenSSH don't accept DSA keys by default. Once I switched from a DSA to an RSA key, it worked fine.

Another approach: this question discusses how to configure the SSH server to accept DSA keys: https://superuser.com/questions/1016989/ssh-dsa-keys-no-longer-work-for-password-less-authentication?lq=1

score 4 · Answer 20 · answered Sep 11 '13 at 14:29

4

My solution was that the account was locked. Message found in /var/log/secure: User not allowed because account is locked Solution: give the user a new password.

answered Sep 11 '13 at 14:29

user46932

49

I fixed it by changing password field in /etc/shadow for this user from ! to *. After that password authentication is still impossible, but user is not locked anymore. – user3132194 Apr 07 '16 at 11:53

score 3 · Answer 21 · edited Apr 13 '17 at 12:37

3

For me, the solution was opposite Wojtek Rzepala's: I didn't notice I was still using authorized_keys2, which has been deprecated. My ssh setup stopped working at some point, presumably when the server was updated. Renaming .ssh/authorized_keys2 as .ssh/authorized_keys fixed the problem.

D'oh!

edited Apr 13 '17 at 12:37

Community

1

answered Sep 30 '14 at 01:33

Michael Scheper

263

This is also a configuration option in /etc/ssh/sshd_config, although I think I'd rename it like you did. – Rick Smith Oct 14 '15 at 21:17

score 2 · Answer 22 · answered Jan 09 '14 at 13:28

I had similar problem with ssh. In my case the problem was that I installed hadoop cloudera (from rpm on centos 6) and it created user hdfs with home directory

/var/lib/hadoop-hdfs (not standard /home/hdfs).

I changed in /etc/passwd /var/lib/hadoop-hdfs to /home/hdfs, moved home directory to new location and now I can connect with public key authentication.

score 2 · Answer 23 · answered Oct 31 '14 at 19:08

I just had this same problem, and for me the solution was to set UsePAM to no. See, even with PasswordAuthentication set to no, you'll still get keyboard-interactive, and in my case my local ssh program kept defaulting to that, for some reason.

Extra background to help anyone with the same situation: I'm connecting from a host running Dropbear to one running OpenSSH. With PasswordAuthentication and UsePAM both set no on the remote machine, I'll get the following message if I enter ssh user@server:

ssh: Connection to user@server:22 exited: Disconnect received

Providing the identity file with -i, everything works as expected.

There may be a little more information here.

score 2 · Answer 24 · answered Apr 17 '12 at 04:38

2

These steps should help you out. I use this regularly among many 64bit Ubuntu 10.04 machines.

[ ! -f ~/.ssh/id_rsa.pub ] && ssh-keygen -t rsa;
ssh <username>@<remote_machine> 'mkdir -p ~/.ssh'
cat ~/.ssh/id_rsa.pub | ssh <username>@<remote_machine> 'cat >> ~/.ssh/authorized_keys'

you could put this in a script with some prompts and invoke it as

script_name username remote_machine

answered Apr 17 '12 at 04:38

Sriharsha

41

There exists already ssh-copy-id which does the last two steps automatically. – jofel Apr 17 '12 at 13:05
2

@jofel keep in mind that in many systems ssh-copy-id does not exist. @Sriharsha after the mkdir you should add there chmod 700 .ssh too and btw you don't need be so verbose with ~/.ssh, just .ssh is enough since the commands are executed in the home directory anyway – janos Apr 17 '12 at 18:09

score 1 · Answer 25 · edited Feb 15 '19 at 17:52

My scenario was that I have a NAS server on which I created a backupbot user, after the creation of my primary account, which was able to log in to initially create the backupbot user. After fiddling with sudo vim /etc/ssh/sshd_config, and creating the backupbot user, vim can create, at least on Ubuntu 16.04, and based on your ~/.vimrc config, a swap file left from your vim session's editing of /etc/ssh/sshd_config.

Check to see if: /etc/ssh/.sshd_config.swp exists, and if it does remove it and restart the sshd daemon:

$ sudo rm /etc/ssh/.sshd_config.swp
$ sudo service sshd restart

This magically resolved my issue. I had previously checked all my permissions and even the RSA fingerprints of the public and private keys. This is strange and probably a bug with sshd, specifically this version:

OpenSSH_7.4p1 Ubuntu-10, OpenSSL 1.0.2g 1 Mar 2016

score 1 · Answer 26 · answered Jan 15 '19 at 17:59

Yet another option is a variant of @Jagadish 's answer: to strace the ssh daemon.

It has the significant advantage, that we don't need to stop the sshd, what can result a complete lockout if something goes badly.

First, we find the pid of the main sshd process. Here we can see it by executing a pstree -pa|less.

  |-sshd,633 -D  <-- THIS IS WHAT WE WANT!
  |   `-sshd,21973   
  |       `-sshd,21996    
  |           `-bash,22000
  |               `-screen,638 -r

After knowing, that the pid is 633, we can strace it, following its children:

strace -p 633 -s 4096 -f -o sux

The result will be that everything what this sshd, and its child processes have done, will be strace-ed into the file named sux in the local directory.

Then reproduce the problem.

It will have a massive list of kernel call log, which is mostly incomprehensible/irrelevant for us, but not everywhere. In my case, the important thing was this:

6834  sendto(4, "<38>Jan 15 18:49:21 sshd[6834]: User cica not allowed because account is locked\0", 84, MSG_NOSIGNAL, NULL, 0) = 84

It was meants, that the sshd tried to log the message User cica not allowed because account is locked - it only couldn't, because logging is not enough verbose for that. But we already know, the pubkey was rejected because the account was locked.

It is not yet a solution - now we need to google, what means a "locked account" in the case of the sshd. It will be most likely some trivial /etc/passwd, /etc/shadow wizardry, but the important thing is done - the problem isn't a mysterious, but an easily debuggable/googlable one.

I tried that method. In my case, it was because the ownership of the .ssh folder was wrong. Using sshd -d showed the error, but unfortunately strace didn't catch it. Glad I learned about pstree in your response. — Wadih M., Aug 16 '21 at 16:01
@WadihM You are right - in this case, strace will only contain that sshd checked the ~/.ssh metadata with an fstat-related syscall. Possibly you would catch also the logging try, possibly not (it depends on, how verbose is sshd without the -d flag). Thanks the feedback! — peterh, Aug 16 '21 at 18:41

score 0 · Answer 27 · answered Jan 31 '19 at 11:04

In my case I had all permissions right and even when running ssh with -vvv flag I couldn't figure out what was the problem.

So I generated new certificate on remote host

ssh-keygen -t rsa -C "your_email@example.com"

and copied generated keys to local machine and added new public key to ~/.ssh/authorized_keys on remote host

cat id_rsa.pub >> authorized_keys

Using generated keys from remote host machine connection now works. So if other solutions fail this is another thing to try.

score 0 · Answer 28 · answered Jun 04 '21 at 18:04

I had the same problem when connecting from Raspbian8 to Fedora34.

The debug error I received was:

userauth_pubkey: key type ssh-rsa not in PubkeyAcceptedAlgorithms [preauth]

The solution was to append ssh-rsa to the value of PubkeyAcceptedAlgorithms in

/etc/crypto-policies/back-ends/opensshserver.config

and restart the service

thanks to Dave @ https://wiki.xdroop.com/space/Fedora/34/SSH+Pubkey+doesn%27t+work for this solution

score 0 · Answer 29 · answered Nov 11 '21 at 19:57

I tried to log into a colleague's account without password, by pasting id_rsa.pub into her authorized_keys file. I got the permissions of all relevant files right, but still couldn't succeed with password-less login.

It turns out since I created the authorized_keys file with root permission, I had to chown and chgrp to the ones that match her profile.

sudo chown ${username} -R /home/${username}/.ssh
sudo chgrp ${groupname} -R /home/${groupname}/.ssh

It was easy to spot this mistake when you use the triple verbose mode ssh -vvv.

score 0 · Answer 30 · edited Jan 07 '24 at 13:10

0

In my case, id_rsa authentication appears to be deprecated and is not utilized by default in SSH. Switching to ed25519 resolved my problem.

ssh-keygen -t ed25519

ssh-copy-id -i ~/.ssh/id_ed25519 username@remote

edited Jan 07 '24 at 13:10

Jan Černý

1,381

answered Jan 06 '24 at 05:13

konchy

111

Why am I still getting a password prompt with ssh with public key authentication?

30 Answers30

edit ssh config

restart sshd

log

error found:

look for keys encoding in output

Therefore

connect to my server

Linked

Related