Activar SSH en Ubuntu: instalar OpenSSH y protegerlo
- 6 de octubre de 2026
- 09:00
- Por Adrien Roche
- Redes
Activar SSH en Ubuntu: instalar, iniciar y abrir el firewall
SSH en Ubuntu proviene del paquete openssh-server. Ubuntu Server ofrece instalarlo durante la configuración y casi todas las imágenes de nube o VPS ya lo traen escuchando; Ubuntu Desktop no lo instala en absoluto.
1. Instalar openssh-server
sudo apt update
sudo apt install -y openssh-serverSi el paquete ya está presente, apt lo indica y no cambia nada. La instalación también registra un perfil de aplicación de UFW llamado OpenSSH, que se usa en el paso 3.
2. Habilitar e iniciar el servicio
sudo systemctl enable --now ssh
systemctl status sshEn Ubuntu la unidad se llama ssh; sshd es un alias. enable --now arranca el demonio ahora y en cada inicio. Desde Ubuntu 22.10 sshd se activa por socket: ssh.socket es el propietario del puerto 22 e inicia ssh.service en la primera conexión entrante, por lo que un estado inactive (dead) con TriggeredBy: ssh.socket justo después de la instalación es normal: el puerto está abierto. Para una visión más amplia, consulta cómo listar servicios con systemctl.
3. Permitir SSH a través de UFW
Ubuntu trae UFW desactivado. Si lo activas, permite SSH primero; habilitar el firewall antes de que exista la regla es la forma clásica de quedarte fuera de una máquina remota.
sudo ufw allow OpenSSH
sudo ufw enable
sudo ufw statusufw allow OpenSSH usa el perfil de aplicación y abre el 22/tcp. Si más adelante mueves sshd, permite el nuevo puerto con sudo ufw allow 2222/tcp y elimina la regla antigua. Averigua la dirección del servidor con hostname -I.
Conectarse desde Windows, macOS o Linux
Todos los sistemas operativos de escritorio actuales incluyen un cliente OpenSSH integrado, y la sintaxis es idéntica en todas partes:
ssh username@SERVER_IP
ssh -p 2222 username@SERVER_IP # non-default port- Windows 10 y 11: abre PowerShell o Windows Terminal y escribe el comando; el cliente OpenSSH se incluye en Windows desde 2018 (versión 1809). Si
sshno se reconoce, añádelo en Configuración > Aplicaciones > Características opcionales. - macOS: Terminal, el mismo comando.
- Linux: cualquier terminal;
openssh-clientviene instalado por defecto en Ubuntu.
En la primera conexión, acepta la huella de la clave de host del servidor con yes; se guarda en ~/.ssh/known_hosts y se te avisará si alguna vez cambia. Después escribe la contraseña de la cuenta: la siguiente sección la sustituye por una clave.
Pasar a la autenticación por clave
Los inicios de sesión con contraseña son lo que las botnets intentan por fuerza bruta a todas horas; las claves vuelven inútiles esos intentos. Genera un par de claves Ed25519 en tu propio equipo, nunca en el servidor:
ssh-keygen -t ed25519 -C "laptop-2026"Acepta la ruta por defecto (~/.ssh/id_ed25519) y define una frase de contraseña; cifra la clave privada en disco, y con un agente SSH solo la escribes una vez por sesión. Únicamente el archivo .pub sale de tu máquina.
Copiar la clave pública al servidor
En macOS y Linux, ssh-copy-id lo hace en un solo paso, usando tu contraseña por última vez:
ssh-copy-id -i ~/.ssh/id_ed25519.pub username@SERVER_IPLa versión de OpenSSH para Windows no incluye ssh-copy-id; en su lugar, envía la clave desde PowerShell mediante una tubería:
type $env:USERPROFILE\.ssh\id_ed25519.pub | ssh username@SERVER_IP "mkdir -p ~/.ssh && chmod 700 ~/.ssh && cat >> ~/.ssh/authorized_keys && chmod 600 ~/.ssh/authorized_keys"Ambos métodos añaden la clave al archivo ~/.ssh/authorized_keys de ese usuario. Los permisos importan: sshd ignora el archivo en silencio cuando ~/.ssh no tiene el modo 700 o si authorized_keys es escribible por alguien que no sea su propietario. Desde una terminal nueva, ssh username@SERVER_IP debería iniciar sesión sin la contraseña de la cuenta. No toques la siguiente sección hasta que funcione.
Endurecer sshd_config: sin contraseñas, sin root, con usuarios en lista
Mantén abierta la sesión actual mientras editas; si la nueva configuración rompe algo, es tu vía de regreso. /etc/ssh/sshd_config empieza con Include /etc/ssh/sshd_config.d/*.conf, y sshd conserva el primer valor que lee para cada palabra clave, de modo que un drop-in gana frente a cualquier línea posterior del archivo principal. Además, las imágenes de nube suelen incluir /etc/ssh/sshd_config.d/50-cloud-init.conf con PasswordAuthentication yes, y por eso editar el archivo principal parece tan a menudo no servir de nada. La solución es un drop-in cuyo nombre se ordene primero:
sudo nano /etc/ssh/sshd_config.d/00-hardening.confPega lo siguiente, sustituyendo username por tu propio usuario:
PasswordAuthentication no
KbdInteractiveAuthentication no
PubkeyAuthentication yes
PermitRootLogin no
AllowUsers username
MaxAuthTries 3
LoginGraceTime 30
X11Forwarding no
ClientAliveInterval 300
ClientAliveCountMax 2PermitRootLogin no supone que tienes una cuenta sin privilegios con derechos de sudo. Si hasta ahora has trabajado como root, crea un usuario sudo en Linux y copia tu clave en él antes de aplicar el archivo. Después valida la sintaxis, recarga y comprueba los valores que sshd usa realmente una vez fusionados todos los includes: eso es lo que imprime sshd -T:
sudo sshd -t
sudo systemctl reload ssh
sudo sshd -T | grep -Ei 'passwordauthentication|permitrootlogin|allowusers|port'Abre una segunda terminal e inicia sesión con tu clave antes de cerrar la primera. Qué hace cada directiva:
| Directiva | Valor | Efecto |
|---|---|---|
PasswordAuthentication | no | Solo claves; la fuerza bruta de contraseñas pasa de lenta a imposible. |
KbdInteractiveAuthentication | no | Cierra la vía de desafío-respuesta que PAM podría usar para contraseñas (antes ChallengeResponseAuthentication). |
PermitRootLogin | no | Root no puede iniciar sesión por SSH, con clave o sin ella; usa sudo. |
AllowUsers | tu(s) usuario(s) | Los usuarios no listados se rechazan antes de la autenticación; [email protected]/24 ata un usuario a una red. |
MaxAuthTries | 3 | Tres intentos fallidos por conexión y se corta. |
LoginGraceTime | 30 | Las conexiones sin autenticar se cortan a los 30 segundos. |
ClientAliveInterval / ClientAliveCountMax | 300 / 2 | Sondea a un cliente inactivo cada cinco minutos y lo desconecta tras dos sondeos sin respuesta; los clientes vivos responden automáticamente. |
X11Forwarding | no | Desactivado salvo que reenvíes aplicaciones gráficas. |
El keepalive también tiene su lado cliente: ServerAliveInterval 60 en ~/.ssh/config en tu propio equipo evita que los routers NAT corten las sesiones inactivas.
Cambiar el puerto SSH no es seguridad
Mover sshd fuera del puerto 22 es un consejo popular. Lo que consigues son menos líneas de registro. Los escáneres masivos barren los 65.535 puertos y encuentran sshd en el 2222 en cuestión de horas; quien te tenga en el punto de mira lo localiza en segundos con nmap. Las claves, el bloqueo del acceso root, una lista de permitidos y fail2ban son la seguridad; el puerto es cosmético. Aun así ayuda en un servidor concurrido a mantener legible el registro de autenticación, pero nunca lo cuentes como una capa de defensa.
Si decides cambiarlo, respeta este orden: abre el nuevo puerto en UFW, cambia el puerto, reinicia, prueba desde una segunda terminal y luego elimina la regla antigua. Descomenta #Port 22 en /etc/ssh/sshd_config, define el nuevo puerto y después:
sudo ufw allow 2222/tcp
sudo sshd -t
sudo systemctl daemon-reload
sudo systemctl restart ssh.socket # Ubuntu 22.10 and later
sudo systemctl restart ssh # Ubuntu 22.04 and earlierEn las versiones con activación por socket es la unidad de socket, y no sshd, la que decide qué puerto se enlaza; Ubuntu incluye un generador de systemd que lee Port de la configuración de sshd durante el daemon-reload y actualiza ssh.socket. Compruébalo con sudo ss -tlnp | grep sshd: la guía sobre cómo comprobar los puertos abiertos en Linux explica la salida. Si sshd sigue empeñado en el 22, desactiva la activación por socket y deja que el servicio enlace el puerto por sí mismo: sudo systemctl disable --now ssh.socket && sudo systemctl enable --now ssh.service. Cuando ssh -p 2222 funcione desde una terminal nueva, ejecuta sudo ufw delete allow OpenSSH.
Añade fail2ban y valora la autenticación de dos factores
Con las contraseñas desactivadas la fuerza bruta no puede tener éxito, pero cada intento sigue costando un proceso y una línea de registro. fail2ban vigila el registro de autenticación y banea las direcciones que fallan repetidamente:
sudo apt install -y fail2ban
sudo nano /etc/fail2ban/jail.localPon esto en el archivo:
[sshd]
enabled = true
port = ssh
backend = systemd
maxretry = 5
findtime = 10m
bantime = 1hsudo systemctl enable --now fail2ban
sudo fail2ban-client status sshdNunca edites jail.conf; se reemplaza en las actualizaciones y jail.local lo sobrescribe. port = ssh se resuelve a través de /etc/services, así que escribe port = 2222 si moviste el demonio. backend = systemd lee el journal directamente y funciona escriba o no tu imagen en /var/log/auth.log. fail2ban-client status sshd lista las direcciones baneadas; sudo fail2ban-client set sshd unbanip 203.0.113.7 libera una. Por defecto, las reglas de fail2ban se evalúan antes que las de UFW, así que ambos conviven.
Autenticación de dos factores
Cuando una clave con frase de contraseña no basta, libpam-google-authenticator añade un código temporal por encima de la clave: instálalo, ejecuta google-authenticator como el usuario de acceso, añade auth required pam_google_authenticator.so a /etc/pam.d/sshd (y comenta su línea @include common-auth), y luego define KbdInteractiveAuthentication yes y AuthenticationMethods publickey,keyboard-interactive en sshd. Una ganancia real frente a un portátil robado, y una cosa más que perder: guarda los códigos de emergencia fuera del servidor.
Resolución de problemas: conexión rechazada, agotada o permiso denegado
Connection refused
El servidor respondió pero nada escucha en ese puerto: sshd está detenido, enlazado en otro sitio o has escrito el puerto equivocado. Desde la consola del proveedor, ejecuta systemctl status ssh y sudo ss -tlnp | grep ssh. Un error de sintaxis impide que sshd arranque siquiera; sudo sshd -t muestra la línea culpable y journalctl -u ssh -n 50 enseña el último arranque.
Connection timed out
Los paquetes se descartan en lugar de rechazarse, lo que casi siempre significa un firewall: UFW sin la regla de permiso (sudo ufw status verbose), un grupo de seguridad en el panel del proveedor o tu propia red bloqueando el 22 saliente; probar desde el punto de acceso del móvil lo descarta. ssh -v username@SERVER_IP muestra dónde se atasca el handshake.
Permission denied (publickey)
El servidor es accesible y te está rechazando. Comprueba, por orden: el nombre de usuario, si el archivo authorized_keys de ese usuario contiene la clave que ofreces (ssh -i ~/.ssh/id_ed25519 -v fuerza una clave concreta), los permisos de ~/.ssh y si el usuario falta en AllowUsers. En el servidor, journalctl -u ssh -n 30 indica el motivo; Authentication refused: bad ownership or modes es el problema de permisos descrito antes.
Aviso de clave de host
WARNING: REMOTE HOST IDENTIFICATION HAS CHANGED tras una reinstalación es lo esperado: ejecuta ssh-keygen -R SERVER_IP y vuelve a conectar. Si no has reinstalado nada, averigua por qué antes de escribir una contraseña en ningún sitio. ¿Sin acceso por completo? La consola del proveedor es la vía de regreso.
Todo lo anterior asume una máquina en la que tienes root y puedes permitirte romper sshd y repararlo desde una consola. Un VPS Linux de rdp.monster es exactamente esa máquina: acceso root completo, CPU y RAM dedicadas, ancho de banda ilimitado (uso razonable), sin KYC, pago en cripto o fiat, desde 8,99 $ al mes, y el servidor está en línea unos 10 segundos después de la confirmación del pago, tiempo de sobra para tener las claves colocadas antes de que el primer escáner encuentre el puerto 22.
Preguntas frecuentes
¿Ubuntu viene con SSH activado por defecto?
sudo apt install openssh-server. Ubuntu Server pregunta durante la instalación si quieres instalar el servidor OpenSSH y puede importar al mismo tiempo tus claves de GitHub o Launchpad. Las imágenes de nube y de VPS casi siempre traen openssh-server instalado, habilitado y aceptando conexiones, porque es la única forma que tiene el proveedor de entregarte la máquina. Compruébalo con systemctl status ssh.¿Cómo compruebo si SSH está funcionando en Ubuntu?
systemctl status ssh te dice si el servicio está activo o habilitado. Como Ubuntu 22.10 y posteriores usan activación por socket, el servicio puede mostrar legítimamente inactive (dead) con TriggeredBy: ssh.socket cuando nadie está conectado, así que la prueba más fiable es sudo ss -tlnp | grep ssh: una línea con 0.0.0.0:22 o [::]:22 significa que SSH está escuchando. Desde otra máquina, ssh -v username@SERVER_IP lo confirma de extremo a extremo.¿Es seguro dejar SSH en el puerto 22?
PasswordAuthentication no y un par de claves, y fail2ban elimina buena parte del ruido. Mover sshd al 2222 o al 22222 solo lo oculta de los escáneres más perezosos; escáneres de puertos como nmap y masscan lo encuentran en minutos, y los índices de internet lo listan igualmente. Trata un puerto no estándar como una medida de higiene de registros, no como un control de seguridad, y nunca prescindas de las claves porque hayas cambiado el puerto.¿Cuál es la diferencia entre ssh y sshd en Ubuntu?
ssh es el cliente que ejecutas en tu portátil para abrir una conexión; viene del paquete openssh-client. sshd es el demonio que responde en el servidor, del paquete openssh-server, configurado en /etc/ssh/sshd_config (el cliente lee ssh_config). Ubuntu y Debian llaman a la unidad de systemd ssh.service y declaran sshd.service como alias, de modo que systemctl restart ssh y systemctl restart sshd hacen lo mismo; en Fedora, RHEL y Arch la unidad es simplemente sshd.
