Unable to use RSA keys with SSH: Server refused our key
I am trying to use RSA public/private keys generated by PuTTY to log in to two GNU/Linux computers from Windows computers, and it works for one but not for the Ubuntu computer. The keys were generated on a Windows 7 desktop PC. From it I can log in to a Beaglebone Black running the Angstrom distro. I copied the keys to a Windows 7 laptop, and I was successful logging in to BBB from it as well, but not to the Ubuntu computer. I get the following message on the PuTTY terminal:
Using username "user".
Server refused our key
Using keyboard-interactive authentication.
I can complete the log in by entering the password, but I really want the keys to work so I can eliminate password log-ins over internet. The username is different between the two servers, but I think that is no problem, right?
I am using Ubuntu 14.04 LTS which has openssh-server installed. I copied the public key from PuTTYgen and pasted it into ~/.ssh/known_hosts. The key is on one line only, starting like this:
The ~/.ssh directory has permissions set to 700, ~/.ssh/known_hosts is set to 600.
I had high hopes when I found this post on this board, but none of those solutions have fixed the problem.
At one point I accidentally deleted the host keys in /etc/ssh/, but I uninstalled openssh-server and then reinstalled it which brought back those keys. Well, at least it seems like I got them all back.
I opened one PuTTY terminal and issued
tail -f /var/log/auth.log, and then tried to log in on a second terminal. Nothing enlightening showed up. The first message acknowledged that the password log in was succesful, nothing about the keys though.
I have been tinkering with the configuration file /etc/ssh/sshd_config trying to hit the right combination of settings, each time restarting the daemon with
service ssh restart. Below is that file as it stands now. I think I might be missing something in there, but I am running out of ideas.
# Package generated configuration file
# See the sshd_config(5) manpage for details
# What ports, IPs and protocols we listen for
# Use these options to restrict which interfaces/protocols sshd will bind to
# HostKeys for protocol version 2
#Privilege Separation is turned on for security
# Lifetime and size of ephemeral version 1 server key
# Don't read the user's ~/.rhosts and ~/.shosts files
# For this to work you will also need host keys in /etc/ssh_known_hosts
# similar for protocol version 2
# Uncomment if you don't trust ~/.ssh/known_hosts for RhostsRSAAuthentication
# To enable empty passwords, change to yes (NOT RECOMMENDED)
# Change to yes to enable challenge-response passwords (beware issues with
# some PAM modules and threads)
# Change to no to disable tunnelled clear text passwords
# Kerberos options
# GSSAPI options
# Allow client to pass locale environment variables
AcceptEnv LANG LC_*
Subsystem sftp /usr/lib/openssh/sftp-server
# Set this to 'yes' to enable PAM authentication, account processing,
# and session processing. If this is enabled, PAM authentication will
# be allowed through the ChallengeResponseAuthentication and
# PasswordAuthentication. Depending on your PAM configuration,
# PAM authentication via ChallengeResponseAuthentication may bypass
# the setting of "PermitRootLogin without-password".
# If you just want the PAM account and session checks to run without
# PAM authentication, then enable this but set PasswordAuthentication
# and ChallengeResponseAuthentication to 'no'.
As steeldriver pointed out, the RSA key goes into the authorized_keys file, not known_hosts.
I cut the key out of the known_hosts, created and pasted it into the authorized_keys.
chmod 600 authorized_keys,
sudo service ssh restart, and the server is up and running.
Thank you for your answer steeldriver.
In case you’re getting here when using a newer Ubuntu version with Openssh 8.7; and your /var/log/auth.log tail says: type ssh-rsa not in PubkeyAcceptedAlgorithms,
then most probably you’ll need to add to your /etc/ssh/sshd_config:
Behaviour with in my case Shelly on iOS is now sort of solved. It’s strange that the ssh keygen can generate keys it doesnt standard accept. Lots of puzzling again here solved by https://bbs.archlinux.org/viewtopic.php?id=270005. Thanks guys.