SSH

Secure Shell (SSH) sustituyó gran parte del acceso remoto que confiaba en la red o enviaba credenciales y comandos sin protección. Su protocolo establece primero la identidad criptográfica del servidor y los algoritmos del canal. Después autentica al usuario y abre uno o más canales lógicos para shell, comandos, transferencias o forwarding.

Esa secuencia divide la enumeración en dos mundos. Antes del login se observan banner, host keys, intercambio de claves, cifrados y métodos ofrecidos. Después del login importan el token, la shell, los subsystems, las restricciones de authorized_keys y los forwards permitidos. Una buena política criptográfica no describe los permisos de la cuenta, y una credencial válida no garantiza una shell interactiva.

Los ejemplos usan TARGET_IP, FQDN, PORT, USERNAME, CLIENT_IP y KEY_FILE como placeholders.

Nmap obtiene banner, algoritmos y host keys. Ncat confirma la línea de identificación del servidor. El cliente ssh -vv muestra la negociación y los métodos que el servidor permite para una identidad. ssh-keyscan recoge claves sin demostrar su autenticidad. ssh-audit compara algoritmos y claves con su base de conocimiento, pero sus etiquetas deben contrastarse con la versión y política evaluadas.

La interacción manual cubre Ncat y la conservación del banner. No envíes credenciales mediante una tubería de texto: SSH negocia un protocolo binario después de las líneas de identificación.

SSH suele escuchar en 22/tcp. Tras establecer TCP, cliente y servidor intercambian líneas de identificación como SSH-2.0-OpenSSH_9.x. El prefijo confirma la versión de protocolo. El sufijo es un banner de software y puede estar modificado.

OpenSSH actual implementa SSH 2. SSH 1 fue retirado del proyecto, de modo que referencias antiguas a elegir Protocol 1 ya no describen una instalación moderna.

Nmap -sV reconoce el servicio. ssh2-enum-algos enumera algoritmos ofrecidos y ssh-hostkey obtiene host keys públicas:

nmap -sV -p 22 --script ssh2-enum-algos,ssh-hostkey TARGET_IP

Los algoritmos ofrecidos se negocian con las capacidades y preferencias del cliente. Una opción presente no es necesariamente la elegida. Las huellas de las host keys permiten correlacionar servicios y detectar cambios, aunque varios hosts clonados pueden compartirlas por una provisión defectuosa.

ssh -v activa el diagnóstico. -p fija el puerto y -o PreferredAuthentications=none solicita no usar un método de autenticación. Así se puede observar qué ofrece el servidor sin probar secretos:

ssh -v -p 22 \
  -o PreferredAuthentications=none \
  USERNAME@TARGET_IP

El debug muestra KEX, host key, cipher, MAC y métodos restantes. Permission denied (publickey,password) enumera métodos aceptables en ese punto, no cuentas válidas. PAM, AuthenticationMethods, bloques Match y políticas por origen pueden cambiar la secuencia.

La forma mínima es ssh USERNAME@FQDN. -p PORT cambia el puerto de destino. Si el servidor admite contraseña, el cliente la solicita sin incluirla en el argumento:

ssh -p PORT USERNAME@FQDN

Un cliente que ya tiene claves puede probarlas antes de solicitar la contraseña. Para aislar ese método, PreferredAuthentications=password lo sitúa como única preferencia y PubkeyAuthentication=no desactiva el intento con public key:

ssh -p PORT \
  -o PreferredAuthentications=password \
  -o PubkeyAuthentication=no \
  USERNAME@FQDN

Esto genera un intento de autenticación por contraseña. Un fallo puede significar secreto incorrecto, cuenta inválida, política PAM, restricción por origen o que el método se anuncie pero no sea válido para ese usuario.

Para conectar con una private key, -i selecciona el archivo. OpenSSH rechaza claves privadas accesibles por otros usuarios, por lo que chmod 600 limita lectura y escritura al propietario:

chmod 600 KEY_FILE
ssh -i KEY_FILE USERNAME@TARGET_IP

La aceptación depende de la public key autorizada, la cuenta, los permisos de ~/.ssh, las restricciones incluidas en authorized_keys y la configuración del daemon. Una clave válida puede quedar limitada a un comando, un origen o un tipo de forwarding.

Al conectar por primera vez, el cliente presenta la fingerprint del host. Aceptarla sin contrastarla crea una relación de confianza local en known_hosts. Registra el algoritmo y la fingerprint exacta para distinguir una rotación legítima de una identidad inesperada.

ssh-audit reproduce la identificación y el intercambio inicial, clasifica KEX, host keys, ciphers y MAC, y estima compatibilidad de clientes. -p PORT fija el puerto:

ssh-audit -p PORT TARGET_IP

La herramienta aplica la política de su versión y puede recomendar retirar un algoritmo sin que exista un exploit directo. Conserva su versión, compara el algoritmo realmente negociado con ssh -v y valida la configuración efectiva del servidor. Un banner impreciso también puede afectar a sus recomendaciones de versión.

Leer solo /etc/ssh/sshd_config omite includes, valores predeterminados y bloques Match. sshd -T resuelve la configuración efectiva. -C evalúa un contexto concreto con usuario, host y dirección:

sudo sshd -T -C user=USERNAME,host=FQDN,addr=CLIENT_IP

Revisa listeners, PermitRootLogin, PasswordAuthentication, PubkeyAuthentication, AuthenticationMethods, AllowUsers, AllowGroups, forwarding, AuthorizedKeysFile y subsystems. Los nombres de las directivas deben interpretarse según la versión instalada.

Las conclusiones salen de combinaciones. PermitRootLogin yes solo habilita una ruta si algún método aceptado puede autenticar a root. PasswordAuthentication no no desactiva necesariamente respuestas challenge-response gestionadas por PAM. AllowTcpForwarding, PermitOpen, GatewayPorts y las opciones de cada entrada de authorized_keys determinan qué forwarding puede crear una sesión concreta. Evalúa de nuevo con -C para cada usuario, hostname y origen relevante porque un bloque Match puede cambiar el resultado.

ssh-hostkey recoge host keys, ssh2-enum-algos enumera algoritmos negociables y ssh-auth-methods pregunta por métodos de autenticación para un usuario. sshv1 detecta soporte histórico. ssh-brute, ssh-publickey-acceptance y ssh-run implican credenciales, claves o ejecución y no pertenecen al fingerprint inicial:

nmap -sV -n -Pn -p 22 \
  --script ssh-hostkey,ssh2-enum-algos TARGET_IP

Compara fingerprints con ssh-keyscan solo como recolección. ssh-keyscan no autentica el host. La aceptación debe comparar con una fuente confiable o aplicar TOFU de forma consciente y conservar la primera clave.

Una cuenta puede recibir shell, forced command, SFTP, SCP, subsystems, port forwarding, agent forwarding o X11 según authorized_keys, sshd_config, Match, shell y permisos. ssh -G HOST muestra configuración efectiva del cliente. En servidor, sshd -T -C user=...,host=...,addr=... evalúa condiciones.

Un error Permission denied agrega los métodos intentados, pero no demuestra que el usuario exista. Too many authentication failures puede significar que el agent ofreció demasiadas claves antes de la correcta. Usa IdentitiesOnly yes y una identidad explícita. Diferencia fallo de host key, KEX, cipher, MFA, cuenta, shell y autorización.

Local, remote y dynamic forwarding cambian rutas y crean listeners. Registra bind address, puerto, destino y PID. Agent forwarding expone una capacidad de firma al host remoto y no debe habilitarse por comodidad. OpenSSH registra conexión, método, cuenta, source y sesión según LogLevel. El host observa procesos, PTY, SFTP y forwards.

Al cerrar, termina multiplexed masters y forwards, comprueba sockets, retira claves temporales y no borres entradas previas de known_hosts. Si una clave cambió, conserva ambas fingerprints y resuelve la causa antes de sustituirla.

La comparación de OpenSSH, ssh-keyscan, ssh-audit y NSE está en herramientas y automatización. Usa la checklist para registrar negociación, identidad y capacidades. La cheatsheet conserva comandos ya explicados.

• OpenBSD: ssh(1)
• OpenBSD: sshd(8)
• OpenBSD: sshd_config(5)
• ssh-audit
• Nmap NSE: ssh2-enum-algos
• Nmap NSE: ssh-hostkey