WardtermCliente SSH
ES
Descargar

Cómo depurar una conexión SSH

Ejecuta ssh -v user@server y mira las últimas líneas antes del fallo: indican en qué fase se rompió. Ejecuta ssh -G user@server para ver los ajustes que se aplican de verdad. Si el servidor te rechaza, el motivo solo está de su lado, así que lee su registro o ejecuta sudo /usr/sbin/sshd -d -p 2200 y conecta al puerto 2200. Imprime por qué se rechazó el acceso.

Actualizada el . Salida del cliente capturada con OpenSSH 10.3 en macOS y 10.0 en Debian 13 contra un servidor Debian 13.

Del lado del cliente: ssh -v

ssh -v user@server

Una conexión pasa por fases en un orden fijo. Busca la última fase que aparece en la salida y sabrás dónde está el problema.

1. Lectura de la configuración

debug1: OpenSSH_10.3p1, LibreSSL 3.3.6
debug1: Reading configuration data /Users/you/.ssh/config
debug1: Reading configuration data /etc/ssh/ssh_config

Esto muestra la versión del cliente y los archivos de configuración que usó. Las líneas que mencionan un bloque Host te dicen cuáles coincidieron.

2. Conexión

debug1: Connecting to server [203.0.113.10] port 22.
debug1: Connection established.

Comprueba que la dirección y el puerto son los que esperabas. Si nunca llegas a Connection established, el problema es la red o el servicio, no tu acceso:

ssh: connect to host 203.0.113.10 port 22: Connection refused

Mira connection refused, connection timed out y could not resolve hostname.

3. Identificación de las claves y encuentro con el servidor

debug1: identity file /Users/you/.ssh/id_ed25519 type 2
debug1: Local version string SSH-2.0-OpenSSH_10.3
debug1: Remote protocol version 2.0, remote software version OpenSSH_10.0p2 Debian-7+deb13u4
debug1: Authenticating to server:22 as 'user'

Comprueba el nombre de usuario en la última línea. Un usuario equivocado es fácil de pasar por alto y basta para que el acceso falle. identity file ... type -1 significa que ese archivo no se encontró, lo cual es normal para tipos de clave que no tienes.

4. Acuerdo de algoritmos

debug1: kex: algorithm: mlkem768x25519-sha256
debug1: kex: host key algorithm: ssh-ed25519
debug1: kex: server->client cipher: chacha20-poly1305@openssh.com MAC: <implicit> compression: none
debug1: kex: client->server cipher: chacha20-poly1305@openssh.com MAC: <implicit> compression: none

Si no hay coincidencia, se detiene aquí con un mensaje Unable to negotiate. Mira no matching key exchange.

5. Comprobación de la identidad del servidor

debug1: Server host key: ssh-ed25519 SHA256:c+CTM4jkNvBP8UG87Uh12f2SwOsRapfKmGCO8Yv6tc4
debug1: Host 'server' is known and matches the ED25519 host key.
debug1: Found key in /Users/you/.ssh/known_hosts:1

Si la clave no coincide, se detiene aquí. Mira host key changed.

6. Inicio de sesión

La mayoría de los problemas están aquí. Así se ve un fallo:

debug1: Authentications that can continue: publickey,password
debug1: Next authentication method: publickey
debug1: Will attempt key: /Users/you/.ssh/id_ed25519 ED25519 SHA256:5WGoVhFgmqkQ/7SmXA0cfMDG6u2weqiLGzzf+uY8hCg explicit
debug1: Offering public key: /Users/you/.ssh/id_ed25519 ED25519 SHA256:5WGoVhFgmqkQ/7SmXA0cfMDG6u2weqiLGzzf+uY8hCg explicit
debug1: Authentications that can continue: publickey,password
debug1: No more authentication methods to try.
user@server: Permission denied (publickey,password).

Y así un éxito:

debug1: Offering public key: /Users/you/.ssh/id_ed25519 ED25519 SHA256:NxFS05Q+k1zf9LgrjGPL94UJfFS6B/89THkWACOEJgg explicit
debug1: Server accepts key: /Users/you/.ssh/id_ed25519 ED25519 SHA256:NxFS05Q+k1zf9LgrjGPL94UJfFS6B/89THkWACOEJgg explicit
Authenticated to server ([203.0.113.10]:22) using "publickey".
Lo que vesQué significa
Ninguna línea Offering public keyEl cliente no encontró ninguna clave que probar. Revisa la ruta, o usa -i.
Se ofrece una clave distinta de la que queríasDefine IdentityFile e IdentitiesOnly yes para ese host.
Offering sin Server accepts keyEl servidor no aceptó esa clave. El motivo está en su registro. Mira más abajo.
Server accepts key, y luego un falloAl servidor le gusta la clave, pero el cliente no pudo firmar, por ejemplo por una frase de contraseña incorrecta.
En Authentications that can continue falta lo que queríasEl servidor ha desactivado ese método.

Mira Permission denied (publickey) para las soluciones.

7. Tras iniciar sesión

debug1: Entering interactive session.
debug1: Sending command: true
debug1: Exit status 0

Si el acceso funciona y la sesión se cierra enseguida, mira la shell, los archivos de arranque o un comando forzado en el servidor, no SSH en sí.

-v, -vv y -vvv

Para un acceso fallido, nuestra prueba imprimió 49 líneas con -v, 95 con -vv y 133 con -vvv.

  • -vv añade las listas completas de algoritmos que ofrece cada parte, bajo local client KEXINIT proposal y peer server KEXINIT proposal. Úsalo para problemas de algoritmos.
  • -vvv añade detalle de bajo nivel como debug3: send packet: type 20. Rara vez ayuda, salvo que vayas a informar de un fallo.

Para guardar la salida en un archivo, o ver solo lo importante:

ssh -v -E debug.log user@server
ssh -v user@server 2>&1 | grep -E 'Connecting|Offering|accepts|Authenticat|denied'

Ver los ajustes reales: ssh -G

ssh -G server | grep -E '^(user|hostname|port|identityfile|proxyjump) '

Esto imprime lo que el cliente usaría tras leer toda su configuración, y no se conecta. Zanja la mayoría de las discusiones sobre qué bloque Host se aplica. Con esta configuración:

Host web*
    User deploy
    Port 2200
    HostName 203.0.113.10
Host *
    User other
    Port 22

ssh -G web1 da lo siguiente, porque gana el primer valor encontrado:

user deploy
hostname 203.0.113.10
port 2200

Hay más en la guía del archivo ssh config.

Probar sin terminal: ssh -T

-T no pide terminal. Ayuda a distinguir un problema de acceso de un problema de sesión:

ssh -T user@server 'tty; echo TERM=$TERM'
not a tty
TERM=dumb

Los servicios que no dan shell, como el alojamiento de Git, se prueban normalmente así: ssh -T git@github.com.

Del lado del servidor

Por seguridad, el cliente solo oye Permission denied. El motivo va al registro del servidor, así que léelo primero si tienes otra forma de entrar. Mira cómo revisar los intentos de acceso.

sshd -d en otro puerto

Esto inicia un segundo servidor que atiende una conexión, imprime todo y termina. Tu sshd normal sigue funcionando:

sudo /usr/sbin/sshd -d -p 2200

Luego, desde tu equipo:

ssh -p 2200 user@server

Puede que un cortafuegos tenga que permitir ese puerto. Hace falta la ruta completa: sin ella obtienes sshd requires execution with an absolute path. Esta es la parte importante de la salida cuando authorized_keys tenía un modo incorrecto:

debug1: userauth-request for user user service ssh-connection method publickey [preauth]
debug1: trying public key file /home/user/.ssh/authorized_keys
Authentication refused: bad ownership or modes for file /home/user/.ssh/authorized_keys
Failed publickey for user from 203.0.113.10 port 60932 ssh2: ED25519 SHA256:NxFS05Q+k1zf9LgrjGPL94UJfFS6B/89THkWACOEJgg

Y cuando funciona:

debug1: trying public key file /home/user/.ssh/authorized_keys
debug1: /home/user/.ssh/authorized_keys:1: matching key found: ED25519 SHA256:NxFS05Q+k1zf9LgrjGPL94UJfFS6B/89THkWACOEJgg
Accepted key ED25519 SHA256:NxFS05Q+k1zf9LgrjGPL94UJfFS6B/89THkWACOEJgg found at /home/user/.ssh/authorized_keys:1

Usa -dd o -ddd para más detalle. Detenlo con Ctrl+C si nadie se conecta. Si tu conexión nunca aparece en esta salida, algo delante del servidor, como un cortafuegos, la está bloqueando.

sshd -T: los ajustes en uso

sudo sshd -T | grep -iE '^(port|passwordauthentication|pubkeyauthentication|authorizedkeysfile|permitrootlogin|maxauthtries) '

Esto lee los archivos de configuración como lo hace el servidor, incluidos los que se incluyen, e imprime los resultados. Muestra los ajustes tal como los definen los archivos, así que un servidor aún no recargado puede estar usando valores anteriores. Para ver el efecto de los bloques Match, describe una conexión:

sudo sshd -T -C user=user,host=client.example.com,addr=203.0.113.10 | grep -i passwordauthentication

Usa sudo sshd -t para comprobar solo la sintaxis. No imprime nada si todo está bien.

Preguntas

¿Es seguro compartir la salida de ssh -v?

No contiene tus contraseñas ni tus claves privadas, pero sí muestra nombres de usuario, nombres de host, direcciones, rutas de claves y huellas. Léela entera antes de publicarla en cualquier sitio público.

¿Debo usar siempre -vvv?

No. Empieza con -v. Responde a la mayoría de las preguntas, y los niveles extra añaden sobre todo detalle del protocolo.

Fuentes

Más en Mensajes de error

Todas las guías