Linux Commands

Setting Proper .ssh/config Permissions

The SSH protocol is a secure protocol that is usually used to connect to remote devices such as servers and network devices, including routers and switches. It works in a client-server setup and, by default,  listens on port 22 ( although this can be changed when needed ). SSH  employs different encryption and hashing techniques to ensure the communication between the client and the remote host is encrypted and safe from eavesdropping.

SSH files are stored in the .ssh folder.  This is a hidden folder that resides in the home directory. The  .ssh directory is not created by default; it is created when you initiate a connection with a remote host or use the ssh-keygen command to generate the private and public authentication keys as when you want to set up passwordless ssh authentication.

The .ssh folder.  contains essential SSH files such as:

  1. Public and Private keys ( id_rsa and  id_rsa.pub ).
  2. The known_hosts file – Contains public keys of all the remote systems that you have connected to.
  3. The  config client configuration file

If the config file doesn’t exist, you can easily create one as shown.

$ touch ~/.ssh/config

The .ssh/config client configuration file

Each time you initiate an SSH connection, you need to specify details such as the IP address or domain name and the port SSH is listening to. For example,

$ ssh [email protected]  -p 22

It can be hectic to have to always remember such details. And this is where the ~/.ssh/config file comes in.  The ~/.ssh/config file is a configuration file that allows you to configure per-user configuration details of the remote host. It saves you the agony of always having to recall the per-host details required for connection.

A sample config file appears as shown.

Host staging-server
     HostName 192.168.2.103
     User james
     Port 22

A simple SSH command into the remote host  would look as follows:

$ ssh staging-server

The .ssh/config  file permissions 

By default, the  ~/.ssh/config client configuration file possesses the  644 file permissions. You can verify that using the ls -la command as follows.

$ ls -la ~/.ssh/config

This implies that the owner and group of the file both have read and write permissions (rw) while other users have read permissions only (r).

-rw-rw-r--

NOTE:

As a rule of thumb, never assign write permissions to other users. This poses a security risk to your file, and other users who are not yourself or in your group can modify the contents of the file. Assigning write permissions will result in the ‘Bad owner or permissions’  error as indicated below.

Here, the config file was assigned the permissions 666. This implies that everyone can both read and write the file.

Similarly, the same case applies here where the file has been assigned 777 permissions. This implies that everyone can read, write and execute the file. Simply put, anyone has all the rights to the potentially dangerous file.

Best practice recommends that you leave the default permissions at 664 or 600, where only the owner has read and write permissions (rw). This way, the file remains safe from being modified by unauthorized users.

Additionally,  ensure that you own the file. If the file is changed to another user, SSH will not be able to resolve the hostname provided in the config file.

In the example below, the ~/.ssh/config ownership has been set to bob:bob.

To resolve this issue, I reverted back to the original file ownership using the chown command.

$ sudo chown james:james ~/.ssh/config

With the file permissions reverted, now I can have access by invoking the SSH command followed by the hostname specified in the config file.

$ ssh staging-server

And that is all you need to know about setting permissions on the ~/.ssh/config file. Ensure you don’t set read permissions to the rest of the users and ensure that you own the file.

About the author

Karim Buzdar

Karim Buzdar holds a degree in telecommunication engineering and holds several sysadmin certifications. As an IT engineer and technical author, he writes for various web sites. He blogs at LinuxWays.