Antes de SSH, administrar un servidor remoto significaba enviar tu contraseña en texto plano por la red. Cualquiera con acceso al tráfico intermedio podía leerla. SSH (Secure Shell) resolvió eso en 1995, y desde entonces es el protocolo estándar para shells remotas cifradas. Telnet sigue existiendo en algunos sistemas, pero nadie con criterio lo usa para administración.
Lo que hace SSH es establecer un canal cifrado entre tu máquina (el cliente) y el servidor remoto, autenticarte, y darte una shell interactiva o ejecutar comandos directamente. Todo el tráfico — incluyendo contraseñas, comandos y salida — viaja cifrado. El paquete que necesitas en el servidor es openssh-server; el cliente (openssh-client) viene instalado por defecto en Debian.
El modelo de confianza de SSH merece atención porque es distinto al de HTTPS. No hay una autoridad certificadora central que valide los servidores. En su lugar, SSH usa TOFU (Trust On First Use): la primera vez que te conectas a un servidor, el protocolo te muestra el fingerprint de su clave pública y te pregunta si confías en él. Si dices que sí, ese fingerprint se guarda en ~/.ssh/known_hosts. En conexiones posteriores, SSH comprueba que el servidor presenta la misma clave. Si no coincide — porque el servidor fue reinstalado, porque la clave rotó, o porque hay algo malicioso en medio — SSH detiene la conexión con un error explícito. Ese error no se ignora; se investiga.
La autenticación por contraseña funciona y es el punto de entrada más sencillo, pero en producción es un problema: expone el servidor a ataques de fuerza bruta automatizados. Para un primer contacto o un entorno de laboratorio es aceptable; para cualquier servidor accesible desde internet, la autenticación por clave pública es lo que se usa (eso se cubre en un artículo posterior).
Si algo falla al conectar, el primer sitio donde mirar en el servidor es /var/log/auth.log: ahí aparecen los intentos de autenticación, los rechazos y los errores del demonio.
# Instalar el servidor SSH (si aún no está) sudo apt install openssh-server # Verificar que el demonio está corriendo y habilitado sudo systemctl status ssh # Conectar al servidor en el puerto estándar (22) ssh ana@192.168.1.50 # Primera conexión: SSH muestra algo así y pide confirmación: # # The authenticity of host '192.168.1.50 (192.168.1.50)' can't be established. # ED25519 key fingerprint is SHA256:abc123xyz.../... # Are you sure you want to continue connecting (yes/no/[fingerprint])? yes # # Escribe "yes" solo si puedes verificar el fingerprint con el administrador # del servidor, o si es una máquina que tú mismo controlas. # Tras aceptar, el fingerprint queda registrado: cat ~/.ssh/known_hosts # Conectar a un puerto no estándar (el servidor escucha en 2222) ssh ana@192.168.1.50 -p 2222 # Ejecutar un comando remoto puntual sin abrir shell interactiva ssh ana@192.168.1.50 uptime # Si el fingerprint no coincide (servidor reinstalado, clave cambiada), # SSH muestra un error así y RECHAZA la conexión: # # WARNING: REMOTE HOST IDENTIFICATION HAS CHANGED! # IT IS POSSIBLE THAT SOMEONE IS DOING SOMETHING NASTY! # # Si verificaste que es legítimo (reinstalación conocida), elimina # la entrada antigua de known_hosts para ese host: ssh-keygen -R 192.168.1.50 # Para un servidor en puerto no estándar, especifica el puerto también: ssh-keygen -R '[192.168.1.50]:2222' # Ver los intentos de autenticación en el servidor sudo tail -f /var/log/auth.log
El systemctl status ssh del principio confirma dos cosas: que el servicio está activo (active (running)) y que arranca automáticamente con el sistema (enabled). Si ves inactive o disabled, el servidor no acepta conexiones aunque el paquete esté instalado; sudo systemctl enable --now ssh lo resuelve.
Cuando ejecutas ssh ana@192.168.1.50, el cliente busca primero en ~/.ssh/known_hosts si ya tiene registrado ese host. Si lo encuentra, compara el fingerprint. Si no lo encuentra, hace la pregunta TOFU. Este mecanismo es lo que distingue SSH de una conexión en texto plano: el cifrado protege los datos en tránsito, pero la verificación del fingerprint es lo que te garantiza que estás hablando con el servidor correcto y no con un intermediario.
La opción -p 2222 cambia el puerto de destino. Algunos administradores mueven SSH a un puerto no estándar para reducir el ruido en los logs (menos bots escaneando el 22), aunque no es una medida de seguridad real por sí sola.
La línea ssh-keygen -R 192.168.1.50 edita ~/.ssh/known_hosts y elimina todas las entradas para esa IP. Es el procedimiento correcto cuando sabes con certeza por qué cambió la clave del servidor. Lo que nunca debes hacer es desactivar la verificación con -o StrictHostKeyChecking=no de forma permanente o en scripts de producción: eso anula exactamente la protección que hace útil a SSH.
En /var/log/auth.log verás líneas como Accepted password for ana from 192.168.1.100 o Failed password for root from 185.x.x.x. Si el servidor lleva más de una hora expuesto en el puerto 22 con contraseña habilitada, ese log ya tiene cientos de intentos fallidos de robots buscando credenciales débiles.
N° 81