How to configure SSH
The sshd service reads the settings from the configuration file /etc/ssh/sshd_config . This file contains keyword-argument pairs, one pair on one line. For each keyword, the first received value will be used (the exception is several directives that can be used several times, and each value will be taken into account, for example, Port and ListenAddress ).
Arguments can optionally be enclosed in double quotation marks ( “ ) to pass arguments containing spaces.
Keywords are not case sensitive, and arguments are case sensitive.
Many directives are commented out, but they indicate a default value that is used anyway. If you are satisfied with the default value, then you do not need to change anything. If you want a different value, then you need to uncomment the line with the corresponding directive (remove the # character ) and make changes.
Additionally, you can specify command line options – they take precedence over the settings in the configuration file.
SSH Service Restart
If between sshd.service and sshd.socket (for details, see the section ” Managing the OpenSSH service “), you chose to run sshd.service , so that the changes made to the configuration file take effect, you must restart the service:
sudo systemctl restart sshd.service
sudo systemctl restart sshd.socket
How to change the port on which OpenSSH is running
All settings are made in the / etc / ssh / sshd_config file or in the sshd launch command line .
For sshd.socket, changing the port that the service is listening on is different.
If you use sshd.service, then the port change also occurs in the file / etc / ssh / sshd_config . To do this, uncomment the Port directive and specify a new value:
You can also set the port using ListenAddress.
If you use sshd.socket and want to change the listening port for SSH, then you need to edit the special file as follows:
sudo systemctl edit sshd.socket
[Socket] ListenStream= ListenStream=23456
[Socket] ListenStream= ListenStream=22.214.171.124:12345
For sshd.socket, other settings, as usual, are in the /etc/ssh/sshd_config file. But the Port and ListenAddress directives will be ignored (if socket listening is selected).
How to choose an interface (IP) to listen to
The system can have several network interfaces with several IP addresses, by default sshd listens for them all, including IPv6 addresses:
ListenAddress 0.0.0.0 ListenAddress ::
If you want the computer on the local network to be available only for devices on the local network, you can specify its local IP:
ListenAddress hostname|address [rdomain domain] ListenAddress hostname:port [rdomain domain] ListenAddress IPv4_address:port [rdomain domain] ListenAddress [hostname|address]:port [rdomain domain]
The rdomain qualifier is optional; it is related to routing.
Also note that with ListenAddress , the host name (address) OR port must be specified. You can specify the host name (address) separately, you can specify the port separately, and you can also specify them together. In all cases, rdomain may be absent.
Command line options (about their use later) take precedence over configuration file directives. Including the option to set the port used causes Port to be ignored in the configuration file. But the ports specified with ListenAddress overwrite the ports in the command line.
You can specify a specific IP that will be listened for while waiting for connections. And with the AddressFamily option you can choose to listen to all addresses, only IPv4 or only IPv6:
- any (by default, any addresses)
- inet (use only IPv4)
- inet6 (use only IPv6),
Why root user can not connect via SSH with the correct password. How to prohibit or allow root SSH
If when connecting to a remote system via SSH you encounter an error that you cannot log in as an SSH user even with the correct password:
Permission denied, please try again. Permission denied (publickey,password).
Then check the value of the PermitRootLogin directive :
The PermitRootLogin directive determines whether root can log in using ssh. The arguments can be: yes , prohibit-password , forced-commands-only or no . The default value is prohibit-password .
If this option is set to prohibit-password (or the deprecated alias without-password ), password logging and interactive keyboard authentication are disabled for the root user.
If this option is set to forced-commands-only , root login with public key authentication will be allowed, but only if the ForceCommand option with a command was specified (this can be useful for receiving remote backups, even if normal root login is not allowed). All other authentication methods are disabled for root.
If this option is set to no , then root is not allowed to log in at all.
If the option is set to yes , then root entry is allowed without restrictions.
So, if you encounter a problem that you cannot log in with the correct password as root, then either configure the login without a password using the public key, or set the value of this directive to yes .
Deny and allow SSH login with a password for ordinary users
A little higher, we considered the option when the root user is prohibited from logging in with a password. The same configuration can be done for all other users, the PasswordAuthentication directive is used for this . The default value is yes , that is, password entry is allowed. To prohibit password entry for all users, set the value of this directive to no .
Permission to enter without password
The PermitEmptyPasswords directive is responsible for allowing login without a password . It is needed for specific cases to allow access to accounts with an empty password line. The default is no .
How to allow or deny users log in via SSH
There are 4 directives that allow or prohibit users and groups from connecting to SSH. These directives are in processing order: DenyUsers , AllowUsers , DenyGroups and finally AllowGroups .
The AllowUsers keyword can be followed by a list of user name templates separated by spaces, for example:
AllowUsers alice bob
Further about templates which can accept directives DenyUsers, AllowUsers, DenyGroups and AllowGroups.
Templates in SSH Settings File
A pattern consists of zero or more characters that are not white spaces, ‘ * ‘ (a wildcard that matches zero or more characters), and also ‘ ? ‘(wildcard character that matches exactly one any character). For example, to characterize any host in the domain set “.co.uk”, you can use the following template:
The list of patterns is a few comma-separated patterns. Templates within the list can have the opposite meaning if they are preceded by an exclamation mark (” ! “). For example, to allow a key to be used from anywhere inside the organization, except for the dialup pool, you can use the following (in authorized_keys ):
The solution to the previous situation is to include a term that will lead to a positive match, it can be a wildcard:
Using the directives (listed in order of processing) DenyUsers , AllowUsers , DenyGroups and AllowGroups and templates, you can configure permissions to access SSH over IP.
Let’s look at a few examples. If you add filtering with AllowUsers to the sshd_config file :
AllowUsers [email protected]* [email protected]* otherid1 otherid2
To allow access to SSH to any users, but only from certain IPs, use the AllowUsers directive with a wildcard in the /etc/ssh/sshd_config file :
from="192.168.1.*,192.168.2.*" ssh-rsa AAAAB3NzaC1yc2EAAAADAQABAAABA...etc...mnMo7n1DD useralias
In this example, the public key for useralias will only work from the given addresses.
Configure SSH Logs
The SSH service does not keep its own log and writes events to the system log.
You can configure the logging detail — the level of verbality, that is, which messages will be written to this journal. For this, the LogLevel directive is used . Its default value is INFO . The following options are also available:
DEBUG and DEBUG1 are equivalents. DEBUG2 and DEBUG3 – each indicates higher levels of debugging output.
Logging at the DEBUG level violates user privacy policies and is not recommended.
Starting SSH without disconnecting from the terminal
Starting the sshd service is described in the first part . You can also run the sshd daemon by file name. To do this, specify the full path to the sshd file to find out:
which sshd /usr/bin/sshd
Running sshd in this way will disconnect from the terminal (will go to background execution) and will not output anything to standard output.
You can start sshd as a process without disconnecting from the terminal (so that the process does not become a daemon), use the -D option to do this – this simplifies the process of monitoring SSH operation, since messages about events and service problems will be output to standard output. Additionally, you can specify the -d option to enable debugging mode:
sudo /usr/bin/sshd -D -d
Running SSH with a different configuration file
Using the -f option, you can specify the path to another configuration file (the default value is / etc / ssh / sshd_config ). sshd will refuse to start without a configuration file.
How to check SSH configuration file without starting a service
Test mode. It only checks the correctness of the configuration file and the efficiency of the keys. This is useful for reliably updating sshd, as configuration parameters may change.
Advanced test mode. With this option, sshd will verify that the configuration file is correct, output the current configuration to standard output, and then exit. If desired, compliance rules can be applied by specifying connection parameters using one or more of the -C options .
Specify connection parameters for use in the -T advanced test mode. If set, any Match directives in the configuration file that will apply are applied before the configuration is written to standard output. Connection parameters are provided in the form of “keyword = value” pairs and can be provided in any order, with several -C options or as a comma-separated list. The keywords are “addr”, “user”, “host”, “laddr”, “lport” and “rdomain”, and they correspond to the source address, user, resolved source hostname, local address, local port number and routing domain respectively.
Other Important SSH Command Line Options
Specifies the path to the certificate file for sshd authentication during key exchange. The certificate file must match the host key file specified with the -h option or the HostKey configuration directive.
Specifies the file from which the host key is read. This option should be specified if sshd is not run as root (since regular host key files are generally not read by anyone other than root). By default, these are /etc/ssh/ssh_host_ecdsa_key , /etc/ssh/ ssh_host_ed25519_key and /etc/ssh/ssh_host_rsa_key . You can have multiple host key files for different host key algorithms.
Add debug logs to logfile instead of syslog.
Write debug logs to standard error output instead of syslog.
It can be used to set parameters in the format used in the configuration file ( sshd_config ). This is useful for specifying options for which there is no separate command line flag. The most important configuration file directives are discussed above.
Specifies the port on which the server is listening on connections (default is 22). Multiple ports are allowed. Ports specified in the configuration file with the “ Port ” parameter are ignored if the command line port is specified. Ports specified with the ListenAddress parameter override command line ports.
Silent mode. Nothing is sent to the system log. Without this option, usually the start, authentication, and termination of each connection are logged.
Other sshd options
The most demanded options for the sshd configuration file are considered, in addition to them there are many others that configure the ciphers used, can more finely determine the authentication order and requirements for the connecting one, configure forwarding options, set the command to be executed when the user connects, display certain information when connected and so on.
You can familiarize yourself with other options of the sshd configuration file using the command:
Information about command line options can be seen with: