Related

Tool DOCTL: DigitalOcean CLI Tool
Cpanel cannot be logged in Question Question
Connect to DB installed into dedicated VPS (private networking) Question Question

Question

Public key has been denied

Posted July 17, 2020 491 views
System ToolsInitial Server Setup

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,

Add a comment
mikehermary
By:
mikehermary

Related

Tool DOCTL: DigitalOcean CLI Tool
Cpanel cannot be logged in Question Question
Connect to DB installed into dedicated VPS (private networking) Question Question

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.

×
Submit an Answer
1 answer
KFSys July 17, 2020

Hi @mikehermary,

Usually, when you use SSH, the automatic keys that are being used are idrsa.pub and idrsa. 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------ andrwxr-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

Reply Report

Related

Looking for something else?

Ask a new question Search for more help