SSH is a set of programs that allow you to log into a remote machine to execute commands on it.
277 
SSH is a protocol for securely exchanging data between two computers over an untrusted network. SSH protects the confidentiality and integrity of transmitted identities, data, and files. It works on most computers and almost every server. It comes standard on UNIX, Linux, and macOS machines and is used in more than 90% of all data centers worldwide. This is a universal solution that enables the transmission of any network protocol. A key feature is that SSH encrypts traffic, making connections secure. The SSH protocol and SSH keys secure hundreds of millions of service sessions, file transfers, and automated processes every day.
This, in turn, allows video and audio format files to be transmitted over a secure channel, compresses data for their subsequent reliable encryption and transmission. The OpenSSH server (sshd) reads the configuration file when the service starts. Any changes to the configuration file require a restart of the service. The sshd service reads the settings from the /etc/ssh/sshd_config configuration file. This file contains keyword-argument pairs, one pair per line. For each keyword, the first value received will be used (except for multiple directives that can be used multiple times, and each value will be counted, such as Port and ListenAddress). Arguments can optionally be enclosed in double quotes (“”) to pass arguments containing spaces. Keywords are case-insensitive, but arguments are case-sensitive. Many directives are commented out, but they point to a default value that is used anyway. If if you are satisfied with the default value, then you do not need to change anything. If you want a different value, you need to uncomment the line with the corresponding directive (remove the # symbol) and make changes. Additionally, you can specify command line options – they have priority over the settings in the configuration file.
If between sshd.service and sshd.socket you chose to run sshd.service, then for the changes made in the configuration file to take effect.
you need to restart the service:
For sshd.socket, restarting the service is required only when the port number is changed (as shown below), and this is done as follows:
All settings are done in the /etc/ssh/sshd_config file or on the sshd startup command line. For sshd.socket, changing the port the service is listening on is different. If you use sshd.service (explained in the first part), the port change also happens in the /etc/ssh/sshd_config file.
To do this, uncomment the Port directive and specify a new value:
The Port option can be used multiple times. You can also set the port using ListenAddress. If you are using sshd.socket and want to change the listening port for SSH, you need to edit the custom file as follows:
Only the port can be specified there: [Socket] ListenStream= ListenStream=23456
And also IP and port: [Socket] ListenStream= ListenStream=172.0.0.1:12345
Note that using ListenStream twice in the same configuration file is not an error. If you use ListenStream only once with a port specified, then both port 22 and the port you specified will be listened to. The first use of ListenStream= disables listening on port 22. For sshd.socket, other settings are, as always, in the file /etc/ssh/sshd_config. But the Port and ListenAddress directives will be ignored (if socket listening is selected).
The system can have several network interfaces with several IP addresses, by default sshd listens on all of them, including IPv6:
If you want the computer on the local network to be available only to devices on the local network, specify its local IP:
The ListenAddress directive can be used multiple times in a single configuration file. The following formats are allowed:
If no port is specified, sshd will listen on the specified port according to any set Port options in this file. The rdomain qualifier is optional, it is related to routing. Also note that the ListenAddress must be a hostname (address) OR a port. You can specify the host name (address) separately, you can specify the port separately, and you can specify them together. In all cases, rdomain may be missing. Command line options (more on their use below) take precedence over configuration file directives. Including the option to set the port in use causes the Port in the configuration file to be ignored. But the ports specified with ListenAddress overwrite the ports on the command line. You can specify a specific IP that will listen for connections. And with the AddressFamily option, you can choose to listen to all addresses, only IPv4 or only IPv6:
any (by default – any address),
inet (use only IPv4),
inet6 (use only IPv6),
If you get an error when connecting to a remote SSH system that you can’t log in as an SSH user even with the correct password:
Check the value of the directive:
By default, it is commented out, but the specified value is still used by default. The PermitRootLogin directive determines whether root can log in using ssh. 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 legacy alias without-password), password login 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 was specified with the command (this can be useful for taking 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, root access is allowed without restrictions. So, if you encounter the problem of not being able to log in with the correct password as root, then either configure login without a password – using a public key, or set the value of this directive to yes.
A little above, we considered the option when the root user is prohibited from logging in with a password. The same setting can be made for the rest of the users using the PasswordAuthentication directive. The default value is yes, which means password login is allowed. To prevent password entry for all users, set the value of this directive to no.
The PermitEmptyPasswords directive is responsible for allowing login without a password. It is needed for specific cases to allow login to accounts with an empty password string. By default, it is set to no.
There are a total of 4 directives that allow or deny users and groups to connect to SSH. These directives are in order of processing: DenyUsers, AllowUsers, DenyGroups, and finally AllowGroups. The AllowUsers keyword can be followed by a space-separated list of username patterns.
Example:
If the directive is used, only users whose names match the patterns are allowed to log in. Only usernames are accepted and digital user IDs are not recognized. By default, all users are allowed to log in. If the pattern is USER@HOST, then USER and HOST are checked separately and only specific users from specific hosts are allowed to log in. HOST can be addresses in CIDR format, i.e. in the form of addresses/mask. More on templates that can accept DenyUsers, AllowUsers, DenyGroups, and AllowGroups directives.
A pattern consists of zero or more non-whitespace characters, ‘*’ (a wildcard character that matches zero or more characters), and ‘?’ (a wildcard that matches exactly one character).
For example, to describe any host in the “.co.uk” domain set, you can use the following pattern:
The following pattern will match any host in the range 192.168.0.[0-9]:
A list of patterns is multiple patterns separated by a comma. Patterns inside the list can have the opposite meaning if they are preceded by an exclamation point (“!”).
For example, to authorize a key to be used anywhere within the organization other than the “dialup” pool, you can use the following (in authorized_keys):
A negative coincidence will never produce positive results by itself. Trying to match host “host3” – no matches:
The solution to this situation is to include a term that will result in a positive match, it can be a wildcard:
The DenyUsers, AllowUsers, DenyGroups, and AllowGroups directives (listed in order of processing) and templates can be used to configure permissions for SSH access via IP. Let’s consider several examples. If the sshd_config file adds filtering with AllowUsers:
Access for johndoe and admin2 is only from the addresses 192.168.1.*, and for otherid1, otherid2 access will be open from any address:
To allow SSH access to any user, but only from specific IPs, use the wildcard AllowUsers directive in the /etc/ssh/sshd_config file:
It is possible to restrict an ssh or ca-based key to a set of addresses in the .ssh/authorized_keys file of the user’s home directory.
In this example, the public key for users will be valid only from the specified addresses:
The SSH service does not keep its own log and records events in the system log. You can configure the details of logging — the level of verbosity, that is, which messages will be written to this log. The LogLevel directive is used for this. Its default value is INFO.
QUIET
FATAL
ERROR
INFO
VERBOSE
DEBUG
DEBUG1
DEBUG2
DEBUG3
DEBUG and DEBUG1 are equivalent. DEBUG2 and DEBUG3 each indicate higher levels of debug output. DEBUG logging violates the user privacy policy and is not recommended.
Starting the sshd service is described in the 1st part. Also, sshd can be run on a filename, specify the full path to the sshd file to find it:
Launched in this way, sshd will disconnect from the terminal (go into background execution) and will not output anything to standard output. It is possible to run sshd as a process without disconnecting from the terminal (so that the process does not become a daemon), for this use the -D option – this allows you to simplify the process of monitoring the operation of SSH, since messages about events and service problems will be output to standard output.
Additionally, you can specify the -d option to enable debug mode:
-e – Write debug logs to standard error output instead of the syslog.
-t – Test mode. Only checks the correctness of the configuration file and the functionality of the keys. This is useful for reliably updating sshd, as configuration options can be changed.
-T – Advanced test mode. With this option, sshd will verify that the configuration file is correct, output the current configuration to stdout, and then exit.
-f – This option can be used to specify the path to another configuration file (default /etc/ssh/sshd_config). sshd will refuse to start without a configuration file.
-C – If set, any Match directives in the configuration file that will be applied are applied to the configuration entry to stdout.
-q – Quiet mode. Nothing goes to the syslog. Without this option, the initiation, authentication, and termination of each connection are usually logged.
-E log_file – Add debug logs to log_file instead of syslog.
-c host_certificate_file – Specifies the path to the certificate file to identify sshd during key exchange. The certificate file must match the host key file specified with -h or the HostKey configuration directive.
-h host_key_file – Specifies the file from which the host key is read. This option must be specified if sshd is not running as root (since normal host key files are usually unreadable by anyone but root). The defaults are /etc/ssh/ssh_host_ecdsa_key, /etc/ssh/ssh_host_ed25519_key, and /etc/ssh/ssh_host_rsa_key.
-p port – Specifies the port on which the server listens for connections (default is 22). Multiple ports are allowed. Ports specified in the configuration file with the “Port” parameter are ignored if a command line port is specified. Ports specified with ListenAddress override command line ports.
-o option – Can be used to set parameters in the format used in the configuration file (sshd_config). This is useful for specifying parameters for which there is no separate command line flag. The most important configuration file directives are discussed above.
Considered the most popular options of the sshd configuration file, in addition to them there are many others that configure the ciphers used, can more finely define the authentication procedure and requirements for connecting, configure forwarding capabilities, set the command that is executed when the user connects, display certain information when connections and so on.
You can familiarize yourself with other options of the sshd configuration file (in English) using the command:
Information about command line options can be seen using:
277 
328 
390 
375 
315