SSH Permission denied (publickey)

Question

I am trying to connect to a Linode (running Ubuntu 12.04 LTS) from my local machine (also running Ubuntu 12.04 LTS)

I have created a private and public key on my local machine and copied my public key to my Linode's authorized_keys file. However, whenever I try to ssh to my Linode I get the error message Permission denied (publickey).

It's not a problem with how ssh is set up on my Linode because I can ssh to it from my Windows machine using key authentication.

In my .ssh directory on my local Ubuntu machine, I have my id_rsa and id_rsa.pub files. Do I need to create an authorized_keys file on my local machine?

EDIT: This is what I get when I run ssh -vvv -i id_rsa [youruser]@[yourLinode]:

debug3: authmethod_lookup publickey
debug3: remaining preferred: keyboard-interactive,password
debug3: authmethod_is_enabled publickey
debug1: Next authentication method: publickey
debug1: Offering RSA public key: id_rsa
debug3: send_pubkey_test
debug2: we sent a publickey packet, wait for reply
debug1: Authentications that can continue: publickey
debug2: we did not send a packet, disable method
debug1: No more authentication methods to try.
Permission denied (publickey).

The command should have been ssh -vvv -i .ssh/id_rsa .... (note the path to id_rsa!) - please replace - the old log only shows that "we" had no pubKey to send. — guntbert, Jun 23 '13 at 11:22
@guntbert I missed out the .ssh because I was already in the .ssh directory. I also tried it with .ssh/id_rsa but I got the same result — Pattle, Jun 23 '13 at 11:30
I see, so I misread - Please answer the questions from @gertvdijk. — guntbert, Jun 23 '13 at 11:40
Very useful tutorial: www.digitalocean.com: How To Set Up SSH Keys. — Gabriel Staples, Dec 22 '20 at 04:38
I had same problem. I could log on as root but not as new_user. If you can access your server as root or a sudo user you can watch the ssh auth log via "tail -f /var/log/auth.log". in my case the problem was the new_user was configured with an invalid shell. "user new_user not allowed because shell /bin/ is not executable". — Bryan, Feb 16 '22 at 16:41
(not enough reputation to post as an answer) More recently, this can also happen due to the SHA-1 signature in RSA keys becoming deprecated. Running ssh -vvv will report "no mutual signature algorithm" if this is the case. To fix, either update your ssh server to support rsa-sha2, or regen your key with ssh-keygen -t ed25519, or pass -o PubkeyAcceptedKeyTypes=+ssh-rsa to the ssh client. — Sir Athos, Apr 26 '23 at 09:26
I had this today with a new user account I had added - the keys were fine and all were installed correctly. On checking the /var/log/auth.log, I could see that the connection was being refused becasue the user account was not in the AllowUsers list in the server's — ChumKui, Aug 10 '23 at 13:43
meant to say the server's SSH config file (/etc/ssh/sshd_config). It is good practice to lock down SSH in this way so only those user accounts that abolsutely need to SSH in, can do. — ChumKui, Aug 10 '23 at 13:50

score 166 · Answer 1 · edited Apr 02 '22 at 02:20

166

PubKeyAuthentication

Set up your client

Generate your key.
```
ssh-keygen
```
Configure ssh to use the key.
```
vim ~/.ssh/config
```
Your config file should have something similar to the following:
```
Host SERVERNAME
Hostname ip-or-domain-of-server
User USERNAME
PubKeyAuthentication yes
IdentityFile ./path/to/key
```
You can add IdentitiesOnly yes to ensure ssh uses the specified IdentityFile and no other keyfiles during authentication. Setting IdentitiesOnly prevents failed authentications from occurring, when ssh would otherwise attempt to login with multiple keys. Setting this is also considered more secure, as you're not leaking information about other keys you have installed, and maintaining separation of your keys between different levels of access.
Copy your key to your server.
```
ssh-copy-id -i /path/to/key.pub SERVERNAME`
```
For example, ssh-copy-id -i ~/.ssh/id_res.pub -p 22 user@1.1.1.1

Troubleshooting

use "-vvv" option
Make sure the server has your PUBLIC key (.pub).
Make sure your IdentiyFile points to your PRIVATE key.
Make sure your .ssh directory has 700 and the files within are 600 permissions.
- ssh-keygen will create files and directories for you with the proper permissions
tail -f /var/log/auth.log (on the server) and monitor errors when you attempt to login
If you have many key files, try IdentitiesOnly yes to limit the authentication to use the single, specified key.

edited Apr 02 '22 at 02:20

matigo

22,138
7
45
75

answered Jun 23 '13 at 21:04

earthmeLon

11,247

4

FYI, I created a small script at https://github.com/centic9/generate-and-send-ssh-key which runs the necessary steps in one go and additionally ensures all the file/directory permissions which always caused me headaches... – centic Oct 07 '15 at 11:30
6

Just to elaborate step 2: the IdentityFile line in ~/.ssh/config must point to the PRIVATE key. – Danny Schoemann Aug 30 '17 at 14:19
1

Indeed. – earthmeLon Jun 12 '18 at 20:40
6

I wonder why you'd want to set files to have execute permission in step 4? – Todd Walton Nov 07 '18 at 13:43
1

It's also very important right permissions per user (use chown and chmod) otherwise you will get an authentication denied even if you server has your public key. – joseluisq Jul 23 '19 at 07:40
1

Why does every question like this contain an answer that tells you to start by generating the key using ssh-keygen? OP already said he has a public and private key. – Aaron Franke Sep 22 '19 at 20:10
2

Posterity and completeness is why. – earthmeLon Sep 28 '19 at 21:48
6

While the directory requires 700 permissions, the files do not, they should be 600. – openCivilisation Oct 24 '20 at 10:13
tail -f /var/log/auth.log gave the required info for me – Shankar Thyagarajan May 17 '22 at 10:56
authorized_keys needs 644 I think. – KuN Jul 29 '23 at 02:47
600 on authorized_keys is the default and all you need under most circumstances. – earthmeLon Aug 01 '23 at 15:03

score 144 · Answer 2 · edited Mar 10 '23 at 07:16

144

Sometimes the issue comes from permissions and ownership. For instance, if you want to log in as root, /root, .ssh and authorized_keys must belong to root. Otherwise, sshd won't be able to read them and therefore won't be able to tell if the user is authorized to log in.

In your home directory:

chown -R your_user:your_user .ssh

As for rights, go with 700 for .ssh and 600 for authorized_keys

chmod 700 .ssh
chmod 600 .ssh/authorized_keys

edited Mar 10 '23 at 07:16

Artur Meinild

26,018

answered Mar 15 '16 at 11:50

Buzut

1,591
1
10
7

4

This answer helped me. I had taken the advice from this post and moved my authorized_keys file outside of my encrypted home directory. In doing so, I had inadvertently changed ownership to root:root. – Jordan Grant Aug 12 '16 at 22:27
4

Wish I could upvote twice, once for the folder and once for the file. Very important that permissions are exact. – Mr Griever May 15 '19 at 18:21
I changed the permission of my home folder /home/user to 777 by mistake, this make ssh failed. chmod 777 /home/user will fix it. – hellohawaii Jul 02 '23 at 18:01

score 51 · Answer 3 · answered Feb 04 '17 at 22:28

51

The problem I had was it was using the wrong keys on the client. I had renamed id_rsa and id_rsa.pub to something else. You can either rename them back to their default, or when you issue the ssh command, use it like this

ssh -i ~/.ssh/private_key username@host

answered Feb 04 '17 at 22:28

Todd

611

1

no, use the public key – St3an Dec 03 '18 at 09:58
12

@St3an you put the public key on the server, but when you connected like Todd is here above, you use your private key – Nathan F. Apr 10 '19 at 21:50
@NathanFiscaletti you must never expose your private key, that's why it's private. The private key is used by your local ssh agent to check that you really give a public key that correspond to your private one. SSH agents between machines can then guarantee that users are who they pretend to be :-) – St3an Apr 11 '19 at 08:26
15

Exactly. Which is why when you connect, you provide your private key to the ssh-client. The server stores your public key. The command in the post above is exactly how private keys are supposed to be used. – Nathan F. Apr 11 '19 at 14:54
This works like a charm, and finally solved my first connection to the server. – p3nchan Jul 08 '21 at 11:48

score 21 · Answer 4 · answered Jun 22 '13 at 21:42

21

You don't need authorized_keys on your client.

You must tell the ssh-client to actually use the key you generated. There are several ways to do that. Just for testing type ssh -vvv -i .ssh/id_rsa [youruser]@[yourLinode]. You will have to provide your passphrase every time you want to connect to the server.

If that worked you can add the key to the ssh-agent with ssh-add .ssh/id_rsa (you will have to provide the passphrase only once for this and it should work as long as you don't logout/reboot)

answered Jun 22 '13 at 21:42

guntbert

13,134

Thanks for your help, I have edited my answer to show what happens when I type what you suggested. – Pattle Jun 22 '13 at 23:22
2

to transfer a key, on the client, use ssh-copy-id – Panther Jun 23 '13 at 00:30
@bodhi.zazen Thanks, but I have already transferred the key, that isn't the problems – Pattle Jun 23 '13 at 00:33
4

"You must tell the ssh-client to actually use the key you generated." No, by default it will look for the key in the default path, e.g. ~/.ssh/id_rsa. Also, the use of a key agent is completely optional and unrelated to the issue as far as I can see. – gertvdijk Jun 23 '13 at 01:09
@gertvdijk, you are making assumptions here which are not backed by facts yet - we don't know what happened on the system. – guntbert Jun 23 '13 at 11:24
If SSH doesn't automaticly, then there are things done to the system which are not reported. So it should OK to assume default behaviour. But the -vvv are great way of know what the client SSH does. I would like the user to transfer the keys again, with ssh-copy-id. I would goes the problem is on the server side. – Anders Jun 23 '13 at 17:12
How to pass a passphrase in the same command – Kiran Reddy Feb 23 '17 at 05:47
It is possible that ssh-agent will not see a new key in ~/.ssh/id_rsa if it is already using a different key. You'll need to use ssh-add again. Using that as a default for ssh is ignored I think if there are any keys in ssh-agent. – Mnebuerquo Jul 05 '18 at 17:21

score 19 · Answer 5 · answered Feb 09 '17 at 10:11

19

Also check value of PasswordAuthentication in /etc/ssh/sshd_config and if it's no change it to yes. Don't forget to restart ssh service after that.

answered Feb 09 '17 at 10:11

iman

875
9
15

30

The OP is not trying to use password authentication. They have some sense and are using public/private key. – ctrl-alt-delor Aug 20 '18 at 17:43
2

This solved my issue, in some cloud server, after enable ssh login, password login is disabled automatically ... – Eric Jul 30 '21 at 08:09
The OP didn't have this issue, but others who have a similar issue (e.g. yours truly) may be directed to this question by Google. I am trying to set up a test server within my firewall with password authentication. One might say that's never advisable, but I would like to know that I have the option. – Dr Phil Apr 25 '23 at 02:38

score 7 · Answer 6 · answered Nov 24 '13 at 05:55

I ran into this issue recently with my web server.

I typically keep a list of authorized keys on all my servers in ~/.ssh/authorized_keys2. From my experience, sshd will look for ~/.ssh/authorized_keys or ~/.ssh/authorized_keys2 by default.

In the case of my webserver, the /etc/ssh/sshd_config had this line

AuthorizedKeysFile    %h/.ssh/authorized_keys

instead of

AuthorizedKeysFile    %h/.ssh/authorized_keys2

I applied the latter, restarted my ssh daemon, and solved my problem logging in with ssh using my pubkey.

Thanks a lot, this helped me figuring out that this line was completely commented out of the config! — Christian.D, Oct 08 '18 at 08:45

score 7 · Answer 7 · edited Apr 20 '15 at 21:22

7

Also make sure that the user's home directory (on the server) actually belongs to the user ssh'ing into (was set to root:root in my case).

Should have been:

sudo chown username:username /home/username;

edited Apr 20 '15 at 21:22

Jens Erat

5,051
7
31
37

answered Apr 20 '15 at 19:07

canoodle

211

I am able to ssh with public/private keys with a user on my local linux box (e.g. abc), different from the user on the remote server (e.g. def@123.456.789). I just had to make sure the local user owned the local .ssh files (e.g. abc:abc, not root:abc)` – Michael Millar Dec 22 '15 at 09:44

score 7 · Answer 8 · answered Sep 03 '15 at 17:07

7

Another possible cause could be with the AllowedUsers configuration in /etc/ssh/sshd_conf. NOTE: the list is space delimited (not comma delimited) as I learned the hard way.

AllowUsers user1 user2 user3

answered Sep 03 '15 at 17:07

cmbind55

71
1
2

anask · Answer 9 · 2018-03-25T05:16:30.720

The following method might work if you can access machineA and machineB independently (e.g. from machineC).

If ssh-copy-id is not working, password authentication could be disabled. The following is a workaround.

Having machineA's public key in machineB's authorized keys (i.e. ~/.ssh/authorized_keys) will allow you to ssh from machineA. This also applies to scp.

After generating the key pairs using: ssh-keygen

On machineA, execute cat ~/.ssh/id_rsa.pub

Sample output:

ssh-rsa AAAAB3NzaSGMFZW7yB anask@mahineA

Copy the printed key (⌘ Command+C, or CRTL+C) then add it to the ~/.ssh/authorized_keys file on machineB.

For example, execute the following on machineB:

echo 'ssh-rsa AAAAB3NzaSGMFZW7yB anask@mahineA' >> ~/.ssh/authorized_keys

This one worked for me- it turned out the simplest – dollar bill May 07 '22 at 12:04 — dollar bill, May 07 '22 at 12:04

score 4 · Answer 10 · edited Mar 24 '20 at 09:48

Works on Ubuntu 16.04 as well.

The issue is within sshd_config file

Here is the ULTIMATE solution:

Log as as a root to you Ubuntu server

vi /etc/ssh/sshd_config

Now go to very bottom and change the value from "no" to "yes".

It should look like this:

Change to no to disable tunnelled clear text passwords

PasswordAuthentication yes
service sshd reload

to take effect.

Now you can simply a key using following command from your LOCAL machine (aka laptop etc)

So in order to open a new terminal window and NOT log into server, simply use this command:

ssh-copy-id john@serverIPAddress

(Replace john with your username).

you should be good to go

score 3 · Answer 11 · answered Jul 12 '16 at 02:41

I my case, the client is ubuntu 14.04lts, the server was win 2012 server running cygwin. I was using 'ssh administrator@x.x.x.x', when the 2012 server directory in cygwin was /home/Administrator. So it was case sensitive, when I tried 'ssh Administrator@x.x.x.x' (note the capital A on Administrator) then it worked fine.

An error message like 'user not found' would have led me to the solution a lot quicker than 'Permission denied (publickey,keyboard-interactive)'.

Someone should log an issue with the ssh project suggesting that. I ran into a similar issue. — Ben Creasy, Nov 27 '16 at 11:58

score 2 · Answer 12 · answered Oct 29 '18 at 13:21

Some people wondering may have set up ssh access to be key only on the root account then created a new user and not realised they need to

ssh root@your-ip-address

rsync --archive --chown=[user]:[user] ~/.ssh /home/[user]

logout

Then try again. Replace [user] with your new user account.

This is common when setting up a new server on DigitalOcean when you've used ssh-keys on setup.

https://www.digitalocean.com/community/tutorials/initial-server-setup-with-ubuntu-18-04

score 2 · Answer 13 · edited Mar 10 '23 at 07:17

2

Owner permission for the ~/.ssh directory, should contain your username.

chown -R $USER:$USER /home/$USER/.ssh

Note: Make sure $USER is your correct username (not root).

edited Mar 10 '23 at 07:17

AsukaMinato

229

answered Apr 18 '22 at 07:29

Benny

4,920

score 2 · Answer 14 · edited Apr 13 '17 at 12:37

I had the same issue when copying a regular user's (e.g. johndoe) public key from a cPanel Centos system over to an Ubuntu server on AWS. As suggested by gertvdijk above, I checked /var/log/auth.log and sure enough it said Authentication refused: bad ownership or modes for directory /home/johndoe. Turns out I had wrongly 777'ed /home/johndoe when trying to set /home/johndoe/public_html as the default virtualhost Document Root for apache2 (that's not needed for that task either).

SSH Permission denied (publickey)

22 Answers22

PubKeyAuthentication

Linked

Related