Question

PuTTY + ssh - "server refused our key"

Posted May 23, 2014 150.7k views
I tried following along with this article "https://www.digitalocean.com/community/articles/how-to-create-ssh-keys-with-putty-to-connect-to-a-vps" and this article "https://www.digitalocean.com/community/articles/initial-server-setup-with-ubuntu-12-04" to set up ssh with my already existing droplet. Every time I go to putty to ssh in, I get a "server refused our key" message and then I am asked to enter in my password. I must be doing something wrong or have the wrong configuration but I'm not sure what it is. I have re-read both articles many times in order to figure out where I am (possibly) missing something.
Add a comment
vjeorn
By:
vjeorn
9 comments

These answers are provided by our Community. If you find them useful, show some love by clicking the heart. If you run into issues leave a comment, or add your own answer to help others.

×
Submit an Answer
12 answers
Tecca May 23, 2014
Re-check your permissions and ensure 0700 for ~/.ssh and 0644 for the authorized_key file in that folder. Also,

# sudo chown -R username:username /home/username

Change username to your user. Also make sure the authorized_key is inside the .ssh folder in your user's home folder, not /root/.ssh (unless you're using the key for your root user as well).
Reply Report
pay4rhyme April 16, 2015

Hi,

I was having a same problem, I read a few tutorials here in DO and I believe I know what the problem was.

My step was: create a new droplet (brand new account / droplet), not using any key and THEN generate a key after the droplet created.

The problem was, the key was not automatically assigned to the droplet (I read this on one of the tutorials). It is possible to assign the key into an existing droplet (again, read on tutorial) but I didn’t use that solution.

My solution: I deleted the key from DO’s record, delete the droplet (luckily it was still empty) and then create a new droplet, but this time, using the key since the beginning (when it was asked during droplet’s creation, whether we want to use a key or not). Basically just start from scratch, but this time I “rearranged” the steps. I was using the same key, there was a pop up saying that this key already cached but on different droplet (something along that line), hit yes, and everything works.

Just a suggestion, DO should warn the user regarding this issue. Well.. I don’t really think that this is an issue / bug, but.. I think it’d be nice to know this since the beginning. For example, on this tutorial:

https://www.digitalocean.com/community/tutorials/how-to-create-your-first-digitalocean-droplet-virtual-server

On this part “Step Seven-Select SSH Keys (Optional)” >> It should be clear that it would take more, extra effort if we choose to create a key later (manually assign it to the droplet).

Again, just a suggestion. HTH

Reply Report
  • hjchin July 19, 2016

    I thought the same and it is really caused by that. I removed the droplet and create another new one and assign public key to it. Then the SSH connection just works without password.

    Reply Report
  • FruitBowlDigital March 16, 2017

    Agreed, I was facing the same issue doing everything from scratch and adding the keys in the beginning worked. Thanks!

    Reply Report
  • felixmpa March 23, 2017

    If someone is here from BITHOST.io (Powered by Digital Ocean) - I had the same problem.
    After minutes trying to connect, So I just deleted the current servername and created SSH key and then server using this ssh key that I created before.

    “Success”
    thanks.

    Reply Report
  • bogdan4adrian May 19, 2020

    Yes, that is the problem. the key you create after the droplet creation is not associated to that droplet so it cannot work. create the kay whn you choose your droplet configuration

    Reply Report
  • sivaRay February 1, 2021

    It’s 2021! Still this answer is relevant.

    Reply Report
mjaydee July 12, 2015

CORE OS Solution:

If using coreos set the username ‘core’ instead of 'root’.

Once you’ve logged in you can use 'sudo -i’ to become root.

Reply Report
kkobashi March 23, 2017

Digital Ocean needs to put in their dashboard a note saying that the SSH keys must be created prior to creating a new droplet! I wasted way too much time trying to get this to work and its even worse when you got a droplet already created and apps setup.

Here’s what I did for those who need help on this issue. I used Mobaxterm and generated SSH keys at the local terminal.

ssh-keygen -t rsa (accept all defaults)
cd /home/mobaxterm/.ssh
cat id_rsa.pub

Copy and paste the output into Add SSH form box
Create SSH session w/advanced settings pointing at private key
Create SFTP session w/advanced settings pointing at private key

To determine folder locations on the windows box that correlate with Mobaxterm, look at your Settings | Configuration | Persistent home directory and click on the folder to see the Windows directory its located in. Its usually your C:/Users/uername/Documents/Mobaxterm/home/.ssh

Reply Report
Velcapitan December 16, 2014

Digital Ocean needs to improve these tutorials. Digital Ocean needs to improve them not their customers. Your customer’s follow them only to learn that they lack detail, skip steps, or just plain suck. It leads to a lot of non-value adding activity.

Reply Report
  • knappsych September 29, 2015

    Seriously. It’s really frustrating. Especially, when you still can’t get it to work after following users’ suggestions destroying and recreating droplets. I even tried creating the file known-hosts from the root directory in my user directory to no avail.

    Reply Report
TonyTsang May 23, 2014
These are the steps to setup putty ssh login profile, hope this help
=========================================
ssh-keygen -t rsa -b 2048 -f mykey -C [me@domain.com < your comment]
cat mykey.pub >> ~/.ssh/authorized_keys
=========================================
download mykey
download PuTTYgen from http://www.chiark.greenend.org.uk/~sgtatham/putty/download.html
start puttygen
go to conversion > import key
select downloaded mykey
Then [Save private key], you can change key comment if needed
=========================================
Start putty
Key in the host name/ip address together with port, if non standard port is used
Then go to [connection] > [ssh] > [auth]
Click [Browse] of [Private key file for authentication], choose the previous generated [mykey.ppk]
Go back to [Session]
Enter the name you want at [Saved sessions] field, then [Save]
After all that, hit [Open]
Enter your user name when prompted, your should be logged in now
=========================================
Remeber to remove the generated key files from the server
rm mykey mykey.pub
=========================================
If everything is good, follow the article you mentioned to disable the ssh password login.
Reply Report
hargahot January 24, 2015

Just check your secure log. In my case (Centos) the file is locate in /var/log/secure.

In my log:
Jan 24 16:52:40 server sshd[19625]: Authentication refused: bad ownership or modes for directory /home/user

After I changed the modes /home/user from 0755 to 0700 I can login with the key.

Reply Report
stevepatco January 16, 2016

My problem was found in the var/ logs/secuirty apparently, i used a windows text editor that caused a /r switch to be entered into the /bin/bash command when attempting to login. tech support gave me a command to reset it. I will look around to find it.

usermod -s /bin/bash root

Reply Report
PlayPassMedia April 17, 2016

I had same problem, tried everything but kept refusing my key, or prompting me for a password in addition to the key.

Turns out i kept accidentally creating a droplet using CoreOS instead of CentOS…not sure what the deal is with CoreOS…but glad i don’t need to use that right now or i would be in for trouble or switching to a i different service.

Reply Report
gryphonitsolutions April 27, 2016

If you just upgraded Ubuntu 15.04/10 to Ubuntu 16.04 LTS (or otherwise upgraded OpenSSH from v6.9 to v7.0 you may be getting the ssh refusal because of changes in OpenSSH.

I was specifically getting this error in the /var/log/auth.log (via Webmin): sshd[2444]: userauth_pubkey: key type ssh-dss not in PubkeyAcceptedKeyTypes [preauth].

For this specific error, you need to add “PubkeyAcceptedKeyTypes=+ssh-dss” (without the quotations) to the bottom of your /etc/ssh/sshd_config file.

See: https://superuser.com/questions/1016989/ssh-dsa-keys-no-longer-work-for-password-less-authentication?lq=1

Reply Report
Previous 1 2 Next
Load More Answers

Looking for something else?

Ask a new question Search for more help