Take the 2-minute tour ×
Server Fault is a question and answer site for professional system and network administrators. It's 100% free, no registration required.

So I have my home computer & a server. I want the server to be able to SSH into my home computer w/out a password. I have followed various tutorials and can ssh from home to server with no password. Everything works fine. When I try to reverse the process and ssh from server to home I get a permission denied (publickey) error. I can log in to both machines using a password just fine.

The relevant bits from a verbose attempt are as follows:

   debug1: Found key in /root/.ssh/known_hosts:1
debug1: ssh_rsa_verify: signature correct
debug1: SSH2_MSG_NEWKEYS sent
debug1: expecting SSH2_MSG_NEWKEYS
debug1: SSH2_MSG_NEWKEYS received
debug1: SSH2_MSG_SERVICE_REQUEST sent
debug1: SSH2_MSG_SERVICE_ACCEPT received
debug1: Authentications that can continue: publickey,keyboard-interactive
debug1: Next authentication method: publickey
debug1: Trying private key: /root/.ssh/identity
debug1: Offering public key: /root/.ssh/id_rsa
debug1: Authentications that can continue: publickey,keyboard-interactive
debug1: Trying private key: /root/.ssh/id_dsa
debug1: Next authentication method: keyboard-interactive
debug1: Authentications that can continue: publickey,keyboard-interactive
debug1: No more authentication methods to try.
Permission denied (publickey,keyboard-interactive).

My /etc/ssh/sshd_config file on the home PC looks like this:

# 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
#Privilege Separation is turned on for security
UsePrivilegeSeparation yes

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

# Logging
SyslogFacility AUTH
LogLevel INFO

# Authentication:
LoginGraceTime 120
PermitRootLogin yes
StrictModes yes

RSAAuthentication yes
PubkeyAuthentication yes
AuthorizedKeysFile  ~/.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 yes

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

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

The home PC is running Ubuntu and the server is CentOS.

share|improve this question
add comment

4 Answers 4

up vote 1 down vote accepted

Your AuthorizedKeysFile line should read AuthorizedKeysFile .ssh/authorized_keys. Also make sure the permissions on your .ssh directory are 700 and the permissions on your authorized_keys file is 600.

share|improve this answer
    
The path to the authorized_keys file was definitely my problem. Thank you so much! –  binaryorganic Sep 26 '11 at 20:26
add comment

BinaryOrganic... I looked at your post and saw you your /etc/ssh/sshd_config file has an entry setting which is causing your failure and that error message.

In the past I and others have had no problem using x2go client logins to Ubuntu/Debian x2goservers.

However, sometime in the past year or two of Ubuntu & Debian OS updates something changed which caused the normal x2goclient session profile that requires the UserID -and- Password to be entered would fail giving an error message on the client that says:

Access denied. Authentication that can continue: publickey,keyboard-interactive

I finally found out the reason for this change in behavior and here's how to fix it.

Get a terminal session with your x2goserver and edit /etc/ssh/sshd_config

sudo nano /etc/ssh/sshd_config

in /etc/ssh/sshd_config (example was copied from Ubuntu 12.04) you will see the following entries:

*# 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 no**

To fix this CHANGE PasswordAuthentication to "yes" and save the file and restart ssh

sudo /etc/init.d/ssh restart

REASON for the failure & change of behavior from previous/older versions of Ubuntu. I installed several older versions of Ubuntu going back to Ubuntu 9.10 and found that the installations of the Ubuntu Server changed the content of the /etc/ssh/sshd_config file!

In older systems the entry for PasswordAuthentication either said:

# Change to no to disable tunnelled clear text passwords

# PasswordAuthentication no

where the PasswordAuthentication line was commented out ... which then defaulted it to "YES"

-or-

the Password Authentication line was actually uncommented BUT set to "YES"

# Change to no to disable tunnelled clear text passwords

PasswordAuthentication yes

So those older OS versions and x2go would work using login ID's and Passwords.

Sometime during one of the Ubuntu 11.x releases the PasswordAuthentication entry was actually changed to "no" as is the case in Ubuntu 12.04 servers and the line was left not commented out so it was active...

# Change to no to disable tunnelled clear text passwords

PasswordAuthentication no

That is what caused the failure of x2go logins using passwords and would present the user with that error message:

Access denied. Authentication that can continue: publickey,keyboard-interactive

I've made this change now and no longer see the problem on my servers so I wanted to share this info as my google searches on that error message have shown alot of people posting about the same error when using lots of other remote access tools (freenx, x2go, NoMachine NX etc). Hope this helps you too.

share|improve this answer
add comment

I suggest you don't ssh as user root - if you do you might have to work around good configuration issues on one or both hosts. Here are some changes I suggest:

PermitRootLogin yes

That should really be a no. It's a sane additional layer of protection.

RSAAuthentication yes

Make that a no. It refers to ssh v1 which you don't want if you have any say.

PermitEmptyPasswords yes

Change to no.

ChallengeResponseAuthentication yes

If you are doing public-key then you don't have to enable CHAP, so don't.

Consider these:

MaxAuthTries 3

Make an attacker re do they initial handshaking as a penalty for three failed attempts in a session

MaxStartups 5 # max number of concurrent ssh sessions, for a home user 5 should do

You should probably change this line:

AuthorizedKeysFile ~/.ssh/authorized_keys

to this

AuthorizedKeysFile .ssh/authorized_keys

share|improve this answer
add comment

Did you create a user key on the server and then copy THAT public key into the .ssh/authorized_keys on your home box?

easier option is to create your key with the usual 'ssh-keygen ...' command, then use the 'ssh-copy-id' command to move the public key over to another machine.

ssh-keygen (follow the prompts)
ssh-copy-id -i ~/.ssh/id_rsa.pub me@home_system

change the id_rsa.pub to whichever key method you chose (cmd line options for ssh-keygen) of course.

Remember that ssh keys are one way... FROM here TO there. so if you want to use passwordless logins going the other way, you have to set that up too.

share|improve this answer
add comment

Your Answer

 
discard

By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.