> For the complete documentation index, see [llms.txt](https://docs.devolutions.net/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://docs.devolutions.net/rdm/knowledge-base/knowledge-base-articles/open-ssh-security-best-practices.md). # Open SSH security best practices Although Open SSH has become the norm when it comes to remote access, using its default installation still poses a few security risks. This guide proposes ways to considerably increase the security level of an Open SSH installation. ### Use private/public keys authentication Using encrypted keys for authentication is useful as it eliminates the need to enter passwords. Even the most inventive hackers won’t be able to interfere or sneak onto a session, and no more cracking password attempts. 1. Generate a public/private keys pair using this command: `$ ssh-keygen -t rsa`. This creates two files in the (hidden) `~/.ssh` director; the private key is called `id_rsa` and the public one `id_rsa.pub`. 2. Choose a password which will be used to unlock the public key upon each connection. Optionally, an encryption protected with a passphrase can be added when creating the key.

Pressing Enter without entering a passphrase works too. Be aware, however, that creating a key without a passphrase automatically gives SSH access to the remote server to anyone gaining access to your local machine.

3. Copy the public key (`id_rsa.pub`) to the server: ```` Scp –p id_rsa.pub remoteuser@remotehost: ```
The `remoteuser` should never be root. Select the default non-root user as `remoteuser` instead.
```` 4. Log in with SSH and copy the public key to the right place: ``` ssh remoteuser@remotehost mkdir ~/.ssh chmod 700 ~/.ssh cat id_rsa.pub >> ~/.ssh/authorized_keys chmod 600 ~/.ssh/authorized_keys mv id_rsa.pub ~/.ssh logout ``` 5. Then delete the public key from the server, otherwise the SSH client does not allow logging in to the server: ``` rm id_rsa.pub ``` 6. Set file permissions on the server (these two are required if "StrictModes" is set to ***yes***): ``` $ chmod 700 ~/.ssh $ chmod 600 ~/.ssh/authorized_keys ``` 7. Once logged in using the key passphrase, password authentication can be disabled entirely. To do so, open the `/etc/ssh/sshd_config` file and add the following lines to it: ``` # Disable password authentication forcing use of keys PasswordAuthentication no ``` ### Disable username and password authentication To fully eliminate password-based authentication and force the use of SSH keys or certificates, update SSH configuration by adding the following lines in the `/etc/ssh/sshd_config` file: ``` PasswordAuthentication no ChallengeResponseAuthentication no KbdInteractiveAuthentication no UsePAM no ``` Then, restart the SSHD service by entering either `/etc/init.d/sshd restart` or `service sshd restart`. Once this is done, the server should reject all username/password logins and only accept authentication via key or certificate. ### Configure idle timeout interval An Idle timeout interval can be set to avoid having an unattended SSH session. To do so, open the `/etc/ssh/sshd_config` file and add the following line: ``` ClientAliveInterval 360 ClientAliveCountMax 0 ``` The idle timeout interval is in seconds (360 seconds = 6 minutes). Once the interval has passed, idle users are automatically logged out. ### Disable empty passwords For added security, it is recommendedto prevent remote logins from accounts with empty passwords. Open the `/etc/ssh/sshd_config` file and update the following line: ``` PermitEmptyPasswords no ``` ### Limit SSH access to a few users In cases where username/password authentication cannot be avoided, it is recommended to limit SSH login to only certain users who need remote access, thus minimizing the impact of users with weak passwords. To limit SSH login, open the `/etc/ssh/sshd_config` file and add an `AllowUsers` line, followed by the list of usernames separated with spaces: ``` AllowUsers user1 user2 ``` Then restart the SSHD service by entering either `/etc/init.d/sshd restart` or `service sshd restart`. ### Disable root login To disable root logins, open the `/etc/ssh/sshd_config` file while logging on as root and change the line `#PermitRootLogin` to `PermitRootLogin no`. Make sure to remove the # symbol, otherwise it will not work. Then restart the SSHD service by entering either `/etc/init.d/sshd restart` or `service sshd restart`. ### Disable weak cipher Open the `/etc/ssh/sshd_config` file and add in these lines: ``` # Ciphers moderns Ciphers chacha20-poly1305@openssh.com,aes256-gcm@openssh.com,aes128-gcm@openssh.com # KEX robusts KexAlgorithms curve25519-sha256,curve25519-sha256@libssh.org,ecdh-sha2-nistp256,ecdh-sha2-nistp384 # MAC moderns MACs hmac-sha2-512,hmac-sha2-256,umac-128@openssh.com # Disable weak algorithms PubkeyAcceptedKeyTypes ssh-ed25519,rsa-sha2-256,rsa-sha2-512 HostKeyAlgorithms ssh-ed25519,rsa-sha2-256,rsa-sha2-512 ``` Then restart the SSHD service by entering either `/etc/init.d/sshd restart` or `service sshd restart`. ### Use a non-standard port The vast majority of hackers looking for any open SSH servers will look for port 22, since by default, SSH listens for incoming connections on that port. To run SSH on a different port, open the `/etc/ssh/sshd_config` file and add the following lines: ``` #Run SSH on a non standard port Port 2025 #Change me ``` Then restart the SSHD service by entering either `/etc/init.d/sshd restart` or `service sshd restart`. Make sure to change the port forwarding in your router and any necessary firewall rules. It is recommended to inform clients of any port changes so they know which port to connect to since SSH will no longer be listening for connections on the standard port. ### Limit SSH exposure with network controls If changing the SSH port is not feasible, deploying a jump server provides a strong Zero-Trust control point between clients and internal systems. It centralizes authentication, enforces uniform access policies, and prevents direct exposure of critical assets. See [Remote Desktop Manager Jump (feature)](https://docs.devolutions.net/resources/devolutions-agent/jump-host/#configure-a-jump-host) for configuration steps. ### Enable multifactor authentication Multifactor authentication is one of the main protections to add to SSH servers to protect them from unauthorized access since each user login must tie back to a configured MFA user. Even if a hacker manages to get a hold of a password or breaks into the SSH server, they will still get blocked by the MFA. --- # Agent Instructions This documentation is published with GitBook. GitBook is the documentation platform designed so that both humans and AI agents can read, navigate, and reason over technical content effectively. Learn more at gitbook.com. ## Querying This Documentation If you need additional information that is not directly available in this page, you can query the documentation dynamically by asking a question. Perform an HTTP GET request on the current page URL with the `ask` query parameter: ``` GET https://docs.devolutions.net/rdm/knowledge-base/knowledge-base-articles/open-ssh-security-best-practices.md?ask= ``` The question should be specific, self-contained, and written in natural language. The response will contain a direct answer to the question and relevant excerpts and sources from the documentation. Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.