Hi, I really wish I didn’t have to come here but my brain is not working I guess and I need a paint diagram to understand this thing: I’m trying to switch my authentication through SSH to keys because I need to expose my Linux box on the internet.
I generated my pair of keys with Putty (I don’t have a linux host a the moment), created the .ssh folder into the home directory, copied the public key into the file authorized_keys as ssh-rsa "public-key" rsa-key-"date", restarted the SSH connection and the handshake with the key fails. What did I do wrong? Thanks for the help!
Did you convert the public key to openssh format? puttygen makes it SSH2 format by default.
Edit:
Or, rather, the save buttons save it in SSH2 format.
2 Likes
Ooh so I need to convert in openssh to work. I’ll try ASAP.
Also, since we’re on the topic: if I have multiple accounts I should make multiple keys?
Make sure that file isn’t owned by root if you’re remoting in as another user. I’ve had issues with that in the past where /home/admindev/.ssh/authorized_keys was root root and I had to change to admindev admindev.
2 Likes
I changed the owner of the folder so that shouldn’t be an issue. Thanks for the answer.
I was playing around with puttygen just a bit ago, as I don’t use it very often. But one of the very first things I did was generate a key, and then click the Save Public Key button. That button will save as SSH2 format. But the box towards the top of the window shows the OpenSSH formatted public key. That’s what you want in your authorized_keys files.
Between this and AdminDev’s idea, you should be good to go, assuming you’ve told PuTTY to use the private key file when logging in. I forget exactly where that is in the PuTTY interface. PuTTY is such a feature-rich tool, it’s hard to group up all of those options without it seeming like a mess.
Should you make multiple SSH keys for multiple accounts? Eeehhh… That’s rough. If you’re not into password managers, I would say no. One, strong SSH key with a strong passphrase should be good enough. If someone compromises your computer, and takes one SSH key, they can just as easily take 5 SSH keys.
The only thing that would help you there is if you have 5 passphrases, one for each SSH key. At that point you do start to undermine one of the reasons to use SSH keys, which is convenience. That should never be the primary reason to use SSH keys. But it is a reason.
However, if you’re using a password manager, and it’s no big deal to generate and use 5 passphrases for 5 SSH keys, then go for it. Your convenience is not particularly hindered, and the security is tightened.
But an absolute must is putting a passphrase on your SSH key. Many many moons ago, SSH keys were heralded as a source of major convenience for sys admins. They could log into any number of boxen without entering their password. These days we call that a backdoor, and we don’t like those.
Ack! I’m rambling now. I will stop.
2 Likes
Thanks a lot for the detailed response, I really appreciated it and didn’t see it as rambling at all.
Password managing is not an issue for me so, for security sake, I think I’ll make a key for each user so that I can isolate the compromised user in case the key gets leaked.
1 Like
I tried but the key still gets refused. I exported the key in openssh format, pasted it into the authorized_keys file (no extensions) and the key is still refused.
I’m still doing something wrong here.
Okay, check /var/log/syslog and /var/log/auth immediately after the key fails to authenticate you. There should be some clue in one of those as to why the key doesn’t work.
Another thing you could do, which isn’t recommended for production situations, but you can do it and still be pretty secure. You can copy the private key to the machine you’re trying to ssh to. Then from that machine, ssh to localhost using that private key, and add the -vvv flags. 99 times out of 100, that will tell you what’s missing.
I have had an issue of logins in Linux not being allowed to use ssh keys to login. In that instance, nothing showed up in any of the above logs. I just had to create a new login from scratch, and abandon the one that wasn’t working. I’ve only seen that on 2 machines out of hundreds, if not thousands of Linux boxen.
Do you have ssh-keygen or ssh-copy-id available? If you have the latter, you ought to be able to:
ssh-copy-id -i ~/.ssh/foo-key-ecdsa user@host
A small edit here: I haven’t used Putty. To rule out some obvious things, can you ls -l the key on your machine, then do the same on the server, in order to make sure there’s no filetype, ownership, or permission issues?
@Levitance As you predicted both of those files didn’t report anything wrong when I failed to log in with the SSH key. I didn’t understand what you want me to do. It’s fine to do it because until I figure out this thing the machine is still not exposed and in a blank state.
When puttygen asks me to save the private key it doesen’t give me an extension to save it into. Also, what I tried to do was saving it in .txt and copying over the content of the file into /home/[me]/.ssh/authorized_key.
@k3g The file has no extension. What should be the permissions and the ownership of the file?
I am so sorry, the weekend hit, and I forgot all about this thread. Alright, let’s do this thing.
You’re mostly there. Saving the private key without a file extension is fine. Getting it over to the machine is what we wanted, except not in the authorized_keys file. Just put the private key in /home/[you]/.ssh/. For our example, let’s say it’s called yourkey.priv, so we know it’s the private key.
What we have is:
- Your private key is at /home/[you]/.ssh/yourkey.priv
- Your public key is listed in /home/[you]/.ssh/authorized_keys
- Your private key is no longer in /home/[you]/.ssh/authorized_keys
From there, try to ssh to that machine, from that machine.
ssh -vvv localhost -i /home/[you]/.ssh/yourkey.priv
This will give you a boatload of output. If, at the end of all of that output, you get a password prompt, ctrl+c to abort. The clues to solve this are probably in that output.
If you successfully ssh into localhost without giving it a password, then we need to find out why PuTTY isn’t passing the key along.
For anyone curious about the ssh command above, -v enables verbose output. Multiple -v options increase the verbosity to a maximum of 3. So -vvv is as verbose as it gets.
-i specifies what identity file you want to present to the remote machine.
1 Like