SDB:Configure openSSH

openSSH

Basics - Configure openSSH - SFTP usage - SCP usage - Public key authentication - Tunnels - SSH Agent

This article describes some of the commonly used options for OpenSSH. This can help you to improve security and ease of use. Please make sure you are already capable of using openSSH for connections, before changing any options. This will make it easier for you to find the problem when you lock yourself out. Please read openSSH basics in order to set up your first connection.

Update to version: 15.5
This article needs to be tested for a newer version. If you are using this guide on the newer version and you find the guide up-to-date to this version, please add the version number to the Knowledge bar. Please refer to version related jobs: SDB pages for more information.

Tested on openSUSE

11.3
11.2

Recommended articles

Related articles

Assumptions

To work with this article basic Linux/OpenSUSE knowledge is needed, including:

Working from the command line
Editing text files
Gaining root privileges (using su, sudo or login as root)
Familiarity with YaST modules:“Users and Groups” and "Firewall"

And of course, you must have an up and running network. If you would like to set up connections from outside your LAN, you must be able to open the necessary port on your router.

Configuration Files

Both SSHD and SSH make use of configuration (config) files. These files can easily be edited by your favorite text editor. When you first look at the configuration files, you will notice that most options are commented out. (E.g. # Port) This means that they will be read as a “comment” and not actual settings.

If this is regarding variable settings, it means the defaults will be used. A nice thing is, the by default commented options are showing the default value, so you can get an idea what the connection is doing in its default settings. In order to modify an option, uncomment it (remove the # in front of the line) and change the value behind the option. Whenever you feel the new setting is not working for you, just place back the comment (#) and the default will be used again.

SSHD – The server

SSHD (Secure Shell Daemon) should be run on the server. (Remote host). The SSHD manages four tasks: incoming connections, authentication, rules and encryption.

The SSHD uses only one configuration file, which can be found in /etc/ssh/sshd_config. This file can be edited using your favorite editor as root. The configuration of the SSHD is quite general and only to build in limitations for the users that (try) to login. The actual connection parameters will be set from the client side.

When setting up the SSHD you must keep in mind what you think is safe or appropriate to allow. For instance: if you prohibit X forwarding in SSHD, setting up the client for X forwarding would be useless. So consider wisely the purpose of the SSH connection when setting up the SSHD.

It is also possible to configure the SSHD under Yast2 by installing the yast2-sshd package. This is a GUI which will update /etc/ssh/sshd_config for you. In this article we will stick to editing /etc/ssh/sshd_config directly.

SSH – The Client

SSH (Secure Shell) Is one of the client programs of the openSSH package. This program is used to login in to a remote shell or to directly run a remote command. In this article we will refer to the SSH configuration files, although they also apply to SFTP and SCP.

There are three ways to configure SSH. Al three ways have the same options wich will be passed as arguments to SSH.

System wide configuration file: /etc/ssh/ssh_config
Personal configuration file: ~/.ssh/config
Command line arguments

When arguments are contradicting, the last given argument will be used. So command line arguments overrules both configuration files and the personal configuration overrules the system wide configuration file.

If you are running a system with multiple users, and these users again have their own preferences or use different remote hosts, a wise set up will be as follows:

Some general settings in the system wide configuration /etc/ssh/ssh_config. You must be root to edit this file.
Host specific connection details in the personal config file ~/.ssh/config. Any user can edit his own config file. Allowing him to set up his own host and connection data, without the need of root privileges. Use this file to setup the configuration you need for (almost) every connection.
Command line arguments can be used to override or to use a certain parameter sometimes. (e.g. for testing or maintenance).

Keep in mind that the SSH protocol is meant to be used over a insecure network between two untrusted hosts. This means security is not only the issue for the server side, both also on the client side. So for instance, if you don't trust the server, don't enable X forwarding. A misguided admin on a spoofed server may be monitoring your exact keystrokes (e.g. passwords) that are sent to the X server. So, don't just go enable all the features in the configuration files, only enable what you need. The good thing of the set up above is that the users themselves can determine their trust on a per-host basis.

Reloading Configuration

Whenever you made a change to /etc/ssh/sshd_config you must restart the SSHD or make it reload its configuration by typing:

# rcsshd restart

or

# rcsshd reload

You can do this with a running SSH connection and you don't need to log out. But the changes will only take effect for each user the next time they try to log in.

Listening to incoming connections

The first step in (actual) configuring is: “Where will SSHD be listening to?” For this we can set the following options:

Address

By default the SSHD is listening on all local addresses. If you have a computer with multiple network connections and you only want to use one or some of them, you can specify this. Find and change the following in /etc/ssh/sshd_config as root:

#ListenAddress 0.0.0.0
-to-
ListenAddress * your ip *

If you are using only a single interface or a network with DHCP, it is wise to keep this in its default setting. If you would like to use multiple interfaces, but not all, you can specify each address with a new line starting with ListenAddress. Each line needs to be preceded by the Port option.

Port

By default the SSHD is listening on Port 22. You can choose not to change this. But if there were attackers looking for possible connections to break into, they would first be looking for the most common ports, like 22. Changing the port number considerably reduces the number of automated attacks performed by systematic attackers or Zombie Computers. On the other hand, changing the port number forces users to configure this alternative port on all the clients that want to connect to you. We will use port 2222 as alternative port in the following examples. To change the listening port number, edit /etc/ssh/sshd_config as root and change:

#Port 22
-to-
Port 2222

Remember to open the new port on your firewall, and if applicable, close the old port. Also don't forget to reload the new configuration

Setup your SSH to connect to SSHD

Now you will need to set up SSH (the client) to connect to the earlier set port on the SSHD. First of all, edit /etc/ssh/ssh_config. You will see the Host * option. This means all remote hosts. All options specified under a “Host” line will apply to that host only, until a next Host line is specified. This means that all the following options in this file apply to all hosts. Keep this option in it's default value. Check the Protocol option. This one must be un-commented and set to 2 (Protocol 2). This is to make sure the old and now unsafe protocol 1 will not be used. Now safe and close this file. When there are no connections running, you do not have to restart anything for the changes to take affect. Changes will be effective the next time you will make a SSH connection.

Personal configuration file

This is how to set up a personal configuration file with per-host data. First check if the .ssh directory exists in your home directory, with the proper owner (you) and permissions. If the directory does not exist, create it as regular user.

$ mkdir ~/.ssh $ chmod 700 ~/.ssh

Now create a new text file using your favourite editor and save it as ~/.ssh/config. Now we can configure our host-specific connections:

Host ssh-server
      Hostname 192.168.100.103
      Port 2222

Here you set up an easy name (ssh-server) for remote host address 192.168.100.103. The Host option can be set to any name you like, as long as the Hostname option is specified. If the Hostname option is not specified, you will need to put the actual address behind the Host option.

Now we can connect to the earlier configured SSHD, listening on port 2222 on address 192.168.100.103 and log in as the current user, typing:

$ssh ssh-server

To log in under a different user name on the remote system type:

$ssh user@ssh-server

And you will be prompted for a password.

You can specify multiple hosts and give them their own settings:

 Host ssh-server
      Hostname 192.168.100.103
      Port 2222

Host workserver
      Hostname  ssh.host.org
      Port 5041
      Compression yes

Compression is convenient to be enabled over slow connections (eg. dial-up). If enabled over a fast connection it will only slow your connection down, consuming many server and client resources.

Access Control

These settings are optional. Use with care, you can lock yourself out.

This is an important part for the security of your SSHD. Who will be allowed to connect and then log in to your computer. First of all, don't use simple passwords. In the basic configuration any host can connect to your computer. If an attacker would know your ip and listening port (which can be obtained quite easy) he could easily launch a dictionary based attack on you. If the attacker knows your name is “John Smith” your user name most probably is john, js, john.smith etc. If then again you password is your dog's name one can easily break into your system. Also don't trust 3rd party's password databases, like your e-mail, forum and wiki accounts. Now it's time to keep a strict separation between passwords used on the internet and your computer's passwords. It's always good security practice to use random capitalized and non capitalized alphanumeric and non alphanumeric characters in your passwords.

Limit by Hosts

If there are fixed locations from where you would want to log in to your SSHD, you can set up an per-host access control. In /etc/hosts.allow you enter the following lines for the hosts you specifically allow, e.g.:

sshd : 127.0.0.1   : allow
sshd : 192.168.    : allow
sshd : 130.57.5.70 : allow
sshd : 10.         : allow

Next enter all that need to be denied in /etc/hosts.deny,

sshd : ALL         : deny

If you are interested in a more dynamic host access control, you might want to use the DenyHosts script. This will allow you to log in from any location you like, while DenyHosts is filtering out malicious hosts based on rules like log-in attempts. DenyHosts will then again add this malicious hosts to /etc/hosts.deny. It has more nice functions like logging and reporting trough e-mail.

Limit by Users

SSHD allows to limit the login only for special users or groups. Wherever possible, use groups to enable/disable access. This way, it's much simpler to edit the access rights afterward.

This is options can be entered in /etc/ssh/sshd_config and are processed in the following order,

PermitRootlogin
DenyUsers
AllowUsers
DenyGroups
AllowGroups

PermitRootLogin can be set to yes or no. The default is yes. It is wise to change it to no, since every *NIX system has the user root and this user is almighty, so it is the ideal user to use to break into a system. You can still gain Root privileges by typing su or sudo after logging in as a normal user. You might even want to Restrict the usage of su.

The other options can be followed by a list of user or group name patterns, separated by spaces. Only names are valid; a numerical user or group ID is not recognized. You can edit /etc/ssh/sshd_config with your favorite editor and add the following line:

AllowGroups sshlogin

This will allow only the users that are member of the group sshlogin to login to the server. Now open Yast2 > Security and Users > User and Group Management to create the group sshlogin and add the users who must be allowed to login to the server. If you would now try to log in with a user with is not not included in this group, or even non-existent, you still will be prompted for a password and you will still have a number of attempts, but getting the “Incorrect Password” error all the time. So attackers won't know if the password or the user is incorrect.

Authentication

OpenSSH server can authenticate users using its built-in authentication systems:

keyboard-interactive (passwords and challenge-response)
Public key authentication
Kerberos/GSSAPI

In this article only the use keyboard-interactive and public key authentication are described. You are more than welcome to expand this article with other methods.

Keyboard-interactive

When running the SSHD under OpenSUSE, the most common way for keyboard interactive authentication is PAM. PAM is also used for local authentication of users and makes use of the same passwords that are set trough Yast. The following options allow the use of PAM for authentication, account and session check :

ChallengeResponseAuthentication yes
UsePAM yes

These are default values.

Public Key Authentication

Public key authentication allows you to log in on the server, without a password or to improve security. The key pair is generated on the client side and the private key must be stored in a secure place. The public key is sent to the server and stored in the “authorized key file”. Meaning that the computer (and user) holding the private key can sign in to the computer holding the public key.

From main article OpenSSH public key authentication

Key generation

If ssh-keygen is used without any arguments, a 2048 bit RSA key will be generated. The private key will be stored under ~/.ssh/id_rsa and the public key under ~/.ssh/id_rsa.pub. Based upon your needs, you can choose to set a password. Leaving the lines blank will cause no password to be set.

$ ssh-keygen
Enter file in which to save the key (/home/your_user/.ssh/id_rsa): <Enter>
Enter passphrase (empty for no passphrase): <Enter>
Enter same passphrase again: <Enter>
Your identification has been saved...\

Upload your key

In order to use your generated key for authentication, your public key is to be uploaded:

$ ssh-copy-id user@ssh.yourserver.org
Password:
Now try logging into the machine, with "ssh 'user@ssh.yourserver.org'", and check in:
~/.ssh/authorized_keys
to make sure we haven't added extra keys that you weren't expecting.

If you want to know more about this subject, including completely disabling password authentication to increase security and the use of DSA or other custom key options, read the full article

Troubleshooting

Public key authentication is not working anymore

Version: 11.3+ The following applies starting from openSUSE 11.3.

Since openSSH 5.4, relative paths in configuration are no longer allowed. When pointing to the authorized _keys file make sure you use %h/ in front of the path to your authorized_keys file. Older versions still can do without. In /etc/ssh/sshd_config change:

AuthorizedKeysFile .ssh/authorized_keys
-to-
AuthorizedKeysFile %h/.ssh/authorized_keys