SSH Permission denied (publickey)

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

    1) What do the logs on the SSH server say about the time you have this error on the client? (`/var/log/auth.log`) 2) How did you transfer the public key to the server? Always use `ssh-copy-id` to be sure about permissions. Your home directory, the `.ssh` directory and the `authorized_keys` file have strict permission requirements. (see manpage of `sshd` (8) on `~/.ssh/authorized_keys`). 3) Did you generate a new keypair on Ubuntu? In case you reused the key from Windows - you'll have to convert it to OpenSSH format first.

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

    I see, so I misread - Please answer the questions from @gertvdijk.

  • PubKeyAuthentication

    Set up your client

    1. Generate your key
      • ssh-keygen
    2. Configure ssh to use the key
      • vim ~/.ssh/config
    3. Copy your key to your server
      • ssh-copy-id -i /path/to/ SERVERNAME

    Your config file from step 2 should have something similar to the following:

    Hostname ip-or-domain-of-server
    PubKeyAuthentication yes
    IdentityFile ./path/to/key

    You can add IdentitiesOnly yes to ensure ssh uses the IdentityFile and no other keyfiles during authentication, which can cause issues and is not a good practice.


    1. use "-vvv" option
    2. Make sure the server has your PUBLIC key (.pub).
    3. Make sure your IdentiyFile points to your PRIVATE key.
    4. Make sure your .ssh directory has 700 and your files are 700 permissions (rwx------).
    5. tail -f /var/log/auth.log (on the server) and monitor errors when you attempt to login
    6. If you have many key files, try IdentitiesOnly yes to limit the authentication to use the single, specified key.

    FYI, I created a small script at which runs the necessary steps in one go and additionally ensures all the file/directory permissions which always caused me headaches...

    Just to elaborate step 2: the `IdentityFile` line in ~/.ssh/config must point to the PRIVATE key.

    I wonder why you'd want to set files to have execute permission in step 4?

    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.

    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.

    Posterity and completeness is why.

  • 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

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

    Wish I could upvote twice, once for the folder and once for the file. Very important that permissions are exact.

    Yup, it was the permissions all along.

    this one solved my issue, thanks for that.

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

    Thanks for your help, I have edited my answer to show what happens when I type what you suggested.

    to transfer a key, on the client, use ssh-copy-id

    @bodhi.zazen Thanks, but I have already transferred the key, that isn't the problems

    "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, you are making assumptions here which are not backed by facts yet - we don't know what happened on the system.

    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.

    How to pass a passphrase in the same command

    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.

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

    The OP is not trying to use password authentication. They have some sense and are using public/private key.

  • The problem I had was it was using the wrong keys on the client. I had renamed id_rsa and 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 [email protected]

    no, use the public key

    @St3an you put the public key on the server, but when you connected like Todd is here above, you use your private key

    @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 :-)

    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.

  • 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;

    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. [email protected]). I just had to make sure the local user owned the local .ssh files (e.g. abc:abc, not root:abc)`

    This worked in my case

  • 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!

  • 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
  • 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/

    Sample output:

    ssh-rsa AAAAB3NzaSGMFZW7yB [email protected]

    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 [email protected]' >> ~/.ssh/authorized_keys

  • 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 [email protected]

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


    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.

License under CC-BY-SA with attribution

Content dated before 6/26/2020 9:53 AM