Was previously able to SSH into droplet but suddently it's not working?? Resetting keys unsuccessful..

May 2, 2017 1.4k views
Ansible Ubuntu
abm
By:
abm

Not sure what exactly this is telling me? The file [~/Users/austinmiles/.ssh/id_rsa] exists, why wouldn't it be found? Also, why is it searching for a dsa key?

OpenSSH6.9p1, LibreSSL 2.1.8
debug1: Reading configuration data /etc/ssh/sshconfig
debug1: /etc/ssh/sshconfig line 21: Applying options for *
debug2: sshconnect: needpriv 0
debug1: Connecting to 192.241.135.48 [192.241.135.48] port 22.
debug1: Connection established.
debug1: identity file /Users/austinmiles/.ssh/idrsa type 1
debug1: keyloadpublic: No such file or directory
debug1: identity file /Users/austinmiles/.ssh/idrsa-cert type -1
debug1: keyloadpublic: No such file or directory
debug1: identity file /Users/austinmiles/.ssh/iddsa type -1
debug1: keyloadpublic: No such file or directory
debug1: identity file /Users/austinmiles/.ssh/iddsa-cert type -1
debug1: keyloadpublic: No such file or directory
debug1: identity file /Users/austinmiles/.ssh/idecdsa type -1
debug1: keyloadpublic: No such file or directory
debug1: identity file /Users/austinmiles/.ssh/idecdsa-cert type -1
debug1: keyloadpublic: No such file or directory
debug1: identity file /Users/austinmiles/.ssh/ided25519 type -1
debug1: keyloadpublic: No such file or directory
debug1: identity file /Users/austinmiles/.ssh/ided25519-cert type -1
debug1: Enabling compatibility mode for protocol 2.0
debug1: Local version string SSH-2.0-OpenSSH6.9
debug1: Remote protocol version 2.0, remote software version OpenSSH7.2p2
debug1: match: OpenSSH7.2p2 pat OpenSSH* compat 0x04000000
debug2: fd 3 setting ONONBLOCK
debug1: Authenticating to 192.241.135.48:22 as 'root'
debug3: hostkeysforeach: reading file "/Users/austinmiles/.ssh/knownhosts"
debug3: recordhostkey: found key type ED25519 in file /Users/austinmiles/.ssh/knownhosts:6
debug3: loadhostkeys: loaded 1 keys from 192.241.135.48
debug3: orderhostkeyalgs: prefer hostkeyalgs: ssh-ed25519-cert-v01@openssh.com,ssh-ed25519
debug1: SSH2MSGKEXINIT sent
debug1: SSH2MSGKEXINIT received
debug2: kexparsekexinit: curve25519-sha256@libssh.org,ecdh-sha2-nistp256,ecdh-sha2-nistp384,ecdh-sha2-nistp521,diffie-hellman-group-exchange-sha256,diffie-hellman-group-exchange-sha1,diffie-hellman-group14-sha1,diffie-hellman-group1-sha1
debug2: kexparsekexinit: ssh-ed25519-cert-v01@openssh.com,ssh-ed25519,ecdsa-sha2-nistp256-cert-v01@openssh.com,ecdsa-sha2-nistp384-cert-v01@openssh.com,ecdsa-sha2-nistp521-cert-v01@openssh.com,ssh-rsa-cert-v01@openssh.com,ssh-dss-cert-v01@openssh.com,ssh-rsa-cert-v00@openssh.com,ssh-dss-cert-v00@openssh.com,ecdsa-sha2-nistp256,ecdsa-sha2-nistp384,ecdsa-sha2-nistp521,ssh-rsa,ssh-dss
debug2: kexparsekexinit: chacha20-poly1305@openssh.com,aes128-ctr,aes192-ctr,aes256-ctr,aes128-gcm@openssh.com,aes256-gcm@openssh.com,arcfour256,arcfour128,aes128-cbc,3des-cbc,blowfish-cbc,cast128-cbc,aes192-cbc,aes256-cbc,arcfour,rijndael-cbc@lysator.liu.se
debug2: kexparsekexinit: chacha20-poly1305@openssh.com,aes128-ctr,aes192-ctr,aes256-ctr,aes128-gcm@openssh.com,aes256-gcm@openssh.com,arcfour256,arcfour128,aes128-cbc,3des-cbc,blowfish-cbc,cast128-cbc,aes192-cbc,aes256-cbc,arcfour,rijndael-cbc@lysator.liu.se
debug2: kexparsekexinit: 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: kexparsekexinit: 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: kexparsekexinit: none,zlib@openssh.com,zlib
debug2: kexparsekexinit: none,zlib@openssh.com,zlib
debug2: kexparsekexinit:
debug2: kexparsekexinit:
debug2: kexparsekexinit: firstkexfollows 0
debug2: kexparsekexinit: reserved 0
debug2: kexparsekexinit: curve25519-sha256@libssh.org,diffie-hellman-group-exchange-sha256
debug2: kexparsekexinit: ssh-ed25519,ssh-rsa,rsa-sha2-512,rsa-sha2-256
debug2: kexparsekexinit: chacha20-poly1305@openssh.com,aes256-gcm@openssh.com,aes128-gcm@openssh.com,aes256-ctr,aes192-ctr,aes128-ctr
debug2: kexparsekexinit: chacha20-poly1305@openssh.com,aes256-gcm@openssh.com,aes128-gcm@openssh.com,aes256-ctr,aes192-ctr,aes128-ctr
debug2: kexparsekexinit: hmac-sha2-512-etm@openssh.com,hmac-sha2-256-etm@openssh.com,hmac-ripemd160-etm@openssh.com,umac-128-etm@openssh.com,hmac-sha2-512,hmac-sha2-256,hmac-ripemd160
debug2: kexparsekexinit: hmac-sha2-512-etm@openssh.com,hmac-sha2-256-etm@openssh.com,hmac-ripemd160-etm@openssh.com,umac-128-etm@openssh.com,hmac-sha2-512,hmac-sha2-256,hmac-ripemd160
debug2: kexparsekexinit: none,zlib@openssh.com
debug2: kexparsekexinit: none,zlib@openssh.com
debug2: kexparsekexinit:
debug2: kexparsekexinit:
debug2: kexparsekexinit: firstkexfollows 0
debug2: kexparsekexinit: reserved 0
debug1: kex: server->client chacha20-poly1305@openssh.com <implicit> none
debug1: kex: client->server chacha20-poly1305@openssh.com <implicit> none
debug1: expecting SSH2MSGKEXECDHREPLY
debug1: Server host key: ssh-ed25519 SHA256:n06JJ3Chv7S9s9czi5hssBIz7YC9/LHz7RcknyynRSg
debug3: hostkeysforeach: reading file "/Users/austinmiles/.ssh/knownhosts"
debug3: recordhostkey: found key type ED25519 in file /Users/austinmiles/.ssh/knownhosts:6
debug3: loadhostkeys: loaded 1 keys from 192.241.135.48
debug1: Host '192.241.135.48' is known and matches the ED25519 host key.
debug1: Found key in /Users/austinmiles/.ssh/knownhosts:6
debug2: setnewkeys: mode 1
debug1: SSH2MSGNEWKEYS sent
debug1: expecting SSH2MSGNEWKEYS
debug2: setnewkeys: mode 0
debug1: SSH2MSGNEWKEYS received
debug1: SSH2MSGSERVICEREQUEST sent
debug2: serviceaccept: ssh-userauth
debug1: SSH2MSGSERVICEACCEPT received
debug2: key: /Users/austinmiles/.ssh/idrsa (0x7fb729e13e20),
debug2: key: /Users/austinmiles/.ssh/iddsa (0x0),
debug2: key: /Users/austinmiles/.ssh/idecdsa (0x0),
debug2: key: /Users/austinmiles/.ssh/ided25519 (0x0),
debug1: Authentications that can continue: publickey
debug3: start over, passed a different list publickey
debug3: preferred publickey,keyboard-interactive,password
debug3: authmethodlookup publickey
debug3: remaining preferred: keyboard-interactive,password
debug3: authmethodisenabled publickey
debug1: Next authentication method: publickey
debug1: Offering RSA public key: /Users/austinmiles/.ssh/idrsa
debug3: sendpubkeytest
debug2: we sent a publickey packet, wait for reply
debug1: Server accepts key: pkalg ssh-rsa blen 279
debug2: inputuserauthpkok: fp SHA256:PjB2UOY8KWCs7k2tzyWNVvQDTv2Uuy3HclfAB8YlIUM
debug3: signandsendpubkey: RSA SHA256:PjB2UOY8KWCs7k2tzyWNVvQDTv2Uuy3HclfAB8YlIUM
debug1: Authentications that can continue: publickey
debug1: Trying private key: /Users/austinmiles/.ssh/iddsa
debug3: no such identity: /Users/austinmiles/.ssh/iddsa: No such file or directory
debug1: Trying private key: /Users/austinmiles/.ssh/idecdsa
debug3: no such identity: /Users/austinmiles/.ssh/idecdsa: No such file or directory
debug1: Trying private key: /Users/austinmiles/.ssh/ided25519
debug3: no such identity: /Users/austinmiles/.ssh/id_ed25519: No such file or directory
debug2: we did not send a packet, disable method
debug1: No more authentication methods to try.
Permission denied (publickey).

Log In to Comment
2 Answers
jtittle1 May 2, 2017

@abm

The Permission Denied error is a result of one of two things.

1). Your local private key (on your Mac) doesn't match the public key on your Droplet;

2). Incorrect permissions on one or both keys.

...

If your local private key doesn't match the public key on the Droplet, authentication will fail. Likewise, if you generate a new key pair locally and fail to update the public key on the Droplet, authentication will fail.

The private key you attempt to authenticate must match the public key on the server you're trying to connect to using:

ssh user@droplet_ip -i ./ssh/private_key

If permissions are incorrect on the authorized_keys file or the .ssh directory on either end, login will also fail.

...

Generally when you're locked out from SSH after repeated failed logins, the block is temporary, unless you have a firewall (such as ufw) active, in which case, you may need to login to console from the DigitalOcean control panel and login with root and the root users password.

If you deployed with SSH Keys, the root user won't be setup with a password, and you may be locked out of the server as console doesn't accept SSH Keys -- only the root password.

Reply
abm May 2, 2017

Thanks for this @jtittle, how would I be able to confirm that I'm locked out? I did deploy with SSH unfortunately. Is there a specific lockout period? Do I have any other options. Do the keys need to match the ones used via a github deploy? I don't quite understand the process of agent-forwarding.

Reply
  • hansen May 2, 2017

    @abm
    If you've destroyed the key used when creating the droplet, then you need to open a ticket in the control panel and request the Recovery ISO. This is a Debian based Live CD image that will allow you to boot your droplet, mount your droplet's filesystem, reset your root password and perform other maintenance.

  • jtittle1 May 2, 2017

    @abm

    When you deploy with SSH Keys, only the public key you provided DigitalOcean and the private key you have locally can be used to authenticate until you either add additional keys, or create a new user that allows you to login (such as a sudo user).

    If you change or overwrite the private key you have locally, it will no longer authenticate with the public key you have on the server, so you've effectively locked yourself out unless you have a backup of the older private key.

    You can enter recovery mode, as @hansen suggested, though that would effectively be the only option to regain access.

Have another answer? Share your knowledge.

Related Questions