72

Security team of my organization told us to disable the following weak ciphers due to they issue weak keys:

  • arcfour
  • arcfour128
  • arcfour256

But I tried looking for these ciphers in ssh_config and sshd_config file and found them commented.

$ grep arcfour *
ssh_config:#   Ciphers aes128-ctr,aes192-ctr,aes256-ctr,arcfour256,arcfour128,aes128-cbc,3des-cbc

Where else I should check to disable these ciphers from SSH?

Improve this question
4
  • 2
    for SSH server it will be in /etc/ssh/sshd_config and for the SSH client it will be in /etc/ssh/ssh_config. You want to look for the Cipher line in each, and for example have just Cipher aes256-ctr specified. Then restart SSH via /etc/init.d/sshd restart or via the equivalent systemd command. Commented Dec 5, 2018 at 18:58
  • 1
    you want to become knowledgeable about all the parameters in sshd_config if you really care about SSH security, otherwise it can be all security theater. Commented Dec 5, 2018 at 19:09
  • @ron the second comment is an intriguing one, can you illustrate with an example what you intend? Commented Dec 12, 2018 at 12:26
  • 1
    the ciphers list is just one setting out of many for having SSH properly implemented... Protocol, PermitRootLogin, AuthorizedKeysFile, PermitEmptyPasswords, IgnoreRhosts, PermitTunnel, and so on. You can rely on their default settings as implemented in your linux distribution, but Ignornance is bliss only up until you have a problem Commented Dec 12, 2018 at 16:29

6 Answers 6

Reset to default
61

If you have no explicit list of ciphers set in ssh_config using the Ciphers keyword, then the default value, according to man 5 ssh_config (client-side) and man 5 sshd_config (server-side), is:

aes128-ctr,aes192-ctr,aes256-ctr,arcfour256,arcfour128,
[email protected],[email protected],
[email protected],
aes128-cbc,3des-cbc,blowfish-cbc,cast128-cbc,aes192-cbc,
aes256-cbc,arcfour

Note the presence of the arcfour ciphers. So you may have to explicitly set a more restrictive value for Ciphers.

ssh -Q cipher from the client will tell you which schemes your client can support. Note that this list is not affected by the list of ciphers specified in ssh_config. Removing a cipher from ssh_config will not remove it from the output of ssh -Q cipher. Furthermore, using ssh with the -c option to explicitly specify a cipher will override the restricted list of ciphers that you set in ssh_config and possibly allow you to use a weak cipher. This is a feature that allows you to use your ssh client to communicate with obsolete SSH servers that do not support the newer stronger ciphers.

nmap --script ssh2-enum-algos -sV -p <port> <host> will tell you which schemes your server supports.

Improve this answer
6
  • Hi , I mentioned specific ciphers in ssh_config and restarted ssh service but when I did ssh -Q cipher <hostname> I am still getting all ciphers that I am getting earlier irrespective of my configuration. Commented Dec 30, 2016 at 10:30
  • 2
    I'm sorry, ssh_config is the client-side config, the server-side config is sshd_config, please try that. (It's also called Ciphers there.) Commented Dec 30, 2016 at 10:42
  • Yeah I know but when I grep for ciphers I found them at ssh_config so I did changes there. As production server I am not doing anything I am not sure Commented Dec 30, 2016 at 10:46
  • Note that the defaults may differ between distributions. Commented Dec 30, 2016 at 13:33
  • Seems there is no ssh -Q on older versions. (e.g. CentOS 6's openssh v5.3p1) Commented Nov 27, 2018 at 2:58
49

To disable RC4 and use secure ciphers on SSH server, hard-code the following in /etc/ssh/sshd_config

ciphers [email protected],[email protected],[email protected],aes256-ctr,aes192-ctr,aes128-ctr

OR if you prefer not to dictate ciphers but merely want to strip out insecure ciphers, run this on the command line instead (in sudo mode):

sshd -T | grep ciphers | sed -e "s/\(3des-cbc\|aes128-cbc\|aes192-cbc\|aes256-cbc\|arcfour\|arcfour128\|arcfour256\|blowfish-cbc\|cast128-cbc\|[email protected]\)\,\?//g" >> /etc/ssh/sshd_config

You can check ciphers currently used by your server with:

sudo sshd -T | grep ciphers | perl -pe 's/,/\n/g' | sort -u

Make sure your ssh client can use these ciphers, run 

ssh -Q cipher | sort -u

to see the list.

You can also instruct your SSH client to negotiate only secure ciphers with remote servers. In /etc/ssh/ssh_config set:

Host *
    ciphers [email protected],[email protected],[email protected],aes256-ctr,aes192-ctr,aes128-ctr

Above snippets come from here
To test your server's settings you can use ssh-audit

Improve this answer
3
  • I had to use sshd -T -C user=root instead of just sshd -T, also cut out the initial word with sudo sshd -T -C user=root | grep ciphers |cut -d " " -f2- | perl -pe 's/,/\n/g' | sort -u Commented May 8, 2020 at 23:05
  • onleine to check if all ciphers are in your system: for i in $(sudo sshd -T -C user=root | grep ciphers |cut -d " " -f2- | perl -pe 's/,/ /g'); do echo '##'check $i; ssh -Q cipher | grep $i; done Commented May 8, 2020 at 23:12
  • Newer ssh-audit: github.com/jtesta/ssh-audit Commented Mar 29, 2023 at 14:13
38

The problem with explicitly specifying a cipher list is that you must manually add new ciphers as they come out. Instead, simply list the ciphers you want to remove, prepending the list (not each individual cipher) with a '-' character. So in this case, the Ciphers line should read:

Ciphers -arcfour*

Or if you prefer:

Ciphers -arcfour,arcfour128,arcfour256

From the sshd_config man page on the Ciphers option (since OpenSSH 7.5, released 2017-03-20):

If the specified value begins with a ‘+’ character, then the specified ciphers will be appended to the default set instead of replacing them. If the specified value begins with a ‘-’ character, then the specified ciphers (including wildcards) will be removed from the default set instead of replacing them.

This also applies to the KexAlgorithms and MACs options.

Improve this answer
2
  • 1
    /etc/ssh/ssh_config line 60: Bad SSH2 cipher spec '-arcfour,arcfour128,arcfour256'. Getting this error what may be the reason Commented Jun 8, 2021 at 13:20
  • 3
    Although I would love having this feature, I believe the - prefix is not supported anymore and that's the reason of the error @AbhinavKinagi is getting. In fact, check: bash man sshd_config and you'll see: Specifies the ciphers allowed. Multiple ciphers must be comma-separated. If the specified value begins with a ‘+’ character, then the specified ciphers will be appended to the default set instead of replacing them. Commented Oct 8, 2021 at 9:53
6

How to disable a weak ssh cipher,100% working tested on Fedora 29. The problem: Nessus report my samba4 server use not strong ciphers aes256-cbc and aes128-cbc. So I put those lines in /etc/ssh/sshd_config

MACs hmac-sha2-512,hmac-sha2-256
Ciphers aes256-ctr,aes192-ctr,aes128-ctr
KexAlgorithms diffie-hellman-group14-sha256,diffie-hellman-group16-sha512,diffie-hellman-group18-sha512,diffie-hellman-group-exchange-sha256,ecdh-sha2-nistp256,ecdh-sha2-nistp384,ecdh-sha2-nistp521,curve25519-sha256,[email protected]

Et voilà!..it still use the cbc cipher because this command work :(

ssh -c aes256-cbc samba4

So I check the useful systemd and I discover sshd service is using another file for ciphers

/etc/crypto-policies/back-ends/opensshserver.config

Backup the file for safety

cp /etc/crypto-policies/back-ends/opensshserver.config     /etc/crypto-policies/back-ends/opensshserver.config.old

Edit it,and remove the cbc cipher. Restart the service

systemctl restart sshd

And finally test,works fine..cbc disabled.

ssh -c aes256-cbc samba4
Unable to negotiate with 192.168.0.48 port 22: no matching cipher found. Their offer: [email protected],[email protected],aes256-ctr,[email protected],aes128-ctr
Improve this answer
1
  • 1
    rpm -qf /etc/crypto-policies/back-ends/opensshserver.config shows that it belongs to package crypto-policies and you should not modify package owned files. Better create a pmod: echo "cipher = -*CBC" >/etc/crypto-policies/policies/modules/NO-CBC.pmod. Then run update-crypto-policies --set DEFAULT:NO-CBC and restart services or reboot. Commented May 30 at 19:51
4

enable/disable cipher need to add/remove it in file /etc/ssh/sshd_config After edit this file the service must be reloaded

systemctl reload sshd
/etc/init.d/sshd reload

Then,running this command from the client will tell you which schemes support

ssh -Q cipher

To check if arcfour cipher is enabled or not on the server run this command

ssh localhost -c arcfour

To check if arcfour128 cipher is enabled or not on the server,run this command

ssh localhost -c arcfour128
Improve this answer
1
  • This step was missing in above answers Commented Jun 25, 2019 at 12:14
0

SSH: How to disable weak ciphers?

Asked 4 years ago

What you ask is found in /etc/ssh/sshd_config.

The file below is that, taken from RHEL 7.9 and configured to STIG, as of this date their latest version is 2.8. They have called out weak ssh ciphers and request they not be used... as such you are left with what is specified for Ciphers and MACs.

Per a web search: problem with cbc cipher

The problem with CBC mode is that the decryption of blocks is dependant on the previous ciphertext block. This means attackers can manipulate the decryption of a block by tampering with the previous block using the commutative property of XOR.Oct 16, 2019. CBC Mode is Malleable. Don't trust it for Authentication ...

All that sort of stuff is over my head so I can't vouch for how accurate or within context it all is all I know is they say it's bad.

Therefore the aes###-cbc ciphers are removed and only the aes###-ctr ciphers are used. To completely answer your question, use only aes256-ctr and hmac-sha2-512 as anything else would be weaker.

#  This is from RHEL 7.9 x86-64
#
#  $OpenBSD: sshd_config,v 1.100 2016/08/15 12:32:04 naddy Exp $
#  If you want to change the port on a SELinux system
#  semanage port -a -t ssh_port_t -p tcp #PORTNUMBER
#


PermitEmptyPasswords                       no

PermitUserEnvironment                      no

HostbasedAuthentication                    no

Ciphers                                    aes128-ctr,aes192-ctr,aes256-ctr

ClientAliveInterval                        0

#   ** depercated **
RhostsRSAAuthentication                    no

ClientAliveCountMax                        3

IgnoreRhosts                               yes

PrintLastLog                               yes

PermitRootLogin                            no

IgnoreUserKnownHosts                       yes

Protocol                                   2

MACs                                       hmac-sha2-256,hmac-sha2-512

GSSAPIAuthentication                       no

KerberosAuthentication                     no

StrictModes                                yes

UsePrivilegeSeparation                     sandbox

Compression                                no

X11Forwarding                              yes

Port                                       22
banner                                     /etc/issue
UsePAM                                     yes
LoginGraceTime                             2m
MaxAuthTries                               6
MaxSessions                                10
TCPKeepAlive                               yes
UseLogin                                   no
AddressFamily                              any
SyslogFacility                             AUTHPRIV
PubkeyAuthentication                       yes
SyslogFacility                             AUTH
LogLevel                                   INFO
PrintMotd                                  yes
PermitTunnel                               no
ShowPatchLevel                             no
UseDNS                                     yes

#ListenAddress                             0.0.0.0
#ListenAddress                             ::
#RekeyLimit default none

PasswordAuthentication                     yes
ChallengeResponseAuthentication            no

KerberosOrLocalPasswd                      yes
KerberosTicketCleanup                      yes
KerberosGetAFSToken                        no
KerberosUseKuserok                         yes

GSSAPICleanupCredentials                   no
GSSAPIStrictAcceptorCheck                  yes
GSSAPIKeyExchange                          no
GSSAPIEnablek5users                        no

AllowAgentForwarding                       yes
AllowTcpForwarding                         yes
GatewayPorts                               no

X11DisplayOffset                           10
X11UseLocalhost                            yes
PermitTTY                                  yes

PidFile                                    /var/run/sshd.pid
MaxStartups                                10:30:100
ChrootDirectory                            none
VersionAddendum                            none

HostKey /etc/ssh/ssh_host_rsa_key
#HostKey /etc/ssh/ssh_host_dsa_key
HostKey /etc/ssh/ssh_host_ecdsa_key
HostKey /etc/ssh/ssh_host_ed25519_key


# The default is to check both .ssh/authorized_keys and .ssh/authorized_keys2
# but this is overridden so installations will only check .ssh/authorized_keys

AuthorizedKeysFile  .ssh/authorized_keys

#AuthorizedPrincipalsFile none

#AuthorizedKeysCommand none
#AuthorizedKeysCommandUser nobody

# Accept locale-related environment variables
AcceptEnv LANG LC_CTYPE LC_NUMERIC LC_TIME LC_COLLATE LC_MONETARY LC_MESSAGES
AcceptEnv LC_PAPER LC_NAME LC_ADDRESS LC_TELEPHONE LC_MEASUREMENT
AcceptEnv LC_IDENTIFICATION LC_ALL LANGUAGE
AcceptEnv XMODIFIERS

# override default of no subsystems
Subsystem   sftp    /usr/libexec/openssh/sftp-server

# Example of overriding settings on a per-user basis
#Match User anoncvs
#   X11Forwarding no
#   AllowTcpForwarding no
#   PermitTTY no
#   ForceCommand cvs server
Improve this answer
1
  • SSH always uses a MAC (standardly HMAC, OpenSSH also UMAC) with ciphers that don't do their own authentication (standardly AES-GCM, OpenSSH also ChaCha+Poly), so malleability isn't a problem, but if it were, CTR is just as badly (though somewhat differently) malleable than CBC Commented Jan 19, 2021 at 6:27

You must log in to answer this question.

Start asking to get answers

Find the answer to your question by asking.

Ask question

Explore related questions

See similar questions with these tags.