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).

score 177 · Answer 1 · edited May 12 '25 at 03:10

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 key files 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 the verbose option: -vvv
Make sure the server has your PUBLIC key (.pub).
Make sure your IdentityFile points to your PRIVATE key.
Make sure your .ssh directory has 700 permissions and the files within that directory have 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.

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

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

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

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

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

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)

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

21

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

973

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

8

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

81

score 7 · Answer 7 · 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.

score 7 · Answer 8 · 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,131
7
33
37

answered Apr 20 '15 at 19:07

canoodle

221

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

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)'.

score 3 · Answer 12 · 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).

See also the answers here and here

The server only needs to have the public key in .ssh/authorized_keys and the client (computer you're working on) needs to have the private key (.pem, or if using SFTP with Filezilla, .ppk)

score 2 · Answer 13 · 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 14 · 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

259

answered Apr 18 '22 at 07:29

Benny

5,100

bomben · Answer 15 · 2020-11-08T20:40:52.830

I had added a wrong key to the server. Because I did not use the command with an option to specify a certain key it added the standard key-file.

Make sure you did use ssh-copy-id -i CORRECT_KEY.pub

This wrong key worked great with one client, because this client also had this key. But when trying to connect with another client to the same server it obviously failed.

Also, which might be interesting is that you get more logging with ssh -vv instead of just the single -v.

score 1 · Answer 16 · edited Jan 25 '23 at 17:46

Another causes for this error are:

Incorrect user in ssh -i id_rsa [user]@[yourLinode]
Outdated SSH RSA key. OpenSSH v8 deprecated RSA algorithm by default. Regenerate your keys with: ssh-keygen -t ed25519 -f ~/.ssh/your.key -C "My key"

This might be the case especially if you're getting the possible debug warning:

debug1: send_pubkey_test: no mutual signature algorithm

Here is the good article that describes possible issues for this error: https://aws.amazon.com/premiumsupport/knowledge-center/ec2-linux-fix-permission-denied-errors/

Other references:

score 1 · Answer 17 · answered Oct 17 '24 at 09:48

For trouble shooting, once you have setup the .ssh/authorized_keys file:

In /etc/ssh/sshd_config, set this:

LogLevel DEBUG2

This shows whether the .ssh/authorized_keys is actually read or the key is not found in it. Maybe, you copied it wrongly.

Run this to see how the authentication process goes on the server side:

tail -f /var/log/auth.log

Credits:

score 1 · Answer 18 · answered Oct 17 '14 at 06:21

If all else failed, check that your login user belongs to the ssh's AllowedGroup. That is, your users is a member of the group shown at the following line in /etc/ssh/sshd_config on the server:

AllowGroups ssh #Here only users of 'ssh' group can login

score 1 · Answer 19 · answered Mar 28 '17 at 11:06

For those Putty users like me who came to this thread, you may also get this error if you forgot to add user user@Ip !

Others being permission on key file chmod to 600)

ssh 1.1.1.1 -i /path/to/.pem file 
Permission denied (publickey).`

ssh user@1.1.1.1 -i /path/to/.pem file

score 1 · Answer 20 · edited Apr 08 '17 at 04:49

This is what worked for me, the fix is not mine but I would rather write it down here in case someone else has the same problem.

The original author posted it here: digital-ocean-public-access-key-denied

sudo nano /etc/ssh/sshd_config

Replace this

UsePAM yes
IgnoreUserKnownHosts no
PasswordAuthentication no

With this

UsePAM no
IgnoreUserKnownHosts no
PasswordAuthentication yes

Save the file and restart ssh

reload ssh

ssh should work now asking for a password

score 1 · Answer 21 · answered May 16 '17 at 09:41

I had the same problem as described in the question. The output from executing ssh -vvv -i id_rsa [youruser]@[yourLinode] on the client machine was similar to that described in the question. I checked all the file and directory permissions as advised in the other answers, and they were correct.

It turned out that when copying the generated file id_rsa.pub to the server machine, as file ~username/.ssh/authorized_keys, I'd accidentally omitted the word ssh-rsa from the start. Adding it solved the problem.

score 0 · Answer 22 · answered Sep 11 '23 at 11:58

In general the quickest way to understand the reason of refused SSH connections is to inspect the SSH server log (assuming you can access the log without the tested SSH connection):

sudo systemctl status sshd

One possible reason is a move of the connecting client to a new subnet (ISP etc.) combined with a very restrictive filter set up in /etc/ssh/sshd_config, that requires not only a specific pre-defined user name, but also a connection from a pre-defined IPs range:

$ cat /etc/ssh/sshd_config | grep Users
AllowUsers <user>@1.2.3.4/16

score 0 · Answer 23 · answered Oct 01 '17 at 20:16

In my case the issue was caused by copying over an .ssh directory from an older machine. Turns out that my older SSH config was using DSA keys which have since been deprecated. Switching to a new pair of keys, this time RSA-based, solved the problem for me.

SSH Permission denied (publickey)

23 Answers23

PubKeyAuthentication

Linked

Related