- 1 Assumptions
- 2 Configuration Files
- 3 Listening to incoming connections
- 4 Setup your SSH to connect to SSHD
- 5 Access Control
- 6 Authentication
- 7 Troubleshooting
- 8 See also
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.
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.
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.
Whenever you made a change to /etc/ssh/sshd_config you must restart the SSHD or make it reload its configuration by typing:
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:
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.
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
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:
To log in under a different user name on the remote system type:
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.
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 : 188.8.131.52 : 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 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:
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.
OpenSSH server can authenticate users using its built-in authentication systems:
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
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.
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 firstname.lastname@example.org
Now try logging into the machine, with "ssh 'email@example.com'", and check in:
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
Public key authentication is not working anymore
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
$ man hosts_access
$ man ssh
$ man ssh_config
$ man sshd
$ man sshd_config
- SDB:OpenSSH tunnels
- SDB:SFTP server with Chroot
- Securing openSUSE
- SDB:SSH systematic attack protection