search

jtesta / ssh-audit

SSH server & client security auditing (banner, key exchange, encryption, mac, compression, compatibility, security, etc)
MIT License
3.23k stars 165 forks source link

rsa-sha2-512 and rsa-sha2-256 - key algorithm to append #260

Open daniejstriata opened 3 months ago

daniejstriata commented 3 months ago

I followed the guide for al2023 but still get the following recommendations:

# algorithm recommendations (for OpenSSH 8.7)
(rec) +rsa-sha2-256                         -- key algorithm to append 
(rec) +rsa-sha2-512                         -- key algorithm to append

I'm only allowing ed25519 keys to the host. . When I look at the hosts config it appears that the algorithm is in use:

→ ssh -Q PubkeyAcceptedAlgorithms | grep rsa
ssh-rsa
rsa-sha2-256
rsa-sha2-512
ssh-rsa-cert-v01@openssh.com
rsa-sha2-256-cert-v01@openssh.com
rsa-sha2-512-cert-v01@openssh.com

What am I doing wrong to add a key algorithm.

jtesta commented 3 months ago

Can you please post the full output of ssh-audit run with the -d argument?

daniejstriata commented 3 months ago 
Starting audit of 192.168.1.10:22...
Connecting to 192.168.1.10:22...
Getting banner...
KEX initialisation...
Preparing to obtain ssh-ed25519 host key...
Connecting to 192.168.1.10:22...
Getting banner...
KEX initialisation...
Parsing host key type: ssh-ed25519
ssh-ed25519 has a fixed host key modulus of 32.
Hostkey type: [ssh-ed25519]; hostkey size: 256; CA type: []; CA modulus size: 0
Preparing to perform DH group exchange using diffie-hellman-group-exchange-sha256 with min, pref and max modulus sizes of 512 bits, 1024 bits and 1536 bits...
Connecting to 192.168.1.10:22...
Getting banner...
KEX initialisation...
GEXTest._send_init(diffie-hellman-group-exchange-sha256, 512, 1024, 1536): exception when performing DH group exchange init: Expected MSG_KEXDH_GEX_REPLY (33), but got -1 instead.
Connecting to 192.168.1.10:22...
Getting banner...
KEX initialisation...
GEXTest._send_init(diffie-hellman-group-exchange-sha256, 512, 512, 512): exception when performing DH group exchange init: Expected MSG_KEXDH_GEX_REPLY (33), but got -1 instead.
Connecting to 192.168.1.10:22...
Getting banner...
KEX initialisation...
GEXTest._send_init(diffie-hellman-group-exchange-sha256, 768, 768, 768): exception when performing DH group exchange init: Expected MSG_KEXDH_GEX_REPLY (33), but got -1 instead.
Connecting to 192.168.1.10:22...
Getting banner...
KEX initialisation...
GEXTest._send_init(diffie-hellman-group-exchange-sha256, 1024, 1024, 1024): exception when performing DH group exchange init: Expected MSG_KEXDH_GEX_REPLY (33), but got -1 instead.
Connecting to 192.168.1.10:22...
Getting banner...
KEX initialisation...
GEXTest._send_init(diffie-hellman-group-exchange-sha256, 1536, 1536, 1536): exception when performing DH group exchange init: Expected MSG_KEXDH_GEX_REPLY (33), but got -1 instead.
Connecting to 192.168.1.10:22...
Getting banner...
KEX initialisation...
GEXTest._send_init(diffie-hellman-group-exchange-sha256, 2048, 2048, 2048): received modulus size: 2048
First pass found a minimum GEX modulus of 2048 against OpenSSH server.  Performing a second pass to get a more accurate result...
Connecting to 192.168.1.10:22...
Getting banner...
KEX initialisation...
GEXTest._send_init(diffie-hellman-group-exchange-sha256, 2048, 3072, 4096): received modulus size: 3072
Modulus size returned by server during second pass: 3072 bits
# general
(gen) banner: SSH-2.0-OpenSSH_8.7
(gen) software: OpenSSH 8.7
(gen) compatibility: OpenSSH 8.5+, Dropbear SSH 2018.76+
(gen) compression: enabled (zlib@openssh.com)

# security
(cve) CVE-2021-41617                        -- (CVSSv2: 7.0) privilege escalation via supplemental groups
(cve) CVE-2016-20012                        -- (CVSSv2: 5.3) enumerate usernames via challenge response

# key exchange algorithms
(kex) sntrup761x25519-sha512@openssh.com    -- [info] available since OpenSSH 8.5
(kex) curve25519-sha256                     -- [info] available since OpenSSH 7.4, Dropbear SSH 2018.76
                                            `- [info] default key exchange since OpenSSH 6.4
(kex) curve25519-sha256@libssh.org          -- [info] available since OpenSSH 6.4, Dropbear SSH 2013.62
                                            `- [info] default key exchange since OpenSSH 6.4
(kex) diffie-hellman-group16-sha512         -- [info] available since OpenSSH 7.3, Dropbear SSH 2016.73
(kex) diffie-hellman-group18-sha512         -- [info] available since OpenSSH 7.3
(kex) diffie-hellman-group-exchange-sha256 (3072-bit) -- [info] available since OpenSSH 4.4
                                                      `- [info] OpenSSH's GEX fallback mechanism was triggered during testing. Very old SSH clients will still be able to create connections using a 2048-bit modulus, though modern clients will use 3072. This can only be disabled by recompiling the code (see https://github.com/openssh/openssh-portable/blob/V_9_4/dh.c#L477).
(kex) kex-strict-s-v00@openssh.com          -- [info] pseudo-algorithm that denotes the peer supports a stricter key exchange method as a counter-measure to the Terrapin attack (CVE-2023-48795)

# host-key algorithms
(key) ssh-ed25519                           -- [info] available since OpenSSH 6.5

# encryption algorithms (ciphers)
(enc) chacha20-poly1305@openssh.com         -- [info] available since OpenSSH 6.5
                                            `- [info] default cipher since OpenSSH 6.9
(enc) aes256-gcm@openssh.com                -- [info] available since OpenSSH 6.2
(enc) aes128-gcm@openssh.com                -- [info] available since OpenSSH 6.2
(enc) aes256-ctr                            -- [info] available since OpenSSH 3.7, Dropbear SSH 0.52
(enc) aes192-ctr                            -- [info] available since OpenSSH 3.7
(enc) aes128-ctr                            -- [info] available since OpenSSH 3.7, Dropbear SSH 0.52

# message authentication code algorithms
(mac) hmac-sha2-512-etm@openssh.com         -- [info] available since OpenSSH 6.2
(mac) hmac-sha2-256-etm@openssh.com         -- [info] available since OpenSSH 6.2
(mac) umac-128-etm@openssh.com              -- [info] available since OpenSSH 6.2
(mac) hmac-sha2-512                         -- [warn] using encrypt-and-MAC mode
                                            `- [info] available since OpenSSH 5.9, Dropbear SSH 2013.56

# fingerprints
(fin) ssh-ed25519: SHA256:0AvLRIpWQr6Z6MRIpM65JTg29UitCQCJfD1BiLZIWJo

# algorithm recommendations (for OpenSSH 8.7)
(rec) +rsa-sha2-256                         -- key algorithm to append 
(rec) +rsa-sha2-512                         -- key algorithm to append 
(rec) -hmac-sha2-512                        -- mac algorithm to remove 

# additional info
(nfo) For hardening guides on common OSes, please see: <https://www.ssh-audit.com/hardening_guides.html>
(nfo) Be aware that, while this target properly supports the strict key exchange method (via the kex-strict-?-v00@openssh.com marker) needed to protect against the Terrapin vulnerability (CVE-2023-48795), all peers must also support this feature as well, otherwise the vulnerability will still be present.  The following algorithms would allow an unpatched peer to create vulnerable SSH channels with this target: chacha20-poly1305@openssh.com.  If any CBC ciphers are in this list, you may remove them while leaving the *-etm@openssh.com MACs in place; these MACs are fine while paired with non-CBC cipher types.
jtesta commented 3 months ago

host-key algorithms

(key) ssh-ed25519 -- [info] available since OpenSSH 6.5

Looks like ssh-ed25519 is the only host key being returned by your server. It may be that your RSA host keys were deleted and never re- created.

(rec) -hmac-sha2-512 -- mac algorithm to remove

It appears that you also added an HMAC that isn't in the hardening guide.

daniejstriata commented 3 months ago

Correct. I only use ed25519 keys. should the recommendations made not rely on the key types available?

I have to enable that hmac for compatibility reasons on some hosts.

jtesta commented 3 months ago

The "algorithm recommendations" section gives optional algs to add in order to maximize compatibility (aside from algs to remove because they have security concerns). Admittedly, the text should be refined so users don't think they strictly need to add more algorithms.

You may want to use the custom policy feature since you've customized your config(s). This is the exact situation custom policies were designed for, in fact.