ssh to SLES11SP2: "Permission denied (public key)"

SUSE Linux Enterprise Server SLES Networking
1

I cannot reach my SLES11SP2 host with ssh since a couple of days. Either with putty on win7 or ssh-command from other linux hosts - in both cases I receive “Permission denied (public key)”.
ssh -v shows that authentication method “keyboard-interactive” is not offered anymore.
“debug1: Authentications that can continue: publickey”

The host runs as virtual machine on vmware esxi. The console of esxi is the only method to access the host at the moment. Configuration files like /etc/ssh/* and /etc/pam.d/sshd do not show any recent modification dates.

To get the issue resolved I decided to restore from a full backup older than my last successful ssh login. To my surprise the problem remained unchanged. Did someone experience a similar problem?

I already stopped ntp and manually turned back system time for 1 month - just in case it is a matter of expired functionality - but this didn’t help.

2

On 22/08/17 15:34, bernbert wrote:
[color=blue]

I cannot reach my SLES11SP2 host with ssh since a couple of days. Either
with putty on win7 or ssh-command from other linux hosts - in both cases
I receive “Permission denied (public key)”.
ssh -v shows that authentication method “keyboard-interactive” is not
offered anymore.
-“debug1: Authentications that can continue: publickey”-

The host runs as virtual machine on vmware esxi. The console of esxi is
the only method to access the host at the moment. Configuration files
like /etc/ssh/* and /etc/pam.d/sshd do not show any recent modification
dates.

To get the issue resolved I decided to restore from a full backup older
than my last successful ssh login. To my surprise the problem remained
unchanged. Did someone experience a similar problem?

I already stopped ntp and manually turned back system time for 1 month -
just in case it is a matter of expired functionality - but this didn’t
help.[/color]

Obviously something changed somewhere a couple of days ago so the
question is what and/or where?

Since SUSE Linux Enterprise Server (SLES) 11 SP2 is no longer supported
by SUSE (with SLES11 SP4 the latest available release of SLES11) it’s
unlikely that you’ve installed an updated package so if server-side it’s
likely to be a configuration change. Are you the only person who has
admin access to the server?

I’d be surprised if something other than changing the public key was the
cause of this client-side if you’re using the same PuTTY configuration
(hostname/IP address, username, etc.).

Can you post the (sanitised) output from “ssh -vv”?

HTH.

Simon
SUSE Knowledge Partner

If you find this post helpful and are logged into the web interface,
please show your appreciation and click on the star below. Thanks.

3

On 08/22/2017 08:34 AM, bernbert wrote:[color=blue]

I cannot reach my SLES11SP2 host with ssh since a couple of days. Either
with putty on win7 or ssh-command from other linux hosts - in both cases
I receive “Permission denied (public key)”.
ssh -v shows that authentication method “keyboard-interactive” is not
offered anymore.
-“debug1: Authentications that can continue: publickey”-

The host runs as virtual machine on vmware esxi. The console of esxi is
the only method to access the host at the moment. Configuration files
like /etc/ssh/* and /etc/pam.d/sshd do not show any recent modification
dates.[/color]

Which user are you trying to access via SSH? If’root’, have you tried a
non-root user who has a password? With the ‘Authentication that can
continue’ line above, is that the same from all source systems? Was that
both before and after your restore of the backup?
[color=blue]

To get the issue resolved I decided to restore from a full backup older
than my last successful ssh login. To my surprise the problem remained
unchanged. Did someone experience a similar problem?[/color]

You restore everything on the system, then? Home directories and
everything as well? Does the target user have a ~/.ssh directory that may
have an authorized_keys file or something, or a ‘config’ file within there?

–
Good luck.

If you find this post helpful and are logged into the web interface,
show your appreciation and click on the star below.

If you want to send me a private message, please let me know in the
forum as I do not use the web interface often.

4

[QUOTE=bernbert;39218]I cannot reach my SLES11SP2 host with ssh since a couple of days. Either with putty on win7 or ssh-command from other linux hosts - in both cases I receive “Permission denied (public key)”.
ssh -v shows that authentication method “keyboard-interactive” is not offered anymore.
“debug1: Authentications that can continue: publickey”[/QUOTE]

It’s not unusual for “keyboard-interactive” authentication method to be disabled once public key authentication has been setup.

If you were able to use SSH public key authentication both via PuTTY and via ssh from other Linux hosts, and no longer can, it is unlikely that it is related to the private key or the hosts from which you are trying to gain access as these are two different sources. I would suspect that something has happened to your public key on your SLES11 SP2 host.

There are a couple of things you can try:

[LIST=1]
[]Using the console via VMware enable authentication method “keyboard-interactive” and see if you can then login.
[]Go through the process of setting up public key authentication again.
[/LIST]

5

[QUOTE=smflood;39219]On 22/08/17 15:34, bernbert wrote:
[color=blue]

I cannot reach my SLES11SP2 host with ssh since a couple of days. Either
with putty on win7 or ssh-command from other linux hosts - in both cases
I receive “Permission denied (public key)”.
ssh -v shows that authentication method “keyboard-interactive” is not
offered anymore.
-“debug1: Authentications that can continue: publickey”-

The host runs as virtual machine on vmware esxi. The console of esxi is
the only method to access the host at the moment. Configuration files
like /etc/ssh/* and /etc/pam.d/sshd do not show any recent modification
dates.

To get the issue resolved I decided to restore from a full backup older
than my last successful ssh login. To my surprise the problem remained
unchanged. Did someone experience a similar problem?

I already stopped ntp and manually turned back system time for 1 month -
just in case it is a matter of expired functionality - but this didn’t
help.[/color]

Obviously something changed somewhere a couple of days ago so the
question is what and/or where?

Since SUSE Linux Enterprise Server (SLES) 11 SP2 is no longer supported
by SUSE (with SLES11 SP4 the latest available release of SLES11) it’s
unlikely that you’ve installed an updated package so if server-side it’s
likely to be a configuration change. Are you the only person who has
admin access to the server?

I’d be surprised if something other than changing the public key was the
cause of this client-side if you’re using the same PuTTY configuration
(hostname/IP address, username, etc.).

Can you post the (sanitised) output from “ssh -vv”?

HTH.

Simon
SUSE Knowledge Partner

If you find this post helpful and are logged into the web interface,
please show your appreciation and click on the star below. Thanks.
------------------------------------------------------------------------[/QUOTE]

Hi Simon,
here is the output from “ssh -vv”. I have replaced the original hostname of the SLES11 host with “sles11-sshd”.

root@linux-ssh-client:~# ssh -vv sles11-sshd
OpenSSH_6.7p1 Debian-5+deb8u3, OpenSSL 1.0.1t 3 May 2016
debug1: Reading configuration data /etc/ssh/ssh_config
debug1: /etc/ssh/ssh_config line 19: Applying options for *
debug2: ssh_connect: needpriv 0
debug1: Connecting to sles11-sshd [192.168.229.147] port 22.
debug1: Connection established.
debug1: permanently_set_uid: 0/0
debug1: key_load_public: No such file or directory
debug1: identity file /root/.ssh/id_rsa type -1
debug1: key_load_public: No such file or directory
debug1: identity file /root/.ssh/id_rsa-cert type -1
debug1: key_load_public: No such file or directory
debug1: identity file /root/.ssh/id_dsa type -1
debug1: key_load_public: No such file or directory
debug1: identity file /root/.ssh/id_dsa-cert type -1
debug1: key_load_public: No such file or directory
debug1: identity file /root/.ssh/id_ecdsa type -1
debug1: key_load_public: No such file or directory
debug1: identity file /root/.ssh/id_ecdsa-cert type -1
debug1: key_load_public: No such file or directory
debug1: identity file /root/.ssh/id_ed25519 type -1
debug1: key_load_public: No such file or directory
debug1: identity file /root/.ssh/id_ed25519-cert type -1
debug1: Enabling compatibility mode for protocol 2.0
debug1: Local version string SSH-2.0-OpenSSH_6.7p1 Debian-5+deb8u3
debug1: Remote protocol version 2.0, remote software version OpenSSH_5.1
debug1: match: OpenSSH_5.1 pat OpenSSH_5* compat 0x0c000000
debug2: fd 3 setting O_NONBLOCK
debug1: SSH2_MSG_KEXINIT sent
debug1: SSH2_MSG_KEXINIT received
debug2: kex_parse_kexinit: curve25519-sha256@libssh.org,ecdh-sha2-nistp256,ecdh-sha2-nistp384,ecdh-sha2-nistp521,diffie-hellman-group-exchange-sha256,diffie-hellman-group14-sha1,diffie-hellman-group-exchange-sha1,diffie-hellman-group1-sha1
debug2: kex_parse_kexinit: ssh-rsa-cert-v01@openssh.com,ssh-rsa-cert-v00@openssh.com,ssh-rsa,ecdsa-sha2-nistp256-cert-v01@openssh.com,ecdsa-sha2-nistp384-cert-v01@openssh.com,ecdsa-sha2-nistp521-cert-v01@openssh.com,ssh-ed25519-cert-v01@openssh.com,ssh-dss-cert-v01@openssh.com,ssh-dss-cert-v00@openssh.com,ecdsa-sha2-nistp256,ecdsa-sha2-nistp384,ecdsa-sha2-nistp521,ssh-ed25519,ssh-dss
debug2: kex_parse_kexinit: aes128-ctr,aes192-ctr,aes256-ctr,aes128-gcm@openssh.com,aes256-gcm@openssh.com,chacha20-poly1305@openssh.com,arcfour256,arcfour128,aes128-cbc,3des-cbc,blowfish-cbc,cast128-cbc,aes192-cbc,aes256-cbc,arcfour,rijndael-cbc@lysator.liu.se
debug2: kex_parse_kexinit: aes128-ctr,aes192-ctr,aes256-ctr,aes128-gcm@openssh.com,aes256-gcm@openssh.com,chacha20-poly1305@openssh.com,arcfour256,arcfour128,aes128-cbc,3des-cbc,blowfish-cbc,cast128-cbc,aes192-cbc,aes256-cbc,arcfour,rijndael-cbc@lysator.liu.se
debug2: kex_parse_kexinit: umac-64-etm@openssh.com,umac-128-etm@openssh.com,hmac-sha2-256-etm@openssh.com,hmac-sha2-512-etm@openssh.com,hmac-sha1-etm@openssh.com,umac-64@openssh.com,umac-128@openssh.com,hmac-sha2-256,hmac-sha2-512,hmac-sha1,hmac-md5-etm@openssh.com,hmac-ripemd160-etm@openssh.com,hmac-sha1-96-etm@openssh.com,hmac-md5-96-etm@openssh.com,hmac-md5,hmac-ripemd160,hmac-ripemd160@openssh.com,hmac-sha1-96,hmac-md5-96
debug2: kex_parse_kexinit: umac-64-etm@openssh.com,umac-128-etm@openssh.com,hmac-sha2-256-etm@openssh.com,hmac-sha2-512-etm@openssh.com,hmac-sha1-etm@openssh.com,umac-64@openssh.com,umac-128@openssh.com,hmac-sha2-256,hmac-sha2-512,hmac-sha1,hmac-md5-etm@openssh.com,hmac-ripemd160-etm@openssh.com,hmac-sha1-96-etm@openssh.com,hmac-md5-96-etm@openssh.com,hmac-md5,hmac-ripemd160,hmac-ripemd160@openssh.com,hmac-sha1-96,hmac-md5-96
debug2: kex_parse_kexinit: none,zlib@openssh.com,zlib
debug2: kex_parse_kexinit: none,zlib@openssh.com,zlib
debug2: kex_parse_kexinit:
debug2: kex_parse_kexinit:
debug2: kex_parse_kexinit: first_kex_follows 0
debug2: kex_parse_kexinit: reserved 0
debug2: kex_parse_kexinit: diffie-hellman-group-exchange-sha256,diffie-hellman-group-exchange-sha1,diffie-hellman-group14-sha1,diffie-hellman-group1-sha1
debug2: kex_parse_kexinit: ssh-rsa,ssh-dss
debug2: kex_parse_kexinit: aes128-cbc,3des-cbc,blowfish-cbc,cast128-cbc,arcfour128,arcfour256,arcfour,aes192-cbc,aes256-cbc,rijndael-cbc@lysator.liu.se,aes128-ctr,aes192-ctr,aes256-ctr
debug2: kex_parse_kexinit: aes128-cbc,3des-cbc,blowfish-cbc,cast128-cbc,arcfour128,arcfour256,arcfour,aes192-cbc,aes256-cbc,rijndael-cbc@lysator.liu.se,aes128-ctr,aes192-ctr,aes256-ctr
debug2: kex_parse_kexinit: hmac-md5,hmac-sha1,umac-64@openssh.com,hmac-ripemd160,hmac-ripemd160@openssh.com,hmac-sha1-96,hmac-md5-96
debug2: kex_parse_kexinit: hmac-md5,hmac-sha1,umac-64@openssh.com,hmac-ripemd160,hmac-ripemd160@openssh.com,hmac-sha1-96,hmac-md5-96
debug2: kex_parse_kexinit: none,zlib@openssh.com,zlib
debug2: kex_parse_kexinit: none,zlib@openssh.com,zlib
debug2: kex_parse_kexinit:
debug2: kex_parse_kexinit:
debug2: kex_parse_kexinit: first_kex_follows 0
debug2: kex_parse_kexinit: reserved 0
debug2: mac_setup: setup umac-64@openssh.com
debug1: kex: server->client aes128-ctr umac-64@openssh.com none
debug2: mac_setup: setup umac-64@openssh.com
debug1: kex: client->server aes128-ctr umac-64@openssh.com none
debug1: SSH2_MSG_KEX_DH_GEX_REQUEST(1024<3072<8192) sent
debug1: expecting SSH2_MSG_KEX_DH_GEX_GROUP
debug2: bits set: 1557/3072
debug1: SSH2_MSG_KEX_DH_GEX_INIT sent
debug1: expecting SSH2_MSG_KEX_DH_GEX_REPLY
debug1: Server host key: RSA e0:c0:a1:84:c2:6a:70:eb:fe:ed:61:06:00:fe:96:2e
debug1: Host ‘sles11-sshd’ is known and matches the RSA host key.
debug1: Found key in /root/.ssh/known_hosts:2
debug2: bits set: 1547/3072
debug2: kex_derive_keys
debug2: set_newkeys: mode 1
debug1: SSH2_MSG_NEWKEYS sent
debug1: expecting SSH2_MSG_NEWKEYS
debug2: set_newkeys: mode 0
debug1: SSH2_MSG_NEWKEYS received
debug1: SSH2_MSG_SERVICE_REQUEST sent
debug2: service_accept: ssh-userauth
debug1: SSH2_MSG_SERVICE_ACCEPT received
debug2: key: /root/.ssh/id_rsa ((nil)),
debug2: key: /root/.ssh/id_dsa ((nil)),
debug2: key: /root/.ssh/id_ecdsa ((nil)),
debug2: key: /root/.ssh/id_ed25519 ((nil)),
debug1: Authentications that can continue: publickey
debug1: Next authentication method: publickey
debug1: Trying private key: /root/.ssh/id_rsa
debug1: Trying private key: /root/.ssh/id_dsa
debug1: Trying private key: /root/.ssh/id_ecdsa
debug1: Trying private key: /root/.ssh/id_ed25519
debug2: we did not send a packet, disable method
debug1: No more authentication methods to try.
Permission denied (publickey).

On the target machine there is only a “known_hosts” file under /root/.ssh - no key files.

6

root is the only user who regularly does ssh. There is no other (interactive) local user.
Since there is samba with ADS-security running on this host I can also use a WindowsDomain-User for testing. I receive the same error message. I can guarantee that this worked before because I did an initinal ssh-login for every Domain-User to have the homedir created.

Restores are 100% independant. They hold the complete virtual disk. Restore goes like this

  • create new VM out of the backup
  • stop original VM
  • start new VM

The .ssh-folder has only one file
/root/.ssh/known_hosts

My idea was to keep it simple for stability reasons :frowning:

7

[QUOTE=KBOYLE;39224]It’s not unusual for “keyboard-interactive” authentication method to be disabled once public key authentication has been setup.

If you were able to use SSH public key authentication both via PuTTY and via ssh from other Linux hosts, and no longer can, it is unlikely that it is related to the private key or the hosts from which you are trying to gain access as these are two different sources. I would suspect that something has happened to your public key on your SLES11 SP2 host.

There are a couple of things you can try:

[LIST=1]
[]Using the console via VMware enable authentication method “keyboard-interactive” and see if you can then login.
[]Go through the process of setting up public key authentication again.
[/LIST][/QUOTE]

There might be some misunderstanding here. I never set up publickey authentication in the past. I never created keypairs. Therefore I never was able to login to any of my linux hosts with public keys.
I never used an authentication method for ssh other than keyboard-interacitve.

/etc/ssh/sshd_config was last changed more than 18 months ago!

8

[QUOTE=bernbert;39239]There might be some misunderstanding here. I never set up publickey authentication in the past. I never created keypairs. Therefore I never was able to login to any of my linux hosts with public keys.
I never used an authentication method for ssh other than keyboard-interacitve.[/QUOTE]
My misunderstanding: I apologize!

That was the next question I was going to ask.

[QUOTE][COLOR=#333333][FONT=Arial]debug1: Authentications that can continue: publickey[/FONT][/COLOR]
[COLOR=#333333][FONT=Arial]debug1: Next authentication method: publickey[/FONT][/COLOR]
[COLOR=#333333][FONT=Arial]debug1: Trying private key: /root/.ssh/id_rsa[/FONT][/COLOR]
[COLOR=#333333][FONT=Arial]debug1: Trying private key: /root/.ssh/id_dsa[/FONT][/COLOR]
[COLOR=#333333][FONT=Arial]debug1: Trying private key: /root/.ssh/id_ecdsa[/FONT][/COLOR]
[COLOR=#333333][FONT=Arial]debug1: Trying private key: /root/.ssh/id_ed25519[/FONT][/COLOR]
[COLOR=#333333][FONT=Arial]debug2: we did not send a packet, disable method[/FONT][/COLOR]
[COLOR=#333333][FONT=Arial]debug1: No more authentication methods to try.[/FONT][/COLOR]
[COLOR=#333333][FONT=Arial]Permission denied (publickey).[/FONT][/COLOR]
[/QUOTE]
The above output you provided for Simon shows that the only authentication method supported is publickey. I would think that would be determined by /etc/ssh/sshd_config.

[LIST]
[]Can you compare sshd_config to one from another server where ssh is able to authenticate?
[]I hate to ask the obvious question: Is ChallengeResponseAuthentication set to “no”?
[/LIST]

9

bernbert Wrote in message:
[color=blue]

here is the output from “ssh -vv”. I have replaced the original hostname
of the SLES11 host with “sles11-sshd”.[/color]

Okay, I’ll comment below on various bits of the output.
[color=blue]

root@linux-ssh-client:~# ssh -vv sles11-sshd[/color]

Since you’re root on linux-ssh-client and are not specifying a
username in your ssh command it will try to connect to
sles11-sshd as root - note I’m not trying to be clever but just
flagging this in case it’s important.
[color=blue]

OpenSSH_6.7p1 Debian-5+deb8u3, OpenSSL 1.0.1t 3 May 2016
debug1: Reading configuration data /etc/ssh/ssh_config
debug1: /etc/ssh/ssh_config line 19: Applying options for *
debug2: ssh_connect: needpriv 0
debug1: Connecting to sles11-sshd [192.168.229.147] port 22.
debug1: Connection established.[/color]

It successfully makes a connection to sles11-sshd.
[color=blue]

debug1: permanently_set_uid: 0/0
debug1: key_load_public: No such file or directory
debug1: identity file /root/.ssh/id_rsa type -1
debug1: key_load_public: No such file or directory
debug1: identity file /root/.ssh/id_rsa-cert type -1
debug1: key_load_public: No such file or directory
debug1: identity file /root/.ssh/id_dsa type -1
debug1: key_load_public: No such file or directory
debug1: identity file /root/.ssh/id_dsa-cert type -1
debug1: key_load_public: No such file or directory
debug1: identity file /root/.ssh/id_ecdsa type -1
debug1: key_load_public: No such file or directory
debug1: identity file /root/.ssh/id_ecdsa-cert type -1
debug1: key_load_public: No such file or directory
debug1: identity file /root/.ssh/id_ed25519 type -1
debug1: key_load_public: No such file or directory
debug1: identity file /root/.ssh/id_ed25519-cert type -1[/color]

It doesn’t find a local public key file.
[color=blue]

debug1: Enabling compatibility mode for protocol 2.0
debug1: Local version string SSH-2.0-OpenSSH_6.7p1 Debian-5+deb8u3
debug1: Remote protocol version 2.0, remote software version
OpenSSH_5.1
debug1: match: OpenSSH_5.1 pat OpenSSH_5* compat 0x0c000000
debug2: fd 3 setting O_NONBLOCK
debug1: SSH2_MSG_KEXINIT sent
debug1: SSH2_MSG_KEXINIT received
debug2: kex_parse_kexinit:
curve25519-sha256@libssh.org,ecdh-sha2-nistp256,ecdh-sha2-nistp384,ecdh-sha2-nistp521,diffie-hellman-group-exchange-sha256,diffie-hellman-group14-sha1,diffie-hellman-group-exchange-sha1,diffie-hellman-group1-sha1
debug2: kex_parse_kexinit:
ssh-rsa-cert-v01@openssh.com,ssh-rsa-cert-v00@openssh.com,ssh-rsa,ecdsa-sha2-nistp256-cert-v01@openssh.com,ecdsa-sha2-nistp384-cert-v01@openssh.com,ecdsa-sha2-nistp521-cert-v01@openssh.com,ssh-ed25519-cert-v01@openssh.com,ssh-dss-cert-v01@openssh.com,ssh-dss-cert-v00@openssh.com,ecdsa-sha2-nistp256,ecdsa-sha2-nistp384,ecdsa-sha2-nistp521,ssh-ed25519,ssh-dss
debug2: kex_parse_kexinit:
aes128-ctr,aes192-ctr,aes256-ctr,aes128-gcm@openssh.com,aes256-gcm@openssh.com,chacha20-poly1305@openssh.com,arcfour256,arcfour128,aes128-cbc,3des-cbc,blowfish-cbc,cast128-cbc,aes192-cbc,aes256-cbc,arcfour,rijndael-cbc@lysator.liu.se
debug2: kex_parse_kexinit:
aes128-ctr,aes192-ctr,aes256-ctr,aes128-gcm@openssh.com,aes256-gcm@openssh.com,chacha20-poly1305@openssh.com,arcfour256,arcfour128,aes128-cbc,3des-cbc,blowfish-cbc,cast128-cbc,aes192-cbc,aes256-cbc,arcfour,rijndael-cbc@lysator.liu.se
debug2: kex_parse_kexinit:
umac-64-etm@openssh.com,umac-128-etm@openssh.com,hmac-sha2-256-etm@openssh.com,hmac-sha2-512-etm@openssh.com,hmac-sha1-etm@openssh.com,umac-64@openssh.com,umac-128@openssh.com,hmac-sha2-256,hmac-sha2-512,hmac-sha1,hmac-md5-etm@openssh.com,hmac-ripemd160-etm@openssh.com,hmac-sha1-96-etm@openssh.com,hmac-md5-96-etm@openssh.com,hmac-md5,hmac-ripemd160,hmac-ripemd160@openssh.com,hmac-sha1-96,hmac-md5-96
debug2: kex_parse_kexinit:
umac-64-etm@openssh.com,umac-128-etm@openssh.com,hmac-sha2-256-etm@openssh.com,hmac-sha2-512-etm@openssh.com,hmac-sha1-etm@openssh.com,umac-64@openssh.com,umac-128@openssh.com,hmac-sha2-256,hmac-sha2-512,hmac-sha1,hmac-md5-etm@openssh.com,hmac-ripemd160-etm@openssh.com,hmac-sha1-96-etm@openssh.com,hmac-md5-96-etm@openssh.com,hmac-md5,hmac-ripemd160,hmac-ripemd160@openssh.com,hmac-sha1-96,hmac-md5-96
debug2: kex_parse_kexinit: none,zlib@openssh.com,zlib
debug2: kex_parse_kexinit: none,zlib@openssh.com,zlib
debug2: kex_parse_kexinit:
debug2: kex_parse_kexinit:
debug2: kex_parse_kexinit: first_kex_follows 0
debug2: kex_parse_kexinit: reserved 0
debug2: kex_parse_kexinit:
diffie-hellman-group-exchange-sha256,diffie-hellman-group-exchange-sha1,diffie-hellman-group14-sha1,diffie-hellman-group1-sha1
debug2: kex_parse_kexinit: ssh-rsa,ssh-dss
debug2: kex_parse_kexinit:
aes128-cbc,3des-cbc,blowfish-cbc,cast128-cbc,arcfour128,arcfour256,arcfour,aes192-cbc,aes256-cbc,rijndael-cbc@lysator.liu.se,aes128-ctr,aes192-ctr,aes256-ctr
debug2: kex_parse_kexinit:
aes128-cbc,3des-cbc,blowfish-cbc,cast128-cbc,arcfour128,arcfour256,arcfour,aes192-cbc,aes256-cbc,rijndael-cbc@lysator.liu.se,aes128-ctr,aes192-ctr,aes256-ctr
debug2: kex_parse_kexinit:
hmac-md5,hmac-sha1,umac-64@openssh.com,hmac-ripemd160,hmac-ripemd160@openssh.com,hmac-sha1-96,hmac-md5-96
debug2: kex_parse_kexinit:
hmac-md5,hmac-sha1,umac-64@openssh.com,hmac-ripemd160,hmac-ripemd160@openssh.com,hmac-sha1-96,hmac-md5-96
debug2: kex_parse_kexinit: none,zlib@openssh.com,zlib
debug2: kex_parse_kexinit: none,zlib@openssh.com,zlib
debug2: kex_parse_kexinit:
debug2: kex_parse_kexinit:
debug2: kex_parse_kexinit: first_kex_follows 0
debug2: kex_parse_kexinit: reserved 0
debug2: mac_setup: setup umac-64@openssh.com
debug1: kex: server->client aes128-ctr umac-64@openssh.com none
debug2: mac_setup: setup umac-64@openssh.com
debug1: kex: client->server aes128-ctr umac-64@openssh.com none
debug1: SSH2_MSG_KEX_DH_GEX_REQUEST(1024<3072<8192) sent
debug1: expecting SSH2_MSG_KEX_DH_GEX_GROUP
debug2: bits set: 1557/3072
debug1: SSH2_MSG_KEX_DH_GEX_INIT sent
debug1: expecting SSH2_MSG_KEX_DH_GEX_REPLY
debug1: Server host key: RSA
e0:c0:a1:84:c2:6a:70:eb:fe:ed:61:06:00:fe:96:2e
debug1: Host ‘sles11-sshd’ is known and matches the RSA host key.
debug1: Found key in /root/.ssh/known_hosts:2
debug2: bits set: 1547/3072
debug2: kex_derive_keys
debug2: set_newkeys: mode 1
debug1: SSH2_MSG_NEWKEYS sent
debug1: expecting SSH2_MSG_NEWKEYS
debug2: set_newkeys: mode 0
debug1: SSH2_MSG_NEWKEYS received
debug1: SSH2_MSG_SERVICE_REQUEST sent
debug2: service_accept: ssh-userauth
debug1: SSH2_MSG_SERVICE_ACCEPT received
debug2: key: /root/.ssh/id_rsa ((nil)),
debug2: key: /root/.ssh/id_dsa ((nil)),
debug2: key: /root/.ssh/id_ecdsa ((nil)),
debug2: key: /root/.ssh/id_ed25519 ((nil)),
debug1: Authentications that can continue: publickey
debug1: Next authentication method: publickey
debug1: Trying private key: /root/.ssh/id_rsa
debug1: Trying private key: /root/.ssh/id_dsa
debug1: Trying private key: /root/.ssh/id_ecdsa
debug1: Trying private key: /root/.ssh/id_ed25519
debug2: we did not send a packet, disable method
debug1: No more authentication methods to try.
Permission denied (publickey).[/color]

Server will only accept public key, at least for root user.
[color=blue]

On the target machine there is only a “known_hosts” file under
/root/.ssh - no key files.[/color]

Since you can log in to sles11-sshd at console it would be
worthwhile checking /var/log/messages on sles11-sshd to see if it
reveals anything.

My thoughts:

  • is root the correct user to connect to sles11-sshd?
  • if this worked something must have changed so the question is
    what? Note whilst you can see files may not have changed you
    can’t see files that have been deleted …

HTH.

Simon Flood
SUSE Knowledge Partner

----Android NewsGroup Reader----
http://usenet.sinaapp.com/

10

[QUOTE=KBOYLE;39261]My misunderstanding: I apologize!

That was the next question I was going to ask.

The above output you provided for Simon shows that the only authentication method supported is publickey. I would think that would be determined by /etc/ssh/sshd_config.

[LIST]
[]Can you compare sshd_config to one from another server where ssh is able to authenticate?
[]I hate to ask the obvious question: Is ChallengeResponseAuthentication set to “no”?
[/LIST][/QUOTE]

comparison of sshd_config: I don’t have another SLES11 system. I compared with openSuSE13. The files look a bit different. Let me check if I can publish a nice colored scrollable textdiff here. Maybe the most obvious difference was “UsePAM”.
There ist “yes” in openSuSE but “no” in SLES11. Switched temporarily to “yes”, restarted sshd but the error stays the same.
Change date of sshd_config is 19.03.2016. I made 100s of successful ssh-logins since that day.

ChallengeResponseAuthentication: I confirm that there is the following line
ChallengeResponseAuthentication no

11

root is the only user who needs ssh sessions

/var/log/messages does not show any entries when

  • trying to log in with ssh (with the error we are talking about)
  • login on the vmware console window

On my first vmware console login it said “last login: Friday 28.07.2017 13:39… from [my Windows PC]”. I immediately took a screenshot from this message;)
The backup I restored is from Friday 21.07.2017
Even in the unlikely case that I have accidentally deleted a configuration file after 28.07. the backup from 21.07. cannot be affected by this.

12

[QUOTE=bernbert;39278]ChallengeResponseAuthentication: I confirm that there is the following line
ChallengeResponseAuthentication no[/QUOTE]

If you change it to:
ChallengeResponseAuthentication yes
… does that resolve your issue?

13

Here’s the beginning of the ssh_config man pages.

[CODE]server:~ # man ssh_config
SSH_CONFIG(5) BSD File Formats Manual SSH_CONFIG(5)

NAME
ssh_config - OpenSSH SSH client configuration files

SYNOPSIS
~/.ssh/config
/etc/ssh/ssh_config

DESCRIPTION
ssh(1) obtains configuration data from the following sources in the fol-
lowing order:

       1.   command-line options
       2.   user's configuration file (~/.ssh/config)
       3.   system-wide configuration file (/etc/ssh/ssh_config)

[/CODE]
Read the full man page description to better understand how the config files are processed.

Based on this description, I can speculate why ssh stopped working for you:
[LIST]
[]sshd command-line options may have changed, perhaps due to having applied a patch?
[]Do you have a /root/.ssh/config file? Settings in that file would override corresponding settings in /etc/ssh/ssh_config for user “root”.
[]If you do not have a /root/.ssh/config file, perhaps it was created after your backup and therefore wasn’t restored?
[]Perhaps sshd cannot access a particular config file. Have you checked for file system errors?
[/LIST]
As I said, this is just speculation but it should give you a few other things to consider.

14

I have reread this thread several times to see what I may have missed. IMO, there are two issues we are trying to resolve:
[LIST]
[]Determine why ssh stopped working.
[]How to get it working again.
[/LIST]
I have offered some suggestions for both in previous posts.

This quote is the real brain teaser!

[QUOTE=bernbert;39282]On my first vmware console login it said “last login: Friday 28.07.2017 13:39… from [my Windows PC]”. I immediately took a screenshot from this message;)
The backup I restored is from Friday 21.07.2017
Even in the unlikely case that I have accidentally deleted a configuration file after 28.07. the backup from 21.07. cannot be affected by this.[/QUOTE]
I believe that last statement is the key. As you point out, the backup you restored should work but doesn’t. Here are a couple of other things to consider:
[LIST]
[]The system date is no longer Friday 21.07.2017. How might the system date affect this. The most common issue involving the date is that certificates may have expired.
[]Is it possible that your original VM had a snapshot that may have been reverted?
[/LIST]
I don’t have an answer for you but, at this point, I’m trying to think outside the box (pun intended).

Perhaps others may have some suggestions?

15

I made a little change in /etc/ssh/sshd_config

from original version (19.03.2016)
[I][COLOR="#0000FF"]
…

To disable tunneled clear text passwords, change to no here!

PasswordAuthentication no
…[/COLOR][/I]

to current version (24.08.2017)
[I][COLOR="#0000FF"]…

To disable tunneled clear text passwords, change to no here!

#PasswordAuthentication yes
…[/COLOR][/I]

After restart of sshd the login with putty and ssh from other linux clients works. Now I have at least a workaround.

Unfortunately this explains nothing. But I can work now.

I want to thank everybody for his contribution to this puzzling problem.

16

[QUOTE=bernbert;39296]Now I have at least a workaround.

Unfortunately this explains nothing. But I can work now.[/QUOTE]

That, I assume, was your primary objective!

This is what the man pages have to say:

ChallengeResponseAuthentication
       Specifies whether to use challenge-response authentication.  The argument to this keyword must be “yes” or “no”.  The default is “yes”.

PasswordAuthentication
       Specifies whether to use password authentication.  The argument to this keyword must be “yes” or “no”.  The default is “yes”.

Normally, I like to stay with default settings unless I have a good reason for changing them.
[LIST]
[]I have no problems accessing my SLES11 SP4 server via PuTTy.
[]I have made no changes to my /etc/ssh/sshd_config but my settings are different from yours.
[*]
[/LIST]
This is what I have for the settings we have discessed.

[QUOTE]# To disable tunneled clear text passwords, change to no here!
PasswordAuthentication no
#PermitEmptyPasswords no

Change to no to disable s/key passwords

#ChallengeResponseAuthentication yes

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
[/QUOTE]

From what I have been able to determine, setting either ChallengeResponseAuthentication or PasswordAuthentication to “yes” will allow you to enter a user/password to logon. Setting ChallengeResponseAuthentication to yes is what enables the keyboard-interactive authentication method. I would be a bit concerned about permitting “tunneled clear text passwords” by setting PasswordAuthentication to yes.

While we both have a working SSHD, I am using the SLES provided defaults and you are not.

17

On 24/08/17 20:54, bernbert wrote:
[color=blue]

After restart of sshd the login with putty and ssh from other linux
clients works. Now I have at least a workaround.[/color]

That’s good.
[color=blue]

Unfortunately this explains nothing. But I can work now.[/color]

A thought I had last night - is it possible you’ve recently installed an
update to openSSH on the server?

Given SLES11 SP2 is no longer supported by SUSE and no updates have been
released since 2014 (unless you’ve got Long Term Service Pack Support -
LTSS) it’s unlikely but it could explain a configuration file and/or
openSSH binary changing …

I’m still thinking this is down to something changing between it last
working and until your workaround not. The question is what and where.

HTH.

Simon
SUSE Knowledge Partner

If you find this post helpful and are logged into the web interface,
please show your appreciation and click on the star below. Thanks.