Question

Public key has been denied

The public key for my server was working until today. Now when I try connecting to my server using ssh -v user@xx.xxx.xx.xxx, the following output is returned.

OpenSSH_8.1p1, LibreSSL 2.7.3
debug1: Reading configuration data /Users/michaelhermary/.ssh/config
debug1: /Users/michaelhermary/.ssh/config line 1: Applying options for *
debug1: Reading configuration data /etc/ssh/ssh_config
debug1: /etc/ssh/ssh_config line 47: Applying options for *
debug1: Connecting to 64.227.56.243 [64.227.56.243] port 22.
debug1: Connection established.
debug1: identity file /Users/michaelhermary/.ssh/id_rsa type 0
debug1: identity file /Users/michaelhermary/.ssh/id_rsa-cert type -1
debug1: identity file /Users/michaelhermary/.ssh/id_dsa type -1
debug1: identity file /Users/michaelhermary/.ssh/id_dsa-cert type -1
debug1: identity file /Users/michaelhermary/.ssh/id_ecdsa type -1
debug1: identity file /Users/michaelhermary/.ssh/id_ecdsa-cert type -1
debug1: identity file /Users/michaelhermary/.ssh/id_ed25519 type -1
debug1: identity file /Users/michaelhermary/.ssh/id_ed25519-cert type -1
debug1: identity file /Users/michaelhermary/.ssh/id_xmss type -1
debug1: identity file /Users/michaelhermary/.ssh/id_xmss-cert type -1
debug1: Local version string SSH-2.0-OpenSSH_8.1
debug1: Remote protocol version 2.0, remote software version OpenSSH_7.6p1 Ubuntu-4ubuntu0.3
debug1: match: OpenSSH_7.6p1 Ubuntu-4ubuntu0.3 pat OpenSSH_7.0*,OpenSSH_7.1*,OpenSSH_7.2*,OpenSSH_7.3*,OpenSSH_7.4*,OpenSSH_7.5*,OpenSSH_7.6*,OpenSSH_7.7* compat 0x04000002
debug1: Authenticating to 64.227.56.243:22 as 'mikehermary'
debug1: SSH2_MSG_KEXINIT sent
debug1: SSH2_MSG_KEXINIT received
debug1: kex: algorithm: curve25519-sha256
debug1: kex: host key algorithm: ecdsa-sha2-nistp256
debug1: kex: server->client cipher: chacha20-poly1305@openssh.com MAC: <implicit> compression: none
debug1: kex: client->server cipher: chacha20-poly1305@openssh.com MAC: <implicit> compression: none
debug1: expecting SSH2_MSG_KEX_ECDH_REPLY
debug1: Server host key: ecdsa-sha2-nistp256 SHA256:riDtnLiJ56tFIZhjyIuT0yxV0MaK4zuwrSE1zGdcg5Q
debug1: Host '64.227.56.243' is known and matches the ECDSA host key.
debug1: Found key in /Users/michaelhermary/.ssh/known_hosts:16
debug1: rekey out after 134217728 blocks
debug1: SSH2_MSG_NEWKEYS sent
debug1: expecting SSH2_MSG_NEWKEYS
debug1: SSH2_MSG_NEWKEYS received
debug1: rekey in after 134217728 blocks
debug1: Will attempt key: /Users/michaelhermary/.ssh/id_rsa RSA SHA256:ZcqcTB8oS8GdBCheA/ubHLn0l15IidHaRzqYk5t+BOQ
debug1: Will attempt key: /Users/michaelhermary/.ssh/id_dsa 
debug1: Will attempt key: /Users/michaelhermary/.ssh/id_ecdsa 
debug1: Will attempt key: /Users/michaelhermary/.ssh/id_ed25519 
debug1: Will attempt key: /Users/michaelhermary/.ssh/id_xmss 
debug1: SSH2_MSG_EXT_INFO received
debug1: kex_input_ext_info: server-sig-algs=<ssh-ed25519,ssh-rsa,rsa-sha2-256,rsa-sha2-512,ssh-dss,ecdsa-sha2-nistp256,ecdsa-sha2-nistp384,ecdsa-sha2-nistp521>
debug1: SSH2_MSG_SERVICE_ACCEPT received
debug1: Authentications that can continue: publickey
debug1: Next authentication method: publickey
debug1: Offering public key: /Users/michaelhermary/.ssh/id_rsa RSA SHA256:ZcqcTB8oS8GdBCheA/ubHLn0l15IidHaRzqYk5t+BOQ
debug1: Authentications that can continue: publickey
debug1: Trying private key: /Users/michaelhermary/.ssh/id_dsa
debug1: Trying private key: /Users/michaelhermary/.ssh/id_ecdsa
debug1: Trying private key: /Users/michaelhermary/.ssh/id_ed25519
debug1: Trying private key: /Users/michaelhermary/.ssh/id_xmss
debug1: No more authentication methods to try.

The private key is named digitalocean and the public key is named digitalocean.pub.

I am able to log into the server using the Console Access terminal in the browser using my username and password. It just seems that the keys have become corrupted or something.

The root user was disabled after I created a new user.

I am new to server management and am just learning as I go. Any help is greatly appreciated.

Cheers,

Submit an answer

This textbox defaults to using Markdown to format your answer.

You can type !ref in this text area to quickly search our full set of tutorials, documentation & marketplace offerings and insert the link!

Sign In or Sign Up to Answer

These answers are provided by our Community. If you find them useful, show some love by clicking the heart. If you run into issues leave a comment, or add your own answer to help others.

alexdo • April 15, 2021

Hello there,

You can check our article on How to Upload an SSH Public Key to an Existing Droplet

https://www.digitalocean.com/docs/droplets/how-to/add-ssh-keys/to-existing-droplet/

You can access the droplet from the DigitalOcean console and then temporary enable the PasswordAuthentication on your droplet and access the droplet with a password to upload the ssh-key.

If you haven’t created new pair of keys you’ll need to do that first.

You can enable PasswordAuthentication for your Droplet by modifying your /etc/ssh/sshd_config file. Once set to Yes restart the SSH service and connect via an SSH client for a more stable connection. You can then modify your ~/.ssh/authorized_keys file to add the appropriate public key.

This change can be made from the DigitalOcean’s console. If you’re having issues accessing the console you can then reach to our amazing support team that can help you further with this.

To enable the PasswordAuthentication follow these steps:

  1. Login to the console on the DigitalOcean website.
  2. Type sudo nano /etc/ssh/sshd_config
  3. Change PasswordAuthentication from “no” to “yes” and save the file
  4. Open a terminal on your computer and type ssh username@[hostname or IP address] or if on a Windows box use PuTTY for password login making sure authentication parameters aren’t pointing to a private key
  5. Login with a password
  6. Type sudo nano ~/.ssh/authorized_keys
  7. Paste public key text here and save the file
  8. Type sudo nano /etc/ssh/sshd_config
  9. Change PasswordAuthentication from “yes” to “no” and save the file
  10. Log out and attempt to log back in (if using PuTTY make sure you set up auth parameters to point to your private key)

You can then upload the key using this command:

ssh-copy-id -i ~/.ssh/mykey user@droplet

Hope that this helps! Regards, Alex

KFSys • July 17, 2020

Hi @mikehermary,

Usually, when you use SSH, the automatic keys that are being used are id_rsa.pub and id_rsa. In order for you to make them take another .pub file you can use the -i option:

ssh -i /path/to/id_rsa(digitalocean.pub) user@XXX.XXX.XXX.XXX

Try with that one.

Additionally, I can see you are using it on a user that’s different with root. It’s possible somewhere something hasn’t been configured properly like wrong permissions, ownerships, stuff like that.

Let’s first being with the usual stuff:

  • Your home directory ~, your ~/.ssh directory and the ~/.ssh/authorized_keys file on the remote machine must be writable only by you: rwx------ and rwxr-xr-x are fine, but rwxrwx--- is no good, even if you are the only user in your group (if you prefer numeric modes: 700 or 755, not 775).
  • If ~/.ssh or authorized_keys is a symbolic link, the canonical path (with symbolic links expanded) is checked.
  • Your ~/.ssh/authorized_keys file (on the remote machine) must be readable (at least 400), but you’ll need it to be also writable (600) if you will add any more keys to it.
  • Your private key file (on the local machine) must be readable and writable only by you: rw-------, i.e. 600.

Now that we’ve passed the standard stuff, let’s get going on the more interesting stuff.

When you run

/usr/sbin/sshd -d -p 2222

On your droplet, you can then connect without a password, what does the debug information says on your droplet, It should state something like

Authentication allowed

In this case, what you can do is temporarily stop the SSH daemon and replace it with one in debug mode. Don’t worry, stopping the SSH daemon won’t kill any existing connections. This means it’s possible to run this without being connected to the droplet’s Console but it’s somewhat risky. If the connection does get broken for any kind of reason, you’ll need to connect using your droplet’s console. Anyway, you can run the following

service ssh stop
/usr/sbin/sshd -d
#...debug output...
service ssh start

If it again runs with the debug mode being on, then for sure it’s the SELinux causing the issues, it’s most probably set to Enforcing. The .ssh dir will probably be mislabeled. Look at /var/log/audit/audit.log. Check with ls -laZ and then Run restorecon -r -v /path/to/users/.ssh.

Regards, KFSys