Dear List, I have a question regarding password authentication in ssh. Recently I discovered that I couldn't log on to one of my boxes anymore from a Sun. The linux box is running SuSE 9.2 stock with the latest YOU update kernel: # uname -a Linux alex-1 2.6.8-24.10-smp #1 SMP Wed Dec 22 11:54:27 UTC 2004 i686 i686 i386 GNU/Linux The error output of ssh when trying to connect to this box is this: debug1: Authentications that can continue: publickey,keyboard-interactive debug1: Next authentication method: publickey debug1: Trying private key: /ufl/chem/axa/aa/.ssh/identity debug1: Trying private key: /ufl/chem/axa/aa/.ssh/id_rsa debug1: Trying private key: /ufl/chem/axa/aa/.ssh/id_dsa debug1: No more authentication methods to try. Permission denied (publickey,keyboard-interactive). There is no problem ssh'ing into this box from another linux box called physical36.
uname -a Linux physical36 2.6.8-24.10-default #1 Wed Dec 22 11:54:27 UTC 2004 i686 athlon i386 GNU/Linux I also don't have a problem ssh'ing into physical36 from the Sun. So, I investigated the sshd_config files and they show the following differences between physical36 and alex-1 (see at the end of this message).
Apparently, I have a different version of sshd_config on both machines. Yet, both machines feature the same version of openssh:
rpm -q openssh openssh-3.9p1-3 # rpm -q openssh openssh-3.9p1-3
What would be the safest way to remedy the problem and allow password authentication again upon an ssh request from the Sun while avoiding other potential problems that come with the apparently older version of sshd_config? Thank you very much for pointers. Best regards, Alex. diff between sshd_config on physical36 and alex-1: < # $OpenBSD: sshd_config,v 1.65 2003/08/28 12:54:34 markus Exp $ ---
# $OpenBSD: sshd_config,v 1.69 2004/05/23 23:59:53 dtucker Exp $ 37a38 #MaxAuthTries 6 54c55 < #PasswordAuthentication yes
PasswordAuthentication no 58c59 < ChallengeResponseAuthentication no
#ChallengeResponseAuthentication yes 63a65 #KerberosGetAFSToken no 67c69 < #GSSAPICleanupCreds yes
#GSSAPICleanupCredentials yes 69,71c71,85 < # Set this to 'yes' to enable PAM authentication (via challenge-response) < # and session processing. Depending on your PAM configuration, this may < # bypass the setting of 'PasswordAuthentication'
# Set this to 'yes' to enable support for the deprecated 'gssapi' authentication # mechanism to OpenSSH 3.8p1. The newer 'gssapi-with-mic' mechanism is included # in this release. The use of 'gssapi' is deprecated due to the presence of # potential man-in-the-middle attacks, which 'gssapi-with-mic' is not susceptible to. #GSSAPIEnableMITMAttack no
# 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 mechanism. # Depending on your PAM configuration, this may bypass the setting of # PasswordAuthentication, PermitEmptyPasswords, and # "PermitRootLogin without-password". If you just want the PAM account and # session checks to run without PAM authentication, then enable this but set # ChallengeResponseAuthentication=no 81c95 < #KeepAlive yes
#TCPKeepAlive yes 83c97 < UsePrivilegeSeparation no
#UsePrivilegeSeparation yes