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
> 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
# rpm -q openssh
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
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 $
> #MaxAuthTries 6
< #PasswordAuthentication yes
> PasswordAuthentication no
< ChallengeResponseAuthentication no
> #ChallengeResponseAuthentication yes
> #KerberosGetAFSToken no
< #GSSAPICleanupCreds yes
> #GSSAPICleanupCredentials yes
< # Set this to 'yes' to enable PAM authentication (via
< # 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'
> # mechanism to OpenSSH 3.8p1. The newer 'gssapi-with-mic' mechanism is
> # in this release. The use of 'gssapi' is deprecated due to the presence
> # potential man-in-the-middle attacks, which 'gssapi-with-mic' is not
> #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
> # session checks to run without PAM authentication, then enable this but
> # ChallengeResponseAuthentication=no
< #KeepAlive yes
> #TCPKeepAlive yes
< UsePrivilegeSeparation no
> #UsePrivilegeSeparation yes