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.
.sshdirectory on my local Ubuntu machine, I have my
id_rsa.pubfiles. 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
Can anyone comment on https://stackoverflow.com/questions/51254328/unable-to-ssh-to-bitbucket I have a similar problem.
Set up your client
- Generate your key
- Configure ssh to use the key
- Copy your key to your server
ssh-copy-id -i /path/to/key.pub SERVERNAME
Your config file from step 2 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 yesto ensure
IdentityFileand no other keyfiles during authentication, which can cause issues and is not a good practice.
- 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 your files are 700 permissions (rwx------).
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 yesto limit the authentication to use the single, specified key.
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...
Just to elaborate step 2: the `IdentityFile` line in ~/.ssh/config must point to the PRIVATE key.
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.
- Generate your key
Sometimes the issue comes from permissions and ownership. For instance, if you want to log in as root,
authorized_keysmust 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
.sshand 600 for
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.
You don't need
authorized_keyson 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-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.
@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.
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 [email protected]
@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 :-)
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)`
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,
sshdwill look for
In the case of my webserver, the
/etc/ssh/sshd_confighad this line
I applied the latter, restarted my ssh daemon, and solved my problem logging in with ssh using my pubkey.
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:
On machineA, execute
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
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.