0

I am following a relatively short and simple guide on this (https://www.digitalocean.com/community/tutorials/how-to-set-up-ssh-keys--2)

Step One—Create the RSA Key Pair

ssh-keygen -t rsa

"Your public key has been saved in /Users/justinobrien/.ssh/id_rsa.pub." Okay. I renamed the public and private keys 'justin' and 'justin.pub' (as I have to do this for the root user too).

Step Three—Copy the Public Key: You can paste in the keys using ssh:

cat ~/.ssh/id_rsa.pub | ssh demo@198.51.100.0 "mkdir -p ~/.ssh && chmod 700 ~/.ssh && cat >>  ~/.ssh/authorized_keys"

I replaced the ip with my ip, the name of my files and the name of my user('justin') so:

cat ~/.ssh/justin.pub | ssh justin@42.93..***"mkdir -p ~/.ssh && chmod 700 ~/.ssh && cat >>  ~/.ssh/authorized_keys"

"You may see something like:"

The authenticity of host '198.51.100.0 (198.51.100.0)' can't be established.
RSA key fingerprint is b1:2d:33:67:ce:35:4d:5f:f3:a8:cd:c0:c4:48:86:12.
Are you sure you want to continue connecting (yes/no)? yes
Warning: Permanently added '198.51.100.0' (RSA) to the list of known hosts. 
user@198.51.100.0's password:

But this is not what I see, I enter the command above and only get asked to login with my password? I.e. all I see is: justin@142.93.184.125's password:

Update, in the comments below I found I may have already set this up and just need to restart the server: I ran sudo reboot. Now I can attempt to connect again as either 'root' or 'justin' 3 times, before being asked for the password :

ssh justin@142.93..***
ssh: connect to host 142.93..*** port 22: Operation timed out

ssh justin@142.93..***
ssh: connect to host 142.93..*** port 22: Connection refused

ssh justin@142.93..***
ssh: connect to host 142.93..*** port 22: Connection refused

If I try again a 4th time, it will ask for my password and allow me to connect. Not really sure what is going on here. I ran sudo ufw allow 22 to no avail. Thanks for any help.

17
  • 1
    Remember to delete your old (no longer relevant) comments.
    – user535733
    Feb 20 '20 at 17:22
  • 1
    If you haven't already set up key-based access, then you will need to authenticate once via password in order to copy the key to the remote server. Otherwise anyone could access your server and copy their keys there. Feb 20 '20 at 17:26
  • 2
    Sorry - I didn't see your update. If you are getting multiple timeouts followed by a successful connection, that sounds more like a network issue (such as a bad routing table entry or conflicting LAN IP address) than anything related to SSH specifically Feb 20 '20 at 17:42
  • 1
    It usually looks for the ancient ssl v1 keys first. Trying keys that don't exist, just in case they do exist, is part of the process. Look for the name of the key you created in the output: Offering public key: ... or the like. One thing I have seen is some servers have low caps on number of keys offered. If the right key isn't tried early enough, it can be blocked. Then Authentications that can continue will stop listing publickey. Feb 21 '20 at 0:16
  • 1
    Oh, and if your newly created key is not listed at all, that's a problem too. Feb 21 '20 at 0:17
0

You can supply -v (verbose) option in your SSH connection to see what is happening under the hood. The debug message will provide some pointers for figuring out the root cause.

When copying the public key, you can type the command as follows.

cat ~/.ssh/id_rsa.pub | ssh -v justin@SERVER-IP "mkdir -p ~/.ssh && chmod 700 ~/.ssh && cat >>  ~/.ssh/authorized_keys"

Please note that public key copy command above missed the part to set the authorized_keys permission to 600.

If you generate the key pair using this command:

ssh-keygen -t rsa

The private and public key will use default algorithm (RSA), default key length (2048) and stored with default names (~/.ssh/id_rsa for the private key and ~/.ssh/id_rsa.pub) for the public key. You shall not alter the file name, otherwise the client will fail the key exchange during the SSH handshake.

The error message ssh: connect to host 142.93..*** port 22: Operation timed out indicates network issue rather than an issue with the SSH authentication.

If you want to understand the details of passwordless SSH authentication at the protocol level and also how to set it up, this article may be helpful.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.