The popular and simple telnet, which did not provide a secure connection, was replaced by the well-known SSH protocol. It allowed to organise tunnels, manage devices, through secure sessions. Its ability to integrate with PAM allowed to modify the process of authentication, account accounting and session management. For example, adding a 2-factor or limiting resources to specific user shells.
But, by default, the server out of the box may be under-configured for your infrastructure, its security requirements, or functionality. In this article, we will take a detailed look at what each directive in the SSH configuration file represents and how to use them.
SSH configuration
Let us remind you that SSH or Secure Shell is a protocol for remote control and data transfer. A server and a client are usually installed on the machine to organise all work over a secure connection. Whether it is the windows version of ssh or ssh linux. To configure the server, let's go to the configuration file:
C:\ProgramData\SSH\sshd_configConfig ssh for ubuntu and Linux-like systems:
sudo nano /etc/ssh/sshd_config
This is the one that is loaded by the service that handles user connections on the system's network socket. The main thing is not to confuse it with a similar config, which is stored in the same directory and is responsible for the client software.
After the file has been opened, note that we can specify additional settings in the sshd_config.d directory, which will be prioritised over the general ones we are editing now. This approach will allow us to divide the config by tasks and disable innovations in case of unstable operation by commenting lines or deleting the file.
Let's go through the standard set of options that every server has by default, ssh config file: configuring ports, addresses, keys, authentication policy, etc. To overwrite the default setting, remove the # sign before the beginning of the directive. Each of these will prevent a potential attack on the service or extend the functionality of the service. After open file you will ssh config file example, that you need to modify.
Port
Port 1024 The Port directive is responsible for the port on which the server will accept connections, for security reasons, especially if the server is open to the Internet, you should change it to anything from 1024 to 49151.
AddressFamily
AddressFamily inet This option allows you to select the family of network addresses available for connection to the server: IPv4 and/or IPv6. If your infrastructure does not use IPv6, it is strongly recommended that you disable it, as attacks related to IPv6 are still a pressing problem, as IPv6 is prioritised over IPv4 in configuration:
- inet - for IPv4;
- inet6 for IPv6;
- any - for any family.
ListenAddress
ListenAddress 0.0.0.0 Accordingly ListenAddress specifies which address to listen to, to configure SSH to internal network users, use the address of the interface that looks inward. You can use the ip a command for this. Or leave it available on all interfaces with a default value of 0.0.0.0.0 for all users on the network. Remove the line with the IPv6 address :: .
HostKey
HostKey /etc/ssh/ssh_host_rsa_key
HostKey /etc/ssh/ssh_host_ecdsa_key
HostKey /etc/ssh/ssh_host_ed25519_key If you want to set your own keys for your server, change the HostKey strings that define the path to them. You can regenerate them with the ssh-keygen command, where you need to specify the encryption algorithm on the basis of which they will work.
Ciphers and keying
Ciphers aes256-ctr,aes192-ctr,aes128-ctr,aes256-gcm@openssh.com,aes128-gcm@openssh.com
MACs hmac-sha2-256,hmac-sha2-512,hmac-sha1
KexAlgorithms curve25519-sha256,ecdh-sha2-nistp256,ecdh-sha2-nistp384,ecdh-sha2-nistp521,diffie-hellman-group-exchange-sha256,diffie-hellman-group14-sha256Attacks can occur not only on the server application itself, but also on the protocols it uses. For this purpose, attackers often resort to analysing protocol traffic from their interfaces, where a single query is enough to reveal vulnerable server algorithms:
SSH has three types of algorithms to provide security: key exchange, encryption, and message integrity. But some of them are already vulnerable, but they are still used in servers by default. In order to disable them, it is necessary to prescribe only those that will be safe to use.
Authentification
LoginGraceTime 2m
PermitRootLogin no
StrictModes yes
MaxAuthTries 6
MaxSessions 8
PasswordAuthentication yes
PubkeyAuthentication yes
AuthenticationMethods publickey,password
UsePAM yesAuthentication is an integral process in many services, so it is necessary to understand how SSH does it. It requests passwords that are familiar to everyone through PAM library modules, where you can connect other authentication providers by specifying the UsePAM yes directive. But the server-SSH performs authentication via keys by itself.
The parameter LoginGraceTime 2m means that the user has only 120 seconds to start authenticating. Otherwise the session will be closed, to avoid resource exhaustion, in case of DoS and DDoS. Prohibiting PermitRootLogin no by root will avoid key and password brute force issues, for a user with super privileges. MaxAuthTries 6 will set the maximum number of login attempts, after which it will close the session. Connecting via ssh:
Set the following settings according to your infrastructure requirements. MaxSessions 8 will set the maximum number of concurrent sessions. PasswordAuthentication yes will allow password authentication. PubkeyAuthentication yes will similarly allow asymmetric encryption keys. AuthenticationMethods publickey,password will specify the combination that will eventually be used when authenticating users.
KerberosAuthentication no
KerberosOrLocalPasswd yes
KerberosTicketCleanup yes
KerberosGetAFSToken noIf desired, you can also enable Kerberos authentication.
Optional settings
AllowAgentForwarding yes
AllowTcpForwarding no
GatewayPorts no
X11Forwarding yes
X11DisplayOffset 10
X11UseLocalhost yes
PermitTTY yes
PrintMotd no
PrintLastLog yes
PermitUserEnvironment noThe AllowAgentForwarding directive is used to avoid entering passwords multiple times, ssh agent allows us to send signed packets with a private key instead of an ssh file. If we have already connected to a server and want to get to a third server through it, for example, due to network unavailability. This is relevant when you have a master password on your authentication keys to keep them out of the public domain.
- AllowTcpForwarding no will allow creating tunnels between machines via SSH protocol. This solution is often used by intruders to hide real traffic in tunnels that are encrypted and allowed to work within the infrastructure. If you have no requirements in your work to use tunnels of this protocol, it is better to disable it;
- GatewayPorts no will prevent ssh ports on the machine from being forwarded from public or internal addresses other than localhost;
- X11Forwarding yes will allow redirection of windows interface system traffic within the SSH tunnel;
- PermitTTY yes will allow interactive interaction with the shell, not just executing a single command and closing the server;
- PrintMotd no or ‘Message of the Day’ to disallow text string output during user authentication, to avoid problems during data validation;
- PrintLastLog yes directive says that it will write logs about connections and security events to /var/log/auth.log;
- PermitUserEnvironment no will prevent the user from saving environment variables that could potentially be infected.
The resulting file will be a collection of these lines, which you will need to save and reload the SSH service:
sudo systemctl restart If you don't have sufficient resources than you can perform actions on powerful cloud servers. Serverspace provides isolated VPS / VDS servers for common and virtualize usage.
