Jump to:navigation, search


Last adaptation to the version: 12.1


  • Article adaptation
  • Translation

Previous versions: 11.7


SSH access to the UTM can be hardened in three fixed security levels and one user-defined security level.
Menu → Authentication →SSH Settings


╭╴ Settings ╶╮
caption: value: Description:
Security levels: Medium Default settings of the UTM, root login is possible if a corresponding user has been created. UTM v12.1 Authentifizierung SSH Einstellungen-en.png
High Longer host keys, no potentially insecure hash algorithms, no root login even if a corresponding user has been created.
Very high Extremely limited list of hash algorithms, ciphers and key exchange algorithms, no root login even if a corresponding user has been created.
Custom The user defines his list of hash algorithms, ciphers and key exchange algorithms, root login activatable
Allow pending connections: 10Link= The number of simultaneously established connections that have not yet been authenticated.
Initial drop chance: 30Link= Percentage of connections that are discarded over the allowed unauthenticated ones.
Maximum pending connections: 100Link= Set of simultaneous connections above which all unauthenticated connections are discarded.
Login grace time: 120Link= Time in seconds available for authentication

Custom security settings

╭╴ Custom security settings ╶╮
HMAC list: Medium
List of approved Keyed-Hash Message Authentication Code hash algorithms. UTM v12.1 Authentifizierung SSH Einstellungen Erweitert-en.png
Very high
Cipher-Suite: Medium
Defines which encryptions are permitted for SSH.
Very high
KEX algorithm: Medium
KEX algorithm:
Very high
Allow root access On Only possible with Medium or Custom

Root access

Root with user authentication

There is no root access via user authentication in the high and very high mode. Here, only authentication via Public Key is possible.

If, nevertheless, root access with user authentication in the security levels high and very high is desired, the lists from these modes can be copied into the User Defined mode and root activated.

Root access via public key

The following steps are necessary to carry out authentication without a password via an SSH console using ssh-public-key:

Step Description:
Creating an SSH-RSA Key Pair This can be generated on a Windows system with an additional programme such as "puttygen". Putty KG NewKey.png
Generate Key Pair
On a Linux/Unix system, the tool "ssh-keygen" is available, which is executed with the option ssh-keygen -t rsa .
Location of the key The public part of the key can be saved after creation with "puttygen" with Save public key and Save private key , by default in the document directory of the Windows user.
For Linux/Unix, these are located in the user directory under /home/user/.ssh/
Format public key The Puttygen file must still be adapted in this regard:

The public-key must have the following format:

ssh-rsa <public-key>.

Since there is a space between "ssh-rsa" and the key, the entire content must be enclosed in inverted commas. Furthermore, care must be taken that the line breaks of the public key are removed.

In addition, the optional entry of the user should also be added in the form "User@Computer". It should look like this:

"ssh-rsa AAAAB3NzaC1....93stGrJPeQ= a.admin@ttt-point.de"
This is already set up in the Linux file "id_rsa.pub".
Transfer the public key to the UTM Now this key is copied and added via an SSH console with the following CLI command:
system ssh pubkey new key "ssh-rsa AAAAB3NzaC1....93stGrJPeQ= 
Activate RSA key on the UTM To use the RSA key, it is enabled with the following CLI command:

system ssh pubkey enable id 1 The ID of this key can be queried with the command system ssh pubkey get .

Activate authentication via public key To be able to authenticate via an SSH console using a public key, this must be activated. The corresponding CLI command on the UTM is: extc global set variable "GLOB_SSH_PUBKEY_AUTH" value 1

Finally, the UTM system is updated with the CLI command system update system.

Integrate private key Under Putty, the file with the private key must now be added in the menu CategoryConnectionSSHAuth and in the field Host Name, the user is transferred in the format root@<IP address>. Putty Keyfile.png
Adding a Private Key to a Putty Profile

Putty root login.png
Putty profile
No SSH session can be opened with Putty in "high" and "very high" mode. The key exchange algorithms required there are not supported by Putty.
With the SSH client under Linux, the command ssh root@<IP address> is sufficient, as the key is stored at a defined location in the system.


The settings made in the web interface are visible on the CLI via the following commands.

extc value get application "sshd"

The result should look similar to the following:

application|variable                |value
sshd       |CIPHER_LIST             |
           |CIPHER_LIST_H           |chacha20-poly1305@openssh.com,aes256-gcm@openssh.com,aes128-gcm@openssh.com,aes256-ctr,aes192-ctr,aes128-ctr
           |CIPHER_LIST_M           |aes128-ctr,aes192-ctr,aes256-ctr,arcfour256,arcfour128,aes128-gcm@openssh.com,aes256-gcm@openssh.com,aes128-cbc,3des-cbc,blowfish-cbc,cast128-cbc,aes192-cbc,aes256-cbc,arcfour,rijndael-cbc@lysator.liu.se
           |CIPHER_LIST_P           |chacha20-poly1305@openssh.com
           |HMAC_LIST               |
           |HMAC_LIST_H             |hmac-sha2-512-etm@openssh.com,hmac-sha2-256-etm@openssh.com,hmac-ripemd160-etm@openssh.com,umac-128-etm@openssh.com,hmac-sha2-512,hmac-sha2-256,hmac-ripemd160,umac-128@openssh.com
           |HMAC_LIST_M             |hmac-md5-etm@openssh.com,hmac-sha1-etm@openssh.com,umac-64-etm@openssh.com,umac-128-etm@openssh.com,hmac-sha2-256-etm@openssh.com,hmac-sha2-512-etm@openssh.com,hmac-ripemd160-etm@openssh.com,hmac-sha1-96-etm@openssh.com,hmac-md5-96-etm@openssh.com,hmac-md5,hmac-sha1,umac-64@openssh.com,umac-128@openssh.com,hmac-sha2-256,hmac-sha2-512,hmac-ripemd160,hmac-ripemd160@openssh.com,hmac-sha1-96,hmac-md5-96
           |HMAC_LIST_P             |hmac-sha2-256-etm@openssh.com
           |KEX_LIST                |
           |KEX_LIST_H              |curve25519-sha256@libssh.org,diffie-hellman-group-exchange-sha256
           |KEX_LIST_M              |ecdh-sha2-nistp256,ecdh-sha2-nistp384,ecdh-sha2-nistp521,diffie-hellman-group-exchange-sha256,diffie-hellman-group-exchange-sha1,diffie-hellman-group14-sha1,diffie-hellman-group1-sha1
           |KEX_LIST_P              |curve25519-sha256@libssh.org
           |LOGIN_GRACE_TIME        |10
           |PERMIT_ROOT_LOGIN       |no
           |PERMIT_ROOT_LOGIN_H     |no
           |PERMIT_ROOT_LOGIN_M     |yes
           |PERMIT_ROOT_LOGIN_P     |no
           |RATE_MAX_PENDING_CONNS  |100
           |RATE_START_DROP_CHANCE  |30
           |SECMODE                 |2 
           |USE_HOSTKEY_DSA         |0
           |USE_HOSTKEY_EC25519     |1
           |USE_HOSTKEY_ECDSA       |1
           |USE_HOSTKEY_RSA         |1
           |USE_OTP                 |0

The variable SECMODE indicates which SSH configuration is currently active.

There are four configurations that can be assigned to this variable:

value Meaning
0 Very high
1 High
2 Medium
3 Custom

If the variable is assigned to a different configuration in the CLI, then this instruction must be activated by restarting the SSHD application.

extc value set application "sshd" variable SECMODE value 1
appmgmt restart application "sshd"

Note: Safety precautions during configuration tests

If it is planned to manipulate new encryptions or the SSH settings via the web interface or the CLI, an SSH connection to the UTM should be established before the changeover. Existing SSH connections are not interrupted by changing the encryption or SSH settings.