Page 1 of 2 12 LastLast
Results 1 to 10 of 17

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

Hybrid View

  1. #1

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

    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. #2

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

    On 22/08/17 15:34, bernbert wrote:

    > 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.


    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. #3

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

    Quote Originally Posted by smflood View Post
    On 22/08/17 15:34, bernbert wrote:

    > 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.


    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.
    ------------------------------------------------------------------------
    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...00@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...60@openssh.com,hmac-sha1-96,hmac-md5-96
    debug2: kex_parse_kexinit: umac-64-etm@openssh.com,umac-128-etm...60@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.

  4. #4

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

    bernbert Wrote in message:

    > here is the output from "ssh -vv". I have replaced the original hostname
    > of the SLES11 host with "sles11-sshd".


    Okay, I'll comment below on various bits of the output.

    > root@linux-ssh-client:~# ssh -vv sles11-sshd


    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.

    > 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.


    It successfully makes a connection to sles11-sshd.

    > 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


    It doesn't find a local public key file.

    > 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...00@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...60@openssh.com,hmac-sha1-96,hmac-md5-96
    > debug2: kex_parse_kexinit:
    > umac-64-etm@openssh.com,umac-128-etm...60@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).


    Server will only accept public key, at least for root user.

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


    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/

  5. #5

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

    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.

  6. #6

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

    I have reread this thread several times to see what I may have missed. IMO, there are two issues we are trying to resolve:
    • Determine why ssh stopped working.
    • How to get it working again.

    I have offered some suggestions for both in previous posts.

    This quote is the real brain teaser!
    Quote Originally Posted by bernbert View Post
    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.
    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:
    • 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?

    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?
    Kevin Boyle - 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 this post. Thanks.

  7. #7

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

    On 08/22/2017 08:34 AM, bernbert wrote:
    >
    > 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.


    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?

    > 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?


    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.

  8. #8

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

    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

  9. #9

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

    Quote Originally Posted by bernbert View Post
    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"
    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:

    1. Using the console via VMware enable authentication method "keyboard-interactive" and see if you can then login.
    2. Go through the process of setting up public key authentication again.
    Kevin Boyle - 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 this post. Thanks.

  10. #10

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

    Quote Originally Posted by KBOYLE View Post
    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:

    1. Using the console via VMware enable authentication method "keyboard-interactive" and see if you can then login.
    2. Go through the process of setting up public key authentication again.
    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!

Page 1 of 2 12 LastLast

Bookmarks

Posting Permissions

  • You may not post new threads
  • You may not post replies
  • You may not post attachments
  • You may not edit your posts
  •