Errores comunes de SSH: Guía de supervivencia
Hoy veremos algunas formas de verificar y depurar algunos errores comunes de ssh con los que podemos toparnos al intentar conectarnos a un servidor, y algunos tips útiles para solucionar problemas.
- Introducción
- Las configuraciones generales (/etc/ssh/)
- El directorio ~/.ssh
- El archivo ~/.ssh/config
- El directorio ~/.ssh/config.d/
- Depurando la conexión
- Verificando configuración del servidor
- Verificando configuración del cliente
- Permisos de archivos del cliente
- ¿Muchas contraseñas o passphrases?
- Errores comunes de ssh (y soluciones)
- Conclusión
Introducción
El servicio de SSH es un servicio de tipo cliente-servidor, por lo que tenemos configuraciones tanto de cliente como del servidor.
En este post vamos a analizar algunas formas de depurar errores tanto del cliente como del servidor, cuando no podemos establecer la conexión.
En general, en OpenSSH, «ssh» hace referencia al cliente, al comando que utilizamos para conectarnos, mientras que «sshd» es el servidor, el «daemon» o «demonio» que está atendiendo un puerto esperando conexiones.
Estos nombres se mantienen en los archivos y directorios de configuración, como veremos a continuación.
Las configuraciones generales (/etc/ssh/)
Cuando instalamos OpenSSH, el directorio de configuración principal es /etc/ssh/.
Allí dentro encontraremos varios archivos, como claves de host, módulos para el intercambio Diffie-Hellman, etc., pero de eso hablaremos en otra oportunidad (y, por supuesto, está incluido en el curso de SSH).
📚 ¿Querés saber más de las maravillas de SSH? Sumate a nuestro curso!
Los archivos que nos interesan hoy son los siguientes:
/etc/ssh/ssh_config: Archivo de configuraciones generales del cliente./etc/ssh/ssh_config.d/: Directorio de configuraciones adicionales del cliente./etc/ssh/sshd_config: Archivo de configuraciones generales del servidor./etc/ssh/sshd_config.d/: Directorio de configuraciones adicionales del servidor.
En general, dentro de los archivos de configuración se encuentra una línea «Include ...» que permite incluir todas las configuraciones de los archivos que se encuentren en un directorio particular.
Esto es muy útil para estructurar las configuraciones de cliente y servidor, facilitando la depuración y mantenibilidad del servicio.
Así, dentro del archivo /etc/ssh/ssh_config encontraremos algo similar a esto:
Include /etc/ssh/ssh_config.d/*.conf
Mientras que en el archivo de configuración general del servidor, /etc/ssh/sshd_config, encontraremos algo como esto:
Include /etc/ssh/sshd_config.d/*.conf
De esta forma podremos añadir archivos de configuración de cliente dentro de /etc/ssh/ssh_config.d/, o de servidor en /etc/ssh/sshd_config.d/, que serán considerados en el funcionamiento del servicio, y no habremos modificado los archivos principales de configuración.
El directorio ~/.ssh
Además de las configuraciones generales, cada usuario tendrá sus propias configuraciones personales de su cliente de ssh, que podrá modificar sin necesidad de cambiar configuraciones generales.
El directorio ~/.ssh dentro del home de un usuario se crea de manera predeterminada cuando el cliente intenta escribir archivos dentro. Esto ocurre en algunos casos puntuales, por ejemplo:
- Cuando el cliente intenta establecer una conexión con un servidor, se crea (si no existe) el directorio
~/.sshpara poder escribir dentro el archivoknown_hosts. - Cuando el usuario crea un par de claves para autenticación asimétrica usando
ssh-keygen, se crea el directorio~/.ssh(si no existe) para almacenar dichas claves.
Así que sí, es posible que, solamente con instalar el cliente de SSH, dicho directorio no exista.
Si queremos crearlo manualmente, deberemos tener especial cuidado en los permisos (como veremos más adelante):
mkdir ~/.ssh
chmod 700 ~/.ssh
El archivo ~/.ssh/config
Este es el archivo principal de configuraciones personalizadas del cliente. Aquí podremos añadir, por ejemplo, configuraciones de seguridad y hardening del cliente, bloques Host para facilitarnos las conexiones, etc.
Este archivo a veces no se crea de manera predeterminada, por lo que, si vamos a añadir nuestras propias configuraciones de usuario, deberemos crearlo.
touch ~/.ssh/config
chmod 600 ~/.ssh/config
El directorio ~/.ssh/config.d/
Si vamos a tener muchas configuraciones de cliente, por ejemplo, varios bloques hosts para conectarnos a diferentes redes o ambientes de trabajo, sería conveniente que los agrupáramos según algún criterio de afinidad (por ejemplo, hosts virtuales, hosts de la nube de servidores del trabajo, hosts locales en casa, etc.).
Podríamos crear varios archivos con diversas configuraciones dentro del directorio ~/.ssh/config.d/, y luego incluirlos en la configuración principales de nuestro cliente.
Si no existe el directorio, deberemos crearlo y asignar los permisos correctos:
mkdir ~/.ssh/config.d
chmod 700 ~/.ssh/config.d
Ahí dentro podremos añadir nuestros archivos de configuraciones personalizados, y luego leerlos desde el archivo de configuración de nuestro cliente, ~/.ssh/config, añadiendo allí esta línea:
Include ~/.ssh/config.d/*
📚 ¿Querés saber más de las maravillas de SSH? Sumate a nuestro curso!
Depurando la conexión
Si al intentar conectarnos con un servidor remoto vemos un error genérico, estilo «Connection refused» o similar, el cliente de ssh nos permite depurar la conexión mostrando mensajes de debug.
Esto lo hacemos aumentando el nivel de verbosidad (o explicabilidad) del comando ssh. Como con casi cualquier comando en GNU/Linux, podemos lograrlo con la opción -v.
La única diferencia, el comando ssh permite especificar hasta 3 -v, añadiendo info de debug más específica cada vez. Es decir:
- ssh -v: nivel estándar.
- ssh -vv: más detalles de intercambio de claves.
- ssh -vvv: información máxima, ideal para depurar problemas de protocolo, cifrado, etc.
Veamos un ejemplo de los diferentes niveles de mensajes de depuración:

Verificando configuración del servidor
Si cambiás configuraciones en el servidor, en el archivo /etc/ssh/sshd_config, o en archivos dentro de /etc/ssh/sshd_config.d, lo primero que tenés que hacer para que el servidor tome los cambios es recargarlo o reiniciarlo.
Ahora bien, si te equivocaste con alguna línea de configuración y reiniciás el servicio, seguramente mantengas tu conexión, pero puede que el servidor no haya iniciado nuevamente, por lo que si te desconectás, no podrás volver a conectarte.
Una buena forma de evitar inconvenientes es verificar la sintaxis de la configuración del servidor utilizando la opción -t del comando sshd (como root para que pueda leer las hostkeys y no fallar con error).
Esta opción verificará la sintaxis del archivo principal de configuración del servidor, /etc/ssh/sshd_config, y de todos los archivos incluidos dentro de /etc/ssh/sshd_config.d/, mostrando las líneas donde se produjeron errores, y las opciones de configuración consideradas obsoletas (no son errores, pero podemos estudiar eliminarlas).
De esta forma nos aseguraremos que las opciones que hayamos cargado sean correctas, y el servidor pueda reiniciar sin problemas.
Por cierto, si el comando sudo sshd -t no genera salida, es que está todo bien 🙂
Verificando configuración del cliente
Si bien no tenemos un sshd -t pero para el lado del cliente, sí que tenemos una interesante opción para ejecutar el cliente: -G.
Si tenemos uno o varios archivos de configuración del cliente, con configuraciones globales para todo el sistema, y configuraciones personales de usuario, la opción -G al intentar conectarnos a un host nos va a listar todas las opciones que realmente se están aplicando a dicho host.
Por ejemplo, si ejecutamos esto:
ssh -G devuan
El cliente va a listar todas las opciones que se cargan al intentar conectarnos a dicho host.
Cabe aclarar que en este caso tengo un bloque Host configurado con el nombre «devuan», pero la idea es simplemente añadir la opción -G a nuestra línea de conexión:
ssh -G diego@ip_servidor
Con esta opción no realizará una conexión al servidor, sino que realizará un «dump» de la configuración que aplicaría, es decir, mostrará el puerto al que intentará conectarse, el IdentityFile en el caso de que lo usemos, un opciones como ProxyJump, ForwardAgent, etc.
Tip PRO
La salida de este comando va al stdout, pero si añadimos las opciones de verbosity (-v, -vv, -vvv), tendremos información de depuración en la salida de error, y allí también veremos los errores, si es que los hay.
En fin, una buena de ver estos errores es combinar las opciones de verbosidad con la -G, y mostrar solamente la stderr:
ssh -v -G devuan > /dev/null

Permisos de archivos del cliente
Para SSH, «si no es privado, no es seguro», esa es su regla de oro.
Por más que hayas creado tus claves, si estas tienen permisos demasiado abiertos, no te dejará utilizarlas, y el cliente intentará otro tipo de autenticación.

Las claves y archivos de configuración del cliente deben ser sólo visibles al usuario al que pertenecen. Si una clave de tu usuario también puede ser leída por otro usuario del sistema, el cliente de ssh la ignorará.
Para simplificar las configuraciones de permisos, y configurarlo en modo paranoico, setear los siguientes permisos:
- Directorios
~/.ssh/y~/.ssh/config.d/: permisos700 (rwx------) - Archivos dentro de esos directorios: permisos
600 (rw-------)
Esa es la configuración funcional y segura más fácil de implementar, y más restrictiva de lo necesario. Por ejemplo, los archivos de clave pública (~/.ssh/*.pub) podrían tener permisos 644 (rw-r--r--) que todo funcionaría igual.
Al realizar esta restricción, podemos configurar todos estos permisos con dos comandos:
# Directorios:
find ~/.ssh -type d -exec chmod 700 {} +
# Archivos:
find ~/.ssh -type f -exec chmod 600 {} +
Y, obviamente, todos esos archivos deben tener como propietario usuario dentro de cuyo Home se encuentren:
sudo chown -R $USER:$USER ~/.ssh
¿Muchas contraseñas o passphrases?
Si nos conectamos utilizando contraseñas, o mediante clave privada, pero nuestras claves privadas están protegidas con passphrases, será frecuente meter mal un dedo en el teclado y fallar en la conexión.
Aquí tenemos una solución: usar ssh-agent.
¿Qué es y cómo se usa? Eso te lo explico en estos posts:
Errores comunes de ssh (y soluciones)
Para ir terminando, en esta tabla te resumo algunos problemas comunes que podemos tener a la hora de conectarnos con ssh, con sus causas y soluciones.
Seguramente se me hayan escapado varios, si ven que falta alguno me avisan y lo añadimos!
| Error en terminal | Causa probable | Solución sugerida |
| Connection refused | El servicio sshd no corre en el server o el puerto es incorrecto. | Verifica el puerto con -p (cliente) o inicia el servicio (servidor): sudo systemctl start ssh. |
| Permission denied (publickey) | El servidor no tiene tu llave pública o no la estás enviando. | Copia tu llave: ssh-copy-id usuario@host o verifica tu IdentityFile en el config del cliente. |
| Permissions 0644 are too open | Tu llave privada (id_ed25519) es legible por otros usuarios. | Ejecuta: chmod 600 ~/.ssh/id_ed25519. ¿Por qué ed25519? Miralo acá ▶️. |
| Host key verification failed | La «huella» o «fingerprint» del servidor cambió (reinstalación, cambio de IP). | Limpia la entrada vieja: ssh-keygen -R [IP-o-HOST]. |
| Connection timed out | Un firewall (nftables, iptables, firewall de cloud, etc.) está bloqueando el tráfico. | Abre el puerto (ej. 22) en el firewall del servidor y del proveedor de nube. |
| Connection closed by remote host | El servidor rechazó la conexión (posiblemente por AllowUsers o MaxAuthsTries). | Revisa /etc/ssh/sshd_config y los logs en /var/log/auth.log. |
| No route to host | Problema de red local o IP incorrecta. | Verifica con ping que el servidor sea alcanzable en la red. |
| Too many authentication failures | Tienes demasiadas llaves en tu agente y el server te bloquea. | Usa IdentitiesOnly yes en tu config, o limpia el agente: ssh-add -D. |
📚 ¿Querés saber más de las maravillas de SSH? Sumate a nuestro curso!
Conclusión
Y hemos llegado al final!
Hoy vimos algunos tips que pueden ser de mucha utilidad para solucionar algunos problemas comunes con nuestro cliente o servidor de SSH, y cómo solucionarlos.
Para ello, recorrimos algunas configuraciones fundamentales de cliente y servidor, y los permisos de los archivos de config y de claves, para evitar problemas, y mejorar nuestra seguridad.
Espero que les resulte útil e interesante!
Como siempre, cualquier duda que tengan, me avisan!