SSH

Table of Contents

Linux & MacOS

Footprinting SSH

SSH-Audit

reveals banner - version with a CVE

  • We may encounter various banners for the SSH server -> By default, the banners start with the version of acceptable protocol, then the version of the server itself.
  • e.g. SSH-1.99-OpenSSH_3.9p1, we know that we can use both protocol versions SSH-1 and SSH-2, and we are dealing with OpenSSH server version 3.9p1
  • e.g. SSH-2.0-OpenSSH_8.2p1, we are dealing with an OpenSSH version 8.2p1 which only accepts the SSH-2 protocol version.
> git clone https://github.com/jtesta/ssh-audit.git && cd ssh-audit
> ./ssh-audit.py 10.129.14.132

# general
(gen) banner: SSH-2.0-OpenSSH_8.2p1 Ubuntu-4ubuntu0.3
(gen) software: OpenSSH 8.2p1
(gen) compatibility: OpenSSH 7.4+, Dropbear SSH 2018.76+
(gen) compression: enabled (zlib@openssh.com)                                   

# key exchange algorithms
(kex) curve25519-sha256                     -- [info] available since OpenSSH 7.4, Dropbear SSH 2018.76                            
(kex) curve25519-sha256@libssh.org          -- [info] available since OpenSSH 6.5, Dropbear SSH 2013.62
(kex) ecdh-sha2-nistp256                    -- [fail] using weak elliptic curves
                                            `- [info] available since OpenSSH 5.7, Dropbear SSH 2013.62
(kex) ecdh-sha2-nistp384                    -- [fail] using weak elliptic curves
                                            `- [info] available since OpenSSH 5.7, Dropbear SSH 2013.62
(kex) ecdh-sha2-nistp521                    -- [fail] using weak elliptic curves
                                            `- [info] available since OpenSSH 5.7, Dropbear SSH 2013.62
(kex) diffie-hellman-group-exchange-sha256 (2048-bit) -- [info] available since OpenSSH 4.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-group14-sha256         -- [info] available since OpenSSH 7.3, Dropbear SSH 2016.73

# host-key algorithms
(key) rsa-sha2-512 (3072-bit)               -- [info] available since OpenSSH 7.2
(key) rsa-sha2-256 (3072-bit)               -- [info] available since OpenSSH 7.2
(key) ssh-rsa (3072-bit)                    -- [fail] using weak hashing algorithm
                                            `- [info] available since OpenSSH 2.5.0, Dropbear SSH 0.28
                                            `- [info] a future deprecation notice has been issued in OpenSSH 8.2: https://www.openssh.com/txt/release-8.2
(key) ecdsa-sha2-nistp256                   -- [fail] using weak elliptic curves
                                            `- [warn] using weak random number generator could reveal the key
                                            `- [info] available since OpenSSH 5.7, Dropbear SSH 2013.62
(key) ssh-ed25519                           -- [info] available since OpenSSH 6.5
...SNIP...

Changing SSH authentication methods

> ssh -v cry0l1t3@10.129.14.132 -o PreferredAuthentications=password

OpenSSH_8.2p1 Ubuntu-4ubuntu0.3, OpenSSL 1.1.1f  31 Mar 2020
debug1: Reading configuration data /etc/ssh/ssh_config
...SNIP...
debug1: Authentications that can continue: publickey,password,keyboard-interactive
debug1: Next authentication method: password

cry0l1t3@10.129.14.132's password:

SSH Keys

See Privilege Escalation chapter SSH Keys for id_rsa and keys.

Dangerous Setting

SettingDescription
PasswordAuthentication yesAllows password-based authentication.
PermitEmptyPasswords yesAllows the use of empty passwords.
PermitRootLogin yesAllows to log in as the root user.
Protocol 1Uses an outdated version of encryption.
X11Forwarding yesAllows X11 forwarding for GUI applications.
AllowTcpForwarding yesAllows forwarding of TCP ports.
PermitTunnelAllows tunneling.
DebianBanner yesDisplays a specific banner when logging in.
Password Authentication yes allows brute-force a known username
- use specific patterns are usually used to mutate the most commonly used passwords and, frighteningly, correct them
- for example, numbers or characters are added only at the end of the password. Believing that the password is secure, the mentioned patterns are used to guess precisely such "adjustments" of these passwords. However, some instructions and hardening guides can be used to harden our SSH servers.

Authentication Methods

Public Key Authentication

  1. First, SSH server and client authenticate to each other
  2. Server sends a certificate to the client to verify that it is the correct server (Only when contact is first established is there a risk of a third party interposing itself between the two participants and thus intercepting the connection)
  3. Then, client must also prove itself to the server that it has access authorization (enter password for every connection or alternatively, use public/private key pair)
  4. Using assymetric entryption, the client and the server can establish a connection. In a single session, the user only needs to enter the passphrase once to connect to any number of servers
    • Private key is created individually and secured with a long passphrase. The private key is stored exclusively on our own computer and always remains secret. To establish SSH connection, enter the passphrase and open access to the private key.
    • Public keys are also stored on the server. The server creates a cryptographic problem with the client's public key and sends it to the client. The client, in turn, decrypts the problem with its own private key, sends back the solution, and thus informs the server that it may establish a legitimate connection. At the end of the session, users log out of their local machines, ensuring that no third party who gains physical access to the local machine can connect to the server.