SSH allows you to connect to a remote computer and run task remotely. In my situation, this is great for remotely logging in to one of our lab computers that is designed for intensive computing tasks (24GB of RAM!).
Using SSH is also fairly straightforward. To get started logging in to a remote computer/server that you have access to, just type the following in Terminal (and substitute your own username and the address of your target computer):
Enter your password for the remote computer.
Alternatively, instead of dealing with passwords every time you log in to a remote computer, generate some SSH keys! Not only can you eliminate the need to use a password and automatically log in when you type your ssh command, but by using keys you can virtually eliminate people being able to use a brute force password attack to break in to your computer/server!
First, generate your key set. The following command will generate a private and a public key. The public key can be placed on any server you want SSH key access to. You can just send the public key to anyone who has the capabilities (both the know-how and authorization) to install it in the correct location on the computer/server you’d like to connect to. The private key on your computer will then be able to match with your public key on any computer that the public key has been installed on! No passwords needed for connection!
Generate the keys:
$ssh-keygen -t rsa
Feel free to use an empty password when you are prompted; just hit the “Enter” button and then confirm by hitting the “Enter” button again. This password is only used when physically using your computer to initiate a SSH session. For most people, having a password to initiate a SSH from their computer becomes more of a hassle than it’s worth. However, if you anticipate someone else using your computer, and you’d like to prevent them from easily using SSH to remotely login to servers that you’ve installed SSH keys on, then it would be advised to enable a password for your SSH sessions.
Looking in your
folder reveals the following:
$ls ~/.ssh id_rsa id_rsa.pub known_hosts
The “id_rsa.pub” file is your public key file. This is the file that can be transferred to other computers to enable password-free SSH capabilities on those computers.
Now that we have our keys, we need to transfer the public key to the server. Assuming you have administrative privileges for the server, there are two options for putting the public key on the server. If it’s the first key, we can use the following command:
That will not only copy the public key from the computer to the server, but it will also create the proper directories if they don’t already exist on the server.
Otherwise, if you have the appropriate permissions, you can also use the following command to append your public key to an existing “authorized_keys” file on the server:
cat ~/.ssh/id_rsa.pub | ssh username@remotecomputeraddress 'cat >> .ssh/authorized_keys'
But, in order for the value of SSH keys to be fully realized, the destination computer/server should have password authentication disabled. Doing so means that only computers with authorized SSH keys will be allowed access
I’m using SSH keys to lock down my home Synology server. To do this, I SSH’d into the Synology as user “root”, since “root” is the only user authorized to make system changes.
By default, Synology only seems to have the text editing program “vi”. Let me tell you, it is NOT intuitive how to use it. For example, to delete characters, you have to use the ‘x’ key! Luckily the University of Washington has a nice tutorial on how to use “vi” for editing documents.
After quitting (don’t forget to save changes!), we need to restart the SSH service. I ended up doing this via the GUI since some of the common command line suggestions for restarting SSH didn’t work.
Now, when trying to SSH in, you’ll only be allowed in if you’re doing trying to do so from an authorized computer that has a public key installed on the server. On that note, it would be prudent to backup your private key so that if your computer dies, you’ll still be able to authenticate with the remote computer by installing your private key on a new client computer.