2

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.
Password:

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: ssh-rsa AAAAB...

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
Port 22
# Use these options to restrict which interfaces/protocols sshd will bind to
#ListenAddress ::
#ListenAddress 0.0.0.0
Protocol 2
# HostKeys for protocol version 2
HostKey /etc/ssh/ssh_host_rsa_key
HostKey /etc/ssh/ssh_host_dsa_key
HostKey /etc/ssh/ssh_host_ecdsa_key
HostKey /etc/ssh/ssh_host_ed25519_key
#Privilege Separation is turned on for security
UsePrivilegeSeparation yes

# Lifetime and size of ephemeral version 1 server key
KeyRegenerationInterval 3600
ServerKeyBits 1024

# Logging
SyslogFacility AUTH
LogLevel INFO

# Authentication:
LoginGraceTime 120
PermitRootLogin without-password
StrictModes no

RSAAuthentication yes
PubkeyAuthentication yes
AuthorizedKeysFile  %h/.ssh/authorized_keys

# Don't read the user's ~/.rhosts and ~/.shosts files
IgnoreRhosts yes
# For this to work you will also need host keys in /etc/ssh_known_hosts
RhostsRSAAuthentication no
# similar for protocol version 2
HostbasedAuthentication no
# Uncomment if you don't trust ~/.ssh/known_hosts for RhostsRSAAuthentication
#IgnoreUserKnownHosts yes

# To enable empty passwords, change to yes (NOT RECOMMENDED)
PermitEmptyPasswords no

# Change to yes to enable challenge-response passwords (beware issues with
# some PAM modules and threads)
ChallengeResponseAuthentication yes

# Change to no to disable tunnelled clear text passwords
#PasswordAuthentication yes

# Kerberos options
#KerberosAuthentication no
#KerberosGetAFSToken no
#KerberosOrLocalPasswd yes
#KerberosTicketCleanup yes

# GSSAPI options
#GSSAPIAuthentication no
#GSSAPICleanupCredentials yes

X11Forwarding yes
X11DisplayOffset 10
PrintMotd no
PrintLastLog yes
TCPKeepAlive yes
#UseLogin no

#MaxStartups 10:30:60
#Banner /etc/issue.net

# 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'.
UsePAM yes
2
  • The generated public key needs to go in the Ubuntu system's authorized_keys file not the known_hosts file - is that just a typo in your question? Feb 1, 2015 at 13:31
  • 1
    OMG (slapping forehead). Not a typo, steeldriver, but a real bonehead mistake. I have spent days working on this, and in 2 minutes the problem is fixed. There was no file authorized_keys so I had to create one. It seems so obvious now. I will turn this into an answer now. Thank you for your answer.
    – spanky
    Feb 1, 2015 at 16:58

2 Answers 2

3

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.

0

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:

HostKeyAlgorithms +ssh-rsa
PubkeyAcceptedAlgorithms +ssh-rsa
PubkeyAuthentication yes
PubkeyAcceptedKeyTypes=+ssh-rsa

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.

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .