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