Cómo conectarse por SSH: guía práctica para acceder a servidores Linux

SSH (Secure Shell) es el protocolo estándar para administrar servidores Linux remotos. Si acabas de aprovisionar una VPS o recibiste credenciales de acceso a un servidor, el primer paso es abrir una sesión SSH — todo lo demás (despliegue, instalación de paquetes, configuración de servicios) depende de que esto funcione.

Este tutorial cubre el camino completo: conexión inicial con contraseña, generación y uso de claves SSH, configuración del archivo ~/.ssh/config para simplificar comandos repetitivos, y resolución de los errores más comunes que aparecen en el primer acceso. El foco es el uso práctico en entornos Linux y macOS, con observaciones puntuales para Windows mediante OpenSSH nativo o WSL.

Tiempo estimado de ejecución: 15 a 25 minutos, incluyendo generación de claves y ajustes de configuración.

Requisitos previos

Antes de intentar la conexión, confirma que tienes los datos de acceso del servidor y un cliente SSH disponible en tu máquina local.

Los datos típicos que recibes al contratar una VPS son:

Guarda estos valores — los usarás en los próximos pasos. Si la contraseña llegó por correo en texto plano, considera cambiarla en la primera conexión.

Primera conexión con contraseña

El comando ssh sigue el formato ssh usuario@host -p puerto. Para una conexión básica con las credenciales del ejemplo anterior:

ssh [email protected]

ssh [email protected] -p 2222

The authenticity of host '203.0.113.42 (203.0.113.42)' can't be established.
ED25519 key fingerprint is SHA256:abc123...
Are you sure you want to continue connecting (yes/no/[fingerprint])?

root@servidor:~#

Autenticación por clave SSH

Las claves SSH usan criptografía asimétrica: generas un par (clave privada + clave pública), guardas la privada en tu máquina local y envías la pública al servidor. La autenticación ocurre sin transmitir nunca secretos por la red.

Generar el par de claves

ssh-keygen -t ed25519 -C "[email protected]"

ssh-copy-id [email protected]

cat ~/.ssh/id_ed25519.pub | ssh [email protected] "mkdir -p ~/.ssh && chmod 700 ~/.ssh && cat >> ~/.ssh/authorized_keys && chmod 600 ~/.ssh/authorized_keys"

ssh [email protected]

Configurando ~/.ssh/config

Escribir ssh [email protected] -p 2222 -i ~/.ssh/clave_especifica cada vez resulta tedioso. El archivo ~/.ssh/config permite crear alias por servidor.

nano ~/.ssh/config

Host produccion
    HostName 203.0.113.42
    User root
    Port 22
    IdentityFile ~/.ssh/id_ed25519

Host staging
    HostName 198.51.100.10
    User deploy
    Port 2222
    IdentityFile ~/.ssh/id_staging

chmod 600 ~/.ssh/config

ssh produccion

Reforzando el acceso SSH

Con la clave funcionando, el siguiente paso es cerrar el acceso por contraseña y ajustar el servicio SSH en el servidor.

sudo nano /etc/ssh/sshd_config

PasswordAuthentication no
PermitRootLogin prohibit-password
PubkeyAuthentication yes

sudo sshd -t

sudo systemctl reload ssh

Verificación

Confirma que todo funciona como se espera:

ssh -v produccion

El modo verbose (-v) muestra cada etapa: lectura del config, negociación de algoritmos, oferta de claves. Busca:

debug1: Authentication succeeded (publickey).

Esto confirma que la autenticación se realizó por clave, no por contraseña. Si aparece password, algo no se ha aplicado correctamente.

Desde el servidor, verifica los intentos recientes:

sudo journalctl -u ssh --since "10 minutes ago"

Verás líneas del tipo Accepted publickey for root from ... port ... ssh2.

Resolución de problemas

Permission denied (publickey)

La clave pública no está en ~/.ssh/authorized_keys en el servidor, o los permisos son incorrectos. En el servidor:

chmod 700 ~/.ssh
chmod 600 ~/.ssh/authorized_keys

Verifica también que el cliente esté ofreciendo la clave correspondiente — usa ssh -v y busca Offering public key.

Connection refused

El servicio SSH no está en ejecución, o el firewall bloquea el puerto. En el servidor:

sudo systemctl status ssh
sudo ss -tlnp | grep ssh

Si está activo, revisa el firewall (sudo ufw status o las reglas del proveedor).

Connection timed out

Generalmente es un problema de red o IP incorrecta. Prueba la conectividad básica:

ping 203.0.113.42
nc -zv 203.0.113.42 22

Si nc falla pero ping funciona, el puerto está bloqueado en algún punto del camino.

Host key verification failed

La huella digital del servidor cambió desde la última conexión (servidor reinstalado, IP reciclada). Elimina la entrada antigua:

ssh-keygen -R 203.0.113.42

Y vuelve a conectarte — el cliente pedirá confirmación de la nueva huella digital.

Próximos pasos

Con SSH funcionando de forma segura, el servidor está listo para trabajo real. Algunas direcciones para profundizar:

• Configura fail2ban para bloquear IPs con intentos excesivos de autenticación.
• Usa mosh en conexiones inestables (móvil, Wi-Fi deficiente) — mantiene la sesión activa incluso con cambios de red.
• Aprende port forwarding (ssh -L y ssh -R) para acceder a servicios internos del servidor sin exponerlos a internet.
• Configura ssh-agent para introducir la frase de contraseña una sola vez por sesión de trabajo.
• Estudia los bloques Match en sshd_config para aplicar políticas distintas por usuario o red.

Si estás poniendo un proyecto en producción y quieres evitar problemas con SSH y firewall mal configurados, una VPS Hostini ya viene con SSH habilitado, IPv4 dedicado y acceso root inmediato — solo tienes que seguir los pasos de este tutorial a partir del correo de aprovisionamiento.