Using SSH (Secure SHell – basically an encrypted communication and control system from one computer to another) is a wonderful way to get connection from one computer to another, especially when a computer doesn’t have a monitor or keyboard attached to it. For the computers around my place, this is mostly the case for the Raspberry Pis that I have set up. Being able to log into them and run commands just like I was sitting there at the terminal lets me set them up and do maintenance without the extra work of dragging the monitor and keyboard from place to place. (Not to mention pulling them out of the places that I have them tucked back into!)
So I use SSH quite a bit and I love it. The Raspberry Pi images keep changing the defaults for SSH. For a while it defaulted to not being enabled, and I had to plug everything into the Pi when I first booted it to set it up to use SSH before then removing it and putting the box where I wanted. Then for a while it was turned on by default. For me this was wonderful and helped me out tremendously. It reduced the effort of getting a system up and running, and since using SSH is part of my regular work flow, I was going to need it anyway. I was happy to have things easier. Then they once again decided to change and turn it off by default again. This was disappointing to me on a personal level, but I do see their reasoning, though, as I can imagine that there could be many people out there who would hook a system up, and maybe even have it internet-facing and never think about SSH or worrying about securing it. They would then be just begging any hacker to walk right in and take complete of control of their box without any effort at all. To turn it on they built in a workaround that remains easy, and does not require a monitor or keyboard to be attached, while also keeping it safe for people who never feel like getting that far into the details of the system.
If you are running a regular workstation with the Raspberry Pi, then you can just type in the command
sudo raspi-config and enable it in the settings. Mostly what I want is to run it on a headless system, so for those of us who do it like that, after the image is put on the SD card, we need to open it up and put a file named ‘ssh’ into the root directory. The file does not have an extension, and it should be empty. (Well, it might not need to be, but it won’t help to have anything in there, so why take the chance?) This is spelled out on this page.
Now to get to the meat of the matter. The basic sign-on process for SSH uses a user name and password. From the Linux command line, you enter
ssh user@server to request a login. (Replacing user with the desired user name, and server with the server name.) If you entered it correctly then it will ask for your password, and if everything is entered correctly then you should be in. If the
user@ is left off and only
ssh server is sent, then it will attempt to log in using the current logged in user of the machine that you are currently on. (The target machine and the current one will both be the same user.) This has one complication that surprised me – if you type in
sudo ssh server then once the ssh program is passed control, the user that it sees is root, not a normal user, because of the command
sudo in front of it.
Now, even if you have a good password, it is even more secure to actually sign in to SSH with Authentication Keys. This is an encrypted key that allows all of the login/authentication to happen automatically between the systems, and you can set the level of encryption to whatever makes you comfortable. Of course, setting the encryption to a higher level puts more work on the computer to deal with it, so there’s always a trade-off. You need to weigh the costs and benefits of it all and also determine how much of a risk you’re taking with it.
You create the key by using
ssh-keygen -b 2048 , There are many other options, and the number after the -b determines the bit level of the encryption. It seems like the right balance ends up being in the range of 2048-4096 still. There are plenty of opinions out there, but here’s just one well reasoned example of it. What it also comes down to is that this key pair is only used in the authentication phase, during which the two computers set up a symmetrical key between the two of them that is then used for the remainder of the connection time. (Well, if you have a long enough session it might negotiate a new key at some point. I don’t know the details, nor do I care enough to research them.) If you are more worried about people cracking your authentication keys then one method is to simply only use one for some limited amount of time. (Perhaps change them every month, or every year.) Then there is a much shorter window of time for anyone to be able to use brute force methods to crack the key. As soon as the key has been replaced, the old one has no further value in getting into the system.
Once you have the keys generated, you then need to get them onto the remote computer. This is done with
ssh-copy-id -i input-file user@server . The -i input-file is to specify the location of where the key file is on the computer that is sending the file. When creating the file with the ssh-keygen command, I just accepted its default location, and the ssh-copy-id command also has that as the default, so I was able to leave off the -i input-file and it still worked perfectly. If any other location is required, then it can be spelled out there. (The default is ~/.ssh/ and then the file name, which depends on which encryption format is being used.)
Once everything is in place, there is no more need for entering in passwords, because the two machines will handle the authentication between them. You can also have a password required to even unlock the key file and let it be usable from the client computer, which would be a safer way to go, but in my home environment is overkill. Of course, this only works between defined end-points. It would need to be set up between each pair of machines that needed to talk to each other. That is a definite down-side for it, vs. a password login, but I don’t know how much impact it would really have. At least for my purposes, there are only a few machines that need to talk to each other on a regular basis, so it’s far preferable to do the authentication keys.