SSH Config File for Easier Logins

Using SSH is relatively straightforward and pretty easy. Simply enter something like the following into Terminal:

$ssh user@computer.ip.address

If you don’t already utilize security keys, you’ll be prompted for the password associated with the user that you’re trying to login as. Voila, you’re in and commanding a computer/server remotely.

Despite this simplicity, if you need to access multiple computers/servers and those computers/servers don’t have nice, easy-to-remember domain names, then you’re left with the task of remembering IP addresses for all the different computers/servers. Of course, you can write these down somewhere for future reference, but it would be much nicer if SSH could remember this info for you. As it turns out, SSH can store that info for you! All you have to do is create a config file with the necessary info.

First, on your client computer (i.e. the computer you’ll be using to connect to the remote computer/server), use Terminal to change to the hidden SSH directory:

$cd ~/.ssh

This can also be done via the graphical user interface (GUI) of your computer, if it’s easier. You’ll just have to enable viewing of hidden files/folders. To do so, while you are in a file browser window, go to the “Edit” menu at the top of your screen, select “Preferences” and then check to box to “Show hidden and backup files.” Now you’ll be able to see the “.ssh” folder.

Once there, create a file called “config”. You can do this in a variety of ways. I’ve used the “touch” command in Terminal:

$touch config

Now, we need to add the needed text to this config file. I’ve just used a graphical text editor (gedit) by entering the following in Terminal:

$gksudo gedit config

In the file, I’ve entered the minimally necessary info to accomplish what I want (which is to be able to connect to remote computers/servers without remembering long IP addresses or domain names). For each remote computer/server that you’ll connect to, you’ll have the following text in the config file:

Host easy_to_remember_nickname
HostName IP_address_of_remote_server
User remote_server_login_username
ControlMaster auto
ServerAliveInterval 30
ServerAliveCountMax 3

Now, just save this config file and you’re done! Here’s an example of what the config file might look like with actual info:

Host hotdogs
HostName 192.168.1.1
User MyUserIDforTheServer
ControlMaster auto
ServerAliveInterval 30
ServerAliveCountMax 3

Now, when I decide to use SSH to login to the server located at address 192.168.1.1, all I have to enter into Terminal is this:

$ssh hotdogs

Additionally, you can append additional entries to this file for each server that you connect to.

Oh, and as for the other info in the config file, I’m not fully certain what they all do (the info for this was provided by a computer guru who works with our lab):

ControlMaster – Don’t know
SererAliveInterval 30 – This is for keeping the connection alive.
ServerAliveCountMax – This is for keeping the connection alive.

Of course, you still have to remember the “pet names” that you give to your servers, but it’s much easier to remember English words that it is to remember a series of digits associated with a particular server.

Synology-specific and user-specific SSH key requirements

Earlier, I figured out how to set up SSH keys for SSH authentication in to a Synology server, and eliminate the use of a password for authentication.

These were steps towards securing the Synology, but what I really wanted to accomplish was being able to disable the “root” account to really put the server on lockdown. Although the process is technically very easy (just edit the /etc/ssh/sshd_config file and change “PermitRootLogin” to “yes”), I still needed to verify that I could SSH in to the Synology with another user account. Having SSH’d in to the Synology in the past, I had learned that the only other user account (besides “root”) that has SSH permissions by default is the “admin” account.

So, knowing that I had already established private and public keys on my computer AND had connected to the Synology from my computer using said keys, I tried to SSH with the admin account. What happened? Got this message: “Permission denied (publickey).”

That’s both good and bad.

Good that the Synology is definitely not using password authentication any more.
Bad that I can only login using the “root” account.

So, how to resolve this? Since I had been under the impression that the server just needed a single public key that corresponded to a single private key, I was a bit stumped. I had assumed that the public key provided to the Synology would apply to all existing user accounts. After a fair amount of searching (and I think perusing the Synology forums), I stumbled across the reason for this.

It turns out that each individual user has their own location on the Synology to store authorized public keys! After discovering that, it was fairly straightforward to add my existing public key on my computer to the appropriate user’s (in this case, “admin”) SSH authorized keys file. I used the following command to accomplish this:

$cat /path/to/ssh_public_key/id_rsa.pub | ssh root@synologyaddress 'cat >> /volume1/homes/SynologyUserName/.ssh/authorized_keys'

The brief explanation of the command:
First we used “cat”, which normally prints the text of your intended file (in this case, the id_rsa.pub) to the screen. But, instead of printing the info to the screen we “piped” that info (that’s the “|” character) to our SSH connection. The info of the “id_rsa.pub” file gets sent to server over our SSH connection and then we tell the server to use “cat” to append (that’s the purpose of the “>>“) that information to the authorized keys file for the specific user.

After doing that, I can now connect using the “admin” user account. That means I can now disable the “root” user login capabilities.

Secure Shell (SSH) SSHure iSSH SSHweet!

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):

$ssh username@remotecomputeraddress

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

~/.ssh


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:

$ssh-copy-id username@remotecomputeraddress


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.

$ssh root@SynologyIPaddress


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.

$vi /etc/ssh/sshd_config


Once you’re in the file, remove the “#” from in front of the two lines shown below AND change “yes” to “no” in the line “PasswordAuthentication”.  Then, be sure to save the file.
samb@Mephistopheles: ~_018

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.