too stupid for security: key based ssh authentication for dummies? reddit / selfhosted ---------------------------------------------------------------------- IacovHall · 2023-12-05 15:43 hey i would like to achieve logging into my VMs via SSH with an each unique key pair and deactivated password logins i've found several guides how to achieve that via puttygen etc but i still don't get the hang of it and am afraid of locking myself out of my machines how do you generate your keys for your machines? do you generate a pair for each machine or do you use one "general key"? how do you manage those keys? do you store them in a password manager or simply in putty? how do you recover from a data loss? (e.g. OS has to be reinstalled and you loose the local putty config) what is the most foolproof step by step guide for dummies like me to generate the keys, push them onto the machine and deactivate the pw login? because i once stood in pooring rain in front of my home because i forgot my keys - i don't want to experience something similar with my VMs ;) ---------------------------------------------------------------------- razorpolar · 2023-12-05 15:55 Always use the ssh-keygen command to generate new keys Always generate ed25519 keys as they're more modern, secure and smaller I wouldn't use Putty, it's old and antiquated. Use a multi-session manager like mRemoteNG or the Windows built in openSSH client from command prompt. You can store your config in C:\\Users\\username\\.ssh\\config so when you want to ssh into something you literally just open command prompt and type in "ssh myawesomeserver" and it will authenticate you with your key Youtube: ssh-keygen ed25519 Youtube: ssh config file windows ---------------------------------------------------------------------- Kizaing · 2023-12-05 16:08 Agreed, I've seen so many people get screwed by PuTTY, plus the OpenSSH config file is OS agnostic so you can move your keys and configs anywhere, makes things much easier overall ---------------------------------------------------------------------- ddpbsd · 2023-12-05 16:08 I‘ve never had a problem with putty, it’s a fine tool. Use ssh-keygen to create the keys, then you can convert to putty‘s format with its keygen tool. I use the same key on each class of system. Local systems get 1, remote systems get another. I use the fido support when I can (I’m usually not using windows). Create the keys, make immediate backups of keys, copy the pub key half to the server in your authorized_keys file. Verify you can use the key to login, then and only then disable password auth. Leave an ssh connection open after disabling pw auth and restarting sshd, then try to ssh in using the key in another putty window. If it works, you‘re golden, if not you have the open connection to fix it. ---------------------------------------------------------------------- Ovasak · 2023-12-05 16:11 This is the best ssh tutorial you can find in my opinion: https://youtu.be/3FKsdbjzBcc ---------------------------------------------------------------------- aaronryder773 · 2023-12-05 16:21 When did windows implement ssh? ---------------------------------------------------------------------- wolfnest · 2023-12-05 16:28 Windows 10 ---------------------------------------------------------------------- FineWolf · 2023-12-05 16:41 They didn't implement a custom solution, they are just bundling OpenSSH since Windows 10 as an optional Windows feature. ---------------------------------------------------------------------- ddpbsd · 2023-12-05 16:46 An OLD version of OpenSSH now ---------------------------------------------------------------------- LastTreestar · 2023-12-05 16:51 Screwed how? I use kitty, so I'm concerned about what I don't know about putty. ---------------------------------------------------------------------- AnApexBread · 2023-12-05 17:13 This guide from Digital Ocean is pretty good. ​ Also of note, Powershell now supports SSH by default so these commands work on Windows as well. ​ https://www.digitalocean.com/community/tutorials/how-to-set-up-ssh- keys-on-ubuntu-22-04 ---------------------------------------------------------------------- Kizaing · 2023-12-05 17:40 Putty uses weird key formats (ppk) which isn't compatible with openssh, so you have to convert it or generate a new key if you need to move your SSH keys. So its fine if you only ever use PuTTY but as soon as you try to move elsewhere you have to redo how your keys are stored, which like isn't the end of the world but its pretty annoying ---------------------------------------------------------------------- Cylian91460 · 2023-12-05 18:20 Look at arch wiki ---------------------------------------------------------------------- adamshand · 2023-12-05 19:10 Every SSH server has a public/private key. This is used to allow the client to make sure that it's really connecting to the server it thinks it is. This is normally created automatically by the SSH daemon. Clients can optionally have a public/private key. This can be used to authenticate connections to the server (instead of username/password). You need to create this manually. The basic idea behind public/private keys is that anything encrypted using the public key can only be decrypted by the private key. And anything encrypted by the private key can only be decrypted by the public key. This means that you can share your public key and anyone with your public key now has a way of sending you encrypted messages that only your private key can decrypt. To do passwordless (key based) login, you need to copy your clients ***public*** key to the server (usually into `~/.ssh/`). - Check your `~/.ssh/` folder and see if you already have a public key(s). Keys typically start with `id_` and the public key ends in `.pub`. - If you don't have any keys, create one with: `ssh-keygen` - Now copy your public key to the server you want to do password authentication: `ssh-copy-id ` You should now be able to login without a password. You say you want to have a have unique keys for each host. This is possible but I wouldn't recommend it. Unless you have unusual requirements, it's just extra complexity for no real security gain. To do this, you need to repeat the process to create a key pair for each server (make sure they are named in a way that they don't over write each other and you know which one is which). And then specify the appropriate key each time you do anything with ssh. The above examples are for OpenSSH, I don't use Putty so you'll need to adapt them. ---------------------------------------------------------------------- IacovHall · 2023-12-05 19:11 that video is fantastic, thank you for sharing i will definately watch more of veronica's videos, i like her way of explaining but i'm still confused - how do i create the ssh config file on windows and how do i backup the keys and config and/or move them to other devices, like JuiceSSH on Android? ---------------------------------------------------------------------- thedarkfreak · 2023-12-05 19:56 > how do i create the ssh config file on windows You can just use notepad for that. If you've already made your key using Windows 10+'s built-in SSH, then open a terminal, and type "notepad .ssh\config". Make your configuration changes, and save. Back in the terminal, rename the file from config.txt to config. (__move .ssh\config.txt .ssh\config__ should do it) After that, you can use Notepad to edit the file again if you need to. > how do i backup the keys and config If you're using Windows 10+'s built-in SSH, copy the .ssh folder from your home folder to somewhere else. Done. The .ssh folder contains your configs and your keys. > move them to other devices, like JuiceSSH on Android? You _can_ copy the .ssh folder to other devices, but I recommend not doing so outside of backup purposes. Well, you can copy the config file, but I recommend _not_ copying the keys with the intent of using them simultaneously on different machines. Instead, if you want SSH access on multiple machines, I recommend generating new keys on those machines, and granting access to those keys individually. That way, if you lose one of the machines, you only need to replace _that_ key, not the key on all of the machines. (If a device gets stolen, you want to replace the key on that device so it can't be used. If they're all using the same key, you'll have to replace the key on all of your devices, instead of just disabling that one device's key in the authorized_keys config.) ---------------------------------------------------------------------- thedarkfreak · 2023-12-05 20:01 > You say you want to have a have unique keys for each host. This is possible but I wouldn't recommend it. Unless you have unusual requirements, it's just extra complexity for no real security gain. To do this, you need to repeat the process to create a key pair for each server (make sure they are named in a way that they don't over write each other and you know which one is which). And then specify the appropriate key each time you do anything with ssh. I agree with this in terms of using a unique key for each individual _host_ you connect _to_, which seems to be what OP was talking about, and is the only thing you mention. However, expanding on this, I do recommend having a unique key for each _client_ you connect _from_. The configuration still remains fairly simple in that case(adding a line to authorized_keys for each client key on your hosts, no additional config needed on the clients), but you have less trouble to deal with if a device gets lost/stolen. ---------------------------------------------------------------------- fab_space · 2023-12-05 20:06 1. log in the server 2. execute ssh local host and ctrl-c 3. execute ssh-keygen -t rsa 4. (not best sec) press enter several times 5. copy /root/.ssh/id_rsa.pub in the notepad 6. edit /etc/ssh/sshd_config replacing root access and password auth to yes 7. restart sshd /etc/init.d/sshd restart or ssh restart 8. logout 9. on the client paste id_rsa.pub somewhere 10. chmod 400 that file 11. connect to the server ssh -i /path/of/id_rsa.pub root@serverip 12. 🍻 ---------------------------------------------------------------------- Ovasak · 2023-12-05 20:08 I'm glad that you liked her video, I'm a big fan of her channel! In windows you can create a text document and remove the ".txt" extension at the end of the file. As for moving them to other devices, they are file so you can just move them using a usb cable or any other way you want. Same thing for backing them down. ---------------------------------------------------------------------- Ovasak · 2023-12-05 20:15 Also If you want to create more secure key, Veronica Explains made a new video regarding how to [here](https://youtu.be/tdfBbpJPTGc). ---------------------------------------------------------------------- bristle_beard · 2023-12-05 20:17 Isn't mRemoteNG just a frontend and Putty is usually used on the backend? ---------------------------------------------------------------------- Ovasak · 2023-12-05 20:21 Also If you want to create more secure key, Veronica Explains made a new video regarding how to [here](https://youtu.be/tdfBbpJPTGc). ---------------------------------------------------------------------- IacovHall · 2023-12-05 20:28 thanks! i found a workaround by copying and renaming the known\_hosts file - but removing ".txt" is almost too obvious xD would you see it as good practice to have an individual key per server and device? (for a home user that accesses his network via vpn) and what i can't fathom right now: how does the key know which user it belongs to? is it decided by the "uploading user" with the ssh-copy-id command? or does key based authentication always apply to root? ---------------------------------------------------------------------- DanJOC · 2023-12-05 20:33 I've found that the problem with putty is it stores keys in a format that isn't compatible with openssh. This means you have to convert keys to import them into say, truenas ---------------------------------------------------------------------- ddpbsd · 2023-12-05 20:38 That‘s not much of a problem really. You convert your ssh-keygen generated key to putty‘s format once and you‘re all set. ---------------------------------------------------------------------- highly_confusing · 2023-12-05 20:43 Navigate to your users .ssh folder or wherever you want to store your keys. `ssh-keygen -t ed25519` I would recommend adding a passphrase to your key Then do this to make life easy. It will copy the pubkey to the correct location that will be required to use the keypair for ssh. Usually its in the users home directory `.ssh` folder. Use the username you want the ssh key to be used for. And change x.x.x.x to the ip address or hostname of the device you would like to ssh to. It will ask for the users password. `ssh-copy-id -i /path/to/your/new/ssh.pubkey username@x.x.x.x` then you can login using the private key you created. `ssh -i /path/to/your/new/ssh.privkey username@x.x.x.x` ---------------------------------------------------------------------- thedarkfreak · 2023-12-05 20:45 > would you see it as good practice to have an individual key per server and device? (for a home user that accesses his network via vpn) I recommend having separate keys for each connecting _client_. However, each client having separate keys for each server they connect to is overkill, unless there's a reason a different key is needed(like newer key algorithms not being accepted on an old device) So, for example, if you have two servers(Server1 and Server2), and two clients(laptop and desktop), I would recommend having a separate key on both laptop and desktop, and having Server1 and Server2 trust both those keys. (In this scenario, there are 2 client keys total) I would not recommend having a laptop_server1 and laptop_server2 key on the laptop, and a desktop_server1 and desktop_server2 key on the desktop, and having each server trust their respective keys. IMO, that just gets too unwieldy too fast, for very little to no actual security benefit. (In this scenario, there are 4 client keys total.) It gets unwieldy because of how badly it scales. That was just with two servers and clients. Let's add one more of each. Three servers, three clients. For method 1, you would only need one more key: for the new client. Three keys total. For method 2, you would need _five_ more keys, for _NINE_ keys total. And that's just for six total machines. > and what i can't fathom right now: how does the key know which user it belongs to? is it decided by the "uploading user" with the ssh- copy-id command? Bingo. To be more specific, in a default configuration, each user on a SSH server has a set of keys allowed to connect to the server as that user, usually stored in a file called **authorized_keys** in that user's **$home/.ssh** folder. ssh-copy-id makes a regular SSH connection to a server as a specific user, and then adds the specified key to that user's **authorized_keys** file. ---------------------------------------------------------------------- LastTreestar · 2023-12-05 20:58 Ahhhh... thank you! ---------------------------------------------------------------------- kindrudekid · 2023-12-05 21:00 Doesn’t mremoteng uses putty for ssh anyways ? ---------------------------------------------------------------------- AdrianTeri · 2023-12-05 21:00 >how do you recover from a data loss? (e.g. OS has to be reinstalled and you loose the local putty config) >because i once stood in pooring rain in front of my home because i forgot my keys - i don't want to experience something similar with my VMs ;) Deep underlying problem/issues here ... - Everybody say it with me 3-2-1 backup. And also verify those backups work... - It should be faster to rebuild a server/VM than to debug/troubleshoot things I hear the kids on those crushing games like *Dark Souls* say you have to **git gud**... Well there's no exception here! ---------------------------------------------------------------------- CrazyTillItHurts · 2023-12-05 21:04 > I wouldn't use Putty, it's old and antiquated lol wut ---------------------------------------------------------------------- GSpanFan · 2023-12-05 21:15 I did this last week as a beginner and, it may be clear to you, but it was totally lost on me that I should be creating a pair on the remote machine that I wanted to do the accessing from and then moving the public key to the one I wanted to access via SSH. Perhaps I was misreading the guides, but I kind of assumed that I'd need to run the key generation on the machine I wanted to access. [Maybe that would have worked too, but would have required distribution of the private key.] ---------------------------------------------------------------------- adamshand · 2023-12-05 21:21 I tend to only have a single key on my laptop and rely on `ForwardAgent` if I need to do multiple hops. It's a small security risk, but I only log into machines I control and the convenience is worth it to me. ---------------------------------------------------------------------- Nintenuendo_ · 2023-12-05 21:26 Kitty for life!!! I use this too, it has a nice transparency option, FU putty :p ---------------------------------------------------------------------- du_ra · 2023-12-05 21:36 You shouldn’t put your private key on your server and that’s the thing which has a custom file format. The authentication file format is for OpenSSH. ---------------------------------------------------------------------- IacovHall · 2023-12-05 21:39 thank you for taking your time for giving detailed answers! i use dietpi as my "homeserver OS" ... which apparently handles some things differently as i learn more and more. e.g. there's only the root and dietpi user (which probably is indeed ok for a walled off home setup) - but that's also the reason why i have fail2ban (with it's dietpi stock config in place) installed and want to learn key based authentication ​ BUT apparently dietpi handles the deactivation of pw-logins differently...it does not suffice to edit sshd\_config...still have to figure that one out ​ thank you for the idea of being able to revoke access wasier by having per device-key-pairs i still feel kind of "underprepared" not having a key-pair per server, but yes, would probably be overkill per server AND per device xD ---------------------------------------------------------------------- du_ra · 2023-12-05 21:41 Okay, but you understand that every root user (and some users with specific rights) on the host has access to all the hosts? I wouldn’t say small risk, but that’s debatable. If you just hop, ProxyCommand is the way to go. ---------------------------------------------------------------------- thedarkfreak · 2023-12-05 21:41 Honestly see nothing wrong with this. Technically speaking, it's still one key per client. It's just that there's only ever one client :P ---------------------------------------------------------------------- adamshand · 2023-12-05 21:46 Most of the machines that I log into either I'm the only user. But yeah, I know it's a risk, and it's a good reminder. I used to run systems which were high value targets. These days nobody cares about anything I run (yay!). So I tend to not worry too much. At some point it might bite me. ---------------------------------------------------------------------- thedarkfreak · 2023-12-05 21:56 > BUT apparently dietpi handles the deactivation of pw-logins differently...it does not suffice to edit sshd_config...still have to figure that one out ​Did you restart/reload the sshd daemon/service after changing the config? Those changes don't take until sshd is told to reload. > i still feel kind of "underprepared" not having a key-pair per server, but yes, would probably be overkill per server AND per device xD The way I think of it is both in terms of ease of config and management, as well as thinking of what actually happens if a device with keys is compromised. The basic logic is that having one key per user-server pair is more secure(since the key can only ever be used to access ONE thing), and easier in the event of a compromise, because you only need to regenerate the key and change the config on _one_ server in the event of a compromise. That is, you only need to change the actual key that was leaked on both sides. At first glance, that seems more secure and faster than a compromise in the per-client-key method, where a compromise means you need to update every server to remove the compromised key. Thing is, that supposes that somehow, ONLY that key was compromised. But that's not the most likely compromise scenario. The most likely compromises are someone getting in to your system, or something stealing your system(and therefore getting in to it.) If either of those happen... they've compromised _all the keys on that system._ And that means _all_ your servers need their configs updated to both 1) remove the old keys, and 2) install the new keys. So you've got the same amount of work server-side as you do in the per-device- key method, but you have a lot more work in generating a new set of keys for the replacement client, instead of just one. You just wind up really not getting that much of a benefit by using multiple keys on a single client, and in turn, you have a lot of hassle just to manage it. Heck, if you use the per-client-key method, you can simply management a bit more. Since your authorized_keys file would likely be the same on any machine you used, you could just copy that around each time you need to update it instead of making the change on each machine. This is what I used to do before I switched to using SSH certificates. I would make the changes I needed to to a common authorized_keys file, and I put that on an internal web server. Then, on any machine I needed to reconfigure(or any new VMs I created), I just downloaded that authorized_keys file and everything was already good to go. It made things so much simper. ---------------------------------------------------------------------- IacovHall · 2023-12-05 22:18 >Did you restart/reload the sshd daemon/service after changing the config? Those changes don't take until sshd is told to reload. yes i did, as well as rebooting the machine. so far as i understand currently is, that i have to edit the dietpi.txt and reinstall openssh, for openssh to incorporate the parameters in dietpi.txt. but i don't believe that no easier option exists and i'm still looking into it SSH certificates...how does that work? switching to key based authentication is good, but switching to certs is the next big leap after that? \^\^ ---------------------------------------------------------------------- ZaxLofful · 2023-12-05 22:22 This just happened to me when converting to Linux as my daily driver and it sucks! ---------------------------------------------------------------------- thepenis_mightier · 2023-12-05 22:58 It's something ---------------------------------------------------------------------- Akujinnoninjin · 2023-12-05 23:09 To your edit - for the ```PermitRootLogin``` you want to set it to ```without-passsord``` if you're wanting to enable root ssh access with a key. See https://linux.die.net/man/5/sshd_config for the full config details. My own 2c: slightly better security practice is to create a separate admin user on your clients, and giving it sudo rights. It's not 100% necessary in a homelab, but it's a good habit, and all it really costs is having to type four extra letters before some commands. (And if you use the fish terminal, you can just hit Alt-S). ---------------------------------------------------------------------- lbgdn · 2023-12-05 23:14 You can replace it with [https://github.com/PowerShell/Win32- OpenSSH/](https://github.com/PowerShell/Win32-OpenSSH/) , last release was less than 2 months ago. ---------------------------------------------------------------------- lestrenched · 2023-12-05 23:17 https://www.youtube.com/watch?v=pE3EuiyShoM ---------------------------------------------------------------------- thedarkfreak · 2023-12-05 23:45 I admit I'm not familiar with DietPi, but are you actually using OpenSSH? From what documentation I've found, DietPi uses Dropbear for SSH by default, and can be switched to OpenSSH with DietPi-software. As for SSH certificates... they're a whole different kind of hassle, but they can also enable some convenient workflows, too. Auto-trust of new keys without needing to change any configs on the server, as well as time-limited keys by default, among other things. But it's complicated to work with, and you are more likely to accidentally lock yourself out of a system if you let your cert expire and lose access to the cert signing key. I recommend waiting to work with certs until you're natively familiar with SSH key-based auth. ---------------------------------------------------------------------- ITaggie · 2023-12-05 23:59 Yup, PuTTY has been obsolete for many years now. When anyone (like OP) tells me they use PuTTY still, that is the first place I check for troubleshooting. ---------------------------------------------------------------------- ITaggie · 2023-12-06 00:00 Not true, the public key is also an unsupported format without specific export options. ---------------------------------------------------------------------- stewie410 · 2023-12-06 02:57 > I wouldn't use Putty, it's old and antiquated Wish my boss felt the same; currently I'm the _only_ person on the team that uses either the builtin OpenSSH client or from WSL. I had to make sure I document everything for both CLI & PuTTY users... That said, there's still a _few_ cases I have for PuTTY; but most of that is my lack of knowledge of alternate tools and how to use them effectively (notably for COM3, etc.). ---------------------------------------------------------------------- ScratchinCommander · 2023-12-06 03:33 I'm not sure about obsolete - it's a simple tool, and in a world of bloated software that's nice. ---------------------------------------------------------------------- Anic135 · 2023-12-06 05:03 ive been trying to get OpenSSH to work on Windows for awhile now and its been a miserable time trying to get an Administrator SSH config to work. Im aware OpenSSH is super picky about file permissions and so ive been following the guidance provided for that but what I cant figure out even with Debug3 level logs is why my public key keeps getting accepted but then the connection is "postponed" and then dropped right afterwards. I can see the Firewall rules open for the requested port so I don't think its that. Current guess is Windows is being pissy about the built-in principal security groups, as i'm logged in as a default user via a Microsoft account login who has been granted Admin privileges which from what I gather is not treated quite the same as a local hardware/OS install based Admin account? ---------------------------------------------------------------------- kring1 · 2023-12-06 09:30 puttyget has a "Conversions - Export OpenSSH key" option and you can easily save the same key in both formats alongside each other named id_ed25519.ppk and id_ed25519 ---------------------------------------------------------------------- spherionos2 · 2023-12-06 10:09 This convinced me to finally put certificated based auth on my servers ---------------------------------------------------------------------- IacovHall · 2023-12-06 13:03 thank you for the explanation for certs :) yes, dropbear is standard but I have switched to ssh to use scp and to be able to follow guides regarding openssh :) ---------------------------------------------------------------------- ITaggie · 2023-12-06 13:25 >ssh user@ip That's all you need in any terminal. I'd consider more than that bloated. ---------------------------------------------------------------------- ScratchinCommander · 2023-12-06 13:51 I suppose for Windows, as a GUI tool. On Linux that's all I use, plus config file. ---------------------------------------------------------------------- ITaggie · 2023-12-06 16:46 Who needs a GUI tool to open a terminal connection elsewhere? Literally just open Command Prompt or Powershell if you're on windows and >ssh user@IP ---------------------------------------------------------------------- du_ra · 2023-12-07 23:21 The only difference a the header/footer (and puttygen even displays the correct line to copy/paste in the auth file). The public-key itself is the same. The putty file has afair even the benefit that the public key is not encrypted the the file. ---------------------------------------------------------------------- ScratchinCommander · 2023-12-08 00:25 I wasn't implying anyone needs a GUI, but if they want to, PuTTY is a good choice in my opinion, simplest terminal manager I know of for Windows. It does more than just connect you via SSH, while still being simple and focused on the feature set. ---------------------------------------------------------------------- SpongederpSquarefap · 2023-12-10 15:59 mRemoteNG is dead sadly - no more Dev work is going into it ---------------------------------------------------------------------- IacovHall · 2023-12-10 18:53 thanks... the openssh config file is really neat... thanks to your input I switched to powershell entirely ---------------------------------------------------------------------- IacovHall · 2023-12-10 18:56 well in my case, I am slowly learning what and how I can do stuff in the shell. putty was awesome at first because I also had a saved connection list which I could simply double click. the config file requires me to remember ad hoc the host name, but the connection is en par or even quicker I now realize ---------------------------------------------------------------------- IacovHall · 2023-12-10 19:03 >- Everybody say it with me I'm sorry, and I'm thankful for every experience shared, but this sounds painfully basic and please don't assume that I don't have backups... but my question was primarily (though not well worded) targeting whether there is a best practice. I can go ahead and back up each and everything... but it's not necessarily useful for every file I can backup - either ressource- or time-wise