How to change SSH ciphers

Changing SSH ciphers controls which encryption algorithms protect remote logins and data in transit. Tightening the cipher list can remove outdated algorithms, align with security standards, or tune performance on busy hosts that handle many concurrent SSH sessions.

OpenSSH negotiates a cipher during the handshake based on the order defined on client and server. The server reads /etc/ssh/sshd_config, while clients use /etc/ssh/ssh_config or host-specific settings in ~/.ssh/config; the first algorithm common to both lists is used to encrypt the session.

Restricting ciphers too aggressively can lock out legacy clients or block automation that still relies on older algorithms. Configuration changes benefit from validation with sshd -t and testing from a separate session before restarting sshd so that emergency access remains available if rollback is required.

1. Open a terminal on the SSH server with access to sudo privileges.

   $ whoami
   user

   Use an existing privileged shell or a console session so configuration changes do not interrupt the only administrative connection.

2. Display the ciphers currently enabled in the effective sshd configuration.

   $ sudo sshd -T | grep -i ^ciphers
   ciphers chacha20-poly1305@openssh.com,aes256-ctr,aes192-ctr,aes128-ctr

   The sshd -T command shows the active configuration after all defaults and includes are applied, which reveals the cipher list actually in use.

3. Open the /etc/ssh/sshd_config file on the server.

   $ sudo nano /etc/ssh/sshd_config

   Any preferred text editor such as nano or vi can edit /etc/ssh/sshd_config; ensure backups exist before making large changes.

4. Add or update the Ciphers directive to define the allowed algorithms and their order.

   /etc/ssh/sshd_config
   # Explicit cipher list (strongest first)
   Ciphers chacha20-poly1305@openssh.com,aes256-ctr,aes192-ctr,aes128-ctr

   List algorithms from most to least preferred, keeping modern options such as chacha20-poly1305@openssh.com and aes256-ctr near the front while ensuring required clients support at least one entry.

5. Validate the SSH daemon configuration syntax before restarting the service.

   $ sudo sshd -t

   A syntax error in /etc/ssh/sshd_config can prevent new SSH sessions from starting, so keeping an existing root or console session open allows quick rollback.

6. Restart the SSH service to apply the cipher changes.

   $ sudo systemctl restart ssh

   On RHEL and similar systems the unit name is usually sshd, for example sudo systemctl restart sshd.

7. Check the SSH service status to confirm a clean restart.

   $ sudo systemctl status ssh
   ● ssh.service - OpenBSD Secure Shell server
        Loaded: loaded (/lib/systemd/system/ssh.service; enabled; vendor preset: enabled)
        Active: active (running) since Mon 2024-05-13 10:15:01 UTC; 5s ago
   ##### snipped #####

   An Active: active (running) line indicates that sshd accepted the configuration and is running with the updated cipher list.

1. Open or create the ~/.ssh/config file on the client system.

   $ nano ~/.ssh/config

   If the /~/.ssh directory does not exist, create it with mkdir -m 700 ~/.ssh so that only the owning user can read or write its contents.

2. Add a host entry that specifies the preferred ciphers for a particular server.

   ~/.ssh/config
   Host secure-server
     HostName server.example.com
     User alice
     Ciphers chacha20-poly1305@openssh.com,aes256-ctr,aes192-ctr,aes128-ctr

   Host-specific cipher settings avoid forcing the same list on every SSH connection and can be rolled out gradually to sensitive systems first.

3. Set strict permissions on the SSH client configuration file.

   $ chmod 600 ~/.ssh/config

   Too-permissive permissions on ~/.ssh/config can cause OpenSSH to ignore the file, which prevents the custom cipher list from taking effect.

4. List the ciphers supported by the SSH client binary.

   $ ssh -Q cipher
   3des-cbc
   aes128-ctr
   aes192-ctr
   aes256-ctr
   chacha20-poly1305@openssh.com
   ##### snipped #####

   Only algorithms appearing in this list can be negotiated, so configuring unsupported ciphers results in errors such as no matching cipher found.

5. Make a verbose test connection to confirm which cipher is negotiated.

   $ ssh -vv secure-server
   OpenSSH_9.3p1 Ubuntu-1ubuntu3, OpenSSL 3.0.2 15 Mar 2022
   ##### snipped #####
   debug1: kex: algorithm: curve25519-sha256
   ##### snipped #####
   debug1: kex: cipher: chacha20-poly1305@openssh.com
   ##### snipped #####

   The line beginning with debug1: kex: cipher shows the encryption algorithm selected by client and server during key exchange.

6. Remove or comment out the Ciphers setting if a rollback to default algorithms is required.

   When the configured cipher list has no overlap with the server configuration, SSH negotiation fails until at least one common algorithm is restored on both sides.