Related

Is it possible to take a snapshot of a volume, destroy the volume, then restore it from the snapshot? Question Question
my SGP1 server can't access Question Question

Question

Additional SSH Key not working

Posted March 24, 2020 903 views
DigitalOcean Accounts

I created my private key and added it to the account using the Add SSH Key feature on https://cloud.digitalocean.com/account/security page. That works perfect - I can log in w/out any issues.

The problem is when I tried to do the exact same thing with another key (for a co-worker) and followed the same steps, but it doesn’t work.

login as: root

I get the following error: No supported authentication methods available (server sent:publickey.gssapi-keyex.gssapi-with-mic).

I’ve tried all the articles about the SSH keys with ditigalocean, added the key manually to the ~/.ssh/authorized_keys file, nothing works :(

Add a comment
srenert
By:
srenert

Related

Is it possible to take a snapshot of a volume, destroy the volume, then restore it from the snapshot? Question Question
my SGP1 server can't access 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
2 answers
KFSys March 25, 2020

Hi @srenert,

It’s possible the key provided is not actually correct. This will be my first guess. Please make sure the key provided is actually the .pub one and it does is correct.

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

Try to run the following command on the droplet and then connect from the computer/environment using the said key

/usr/sbin/sshd -d -p 2222

You should be able to connect and receive something like the following on your Droplet :

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,
KDSys

Reply Report
  • srenert March 25, 2020

    Why would my 1st key work fine though? Only the subsequent later keys (which are generated the same way) don’t....

    Reply Report
    • KFSys March 25, 2020

      Yes, in that case I would assume it’s the keys that are wrong.

      Additionally, you’ve mentioned it but can you confirm you are adding the keys to the file used by root

      /root/.ssh/authorized_keys

      Regards,
      KDSys

      Reply Report
stephaniesmi606 March 25, 2020

Here are some steps you can take to troubleshoot this issue: Make sure the authorized_keys file and the private key itself have the correct permissions and ownership. Check that key-based authentication is allowed by the server. … If you’re using an OpenSSH client, be sure your private SSH key has the proper permissions.

Reply Report

Related

Looking for something else?

Ask a new question Search for more help