Publicada enLINUX

SSH server en Linux: instala configura OpenSSH de forma segura

No hay comentarios
ssh-server
ssh-server

Un SSH server en Linux permite acceder de forma remota y segura a un sistema desde otro equipo usando la terminal. Gracias a OpenSSH, es posible administrar servidores, ejecutar comandos, transferir archivos y gestionar servicios sin necesidad de estar físicamente delante de la máquina.

En este artículo veremos cómo instalar y configurar un SSH server en Linux usando OpenSSH. También repasaremos cómo comprobar el estado del servicio, habilitarlo al inicio del sistema y aplicar recomendaciones básicas de seguridad para reducir riesgos en conexiones remotas.

👉 Y recuerda, si quieres aprender más de Linux, pincha en este curso de Linux gratis

👉 También te dejo por aquí una guía de comandos Linux por categorías

Qué es “SSH server” (cliente vs servidor)

Cuando hablamos de SSH hay dos piezas:

  • Cliente SSH: el comando ssh que ejecutas desde tu PC/portátil u otro servidor.
  • SSH server: el demonio sshd que corre en la máquina destino y acepta conexiones entrantes.

En muchas distribuciones el cliente viene instalado por defecto, pero el servidor no siempre.

Comprobar si el SSH server está instalado

Según la distribución, puedes comprobarlo así:

Debian / Ubuntu

dpkg -l | grep openssh-server || true

Fedora / RHEL y derivadas

rpm -qa | grep openssh-server || true

Instalar OpenSSH Server

Debian / Ubuntu

sudo apt update
sudo apt install openssh-server

Fedora / RHEL / CentOS / Rocky / Alma

sudo dnf install openssh-server

Arch Linux

sudo pacman -S openssh

Tras instalar, el servicio suele quedar listo para arrancar.

Arrancar y habilitar el servicio (systemd)

En la mayoría de sistemas modernos, el servicio se llama ssh o sshd.

Habilitar y arrancar (ahora y al inicio)

sudo systemctl enable --now ssh || sudo systemctl enable --now sshd

Ver estado y diagnosticar rápido

systemctl status ssh --no-pager || systemctl status sshd --no-pager

Confirmar que escucha (puerto 22 por defecto)

sudo ss -tulpn | grep sshd

Si no aparece nada escuchando, normalmente el servicio no está activo o falló al arrancar.

Abrir el puerto en el firewall (si aplica)

Si tu servidor tiene firewall activo, necesitas permitir el puerto de SSH desde las IPs necesarias.

UFW (Ubuntu/Debian)

sudo ufw allow OpenSSH
sudo ufw status

firewalld (Fedora/RHEL)

sudo firewall-cmd --permanent --add-service=ssh
sudo firewall-cmd --reload
sudo firewall-cmd --list-services

Si más adelante cambias el puerto de SSH, no olvides ajustar también las reglas del firewall.

Primer acceso y verificación (huella + logs)

Con el servidor escuchando, prueba desde el cliente:

ssh usuario@IP_O_HOSTNAME

La primera conexión te pedirá confirmar la huella (host key). Ese aviso es normal: sirve para detectar ataques tipo “man-in-the-middle”. Idealmente, valida la huella por un canal alternativo (consola del proveedor, acceso físico, panel de tu VPS, etc.).

Revisar logs del servidor cuando algo falla

sudo journalctl -u ssh -n 100 --no-pager || sudo journalctl -u sshd -n 100 --no-pager

Configuración principal: sshd_config

El archivo típico de configuración del servidor SSH es /etc/ssh/sshd_config. Antes de cambiar nada, aplica estas tres reglas básicas.

1) Haz copia de seguridad

sudo cp /etc/ssh/sshd_config /etc/ssh/sshd_config.bak

2) Valida la sintaxis antes de reiniciar

sudo sshd -t

Si sshd -t devuelve error, corrígelo antes de reiniciar.

3) Reinicia el servicio de forma segura

Si estás conectado por SSH, deja otra sesión abierta por si algo sale mal (o ten consola out-of-band).

sudo systemctl restart ssh || sudo systemctl restart sshd

Autenticación por clave pública (recomendado)

El mayor salto de seguridad suele ser pasar de contraseñas a claves SSH.

Generar una clave en el cliente (ed25519)

ssh-keygen -t ed25519 -a 64

Esto crea una clave privada (no se comparte) y una pública (se copia al servidor).

Copiar la clave al servidor (forma sencilla)

ssh-copy-id usuario@IP_O_HOSTNAME

Copia manual (cuando no tienes ssh-copy-id)

En el servidor:

mkdir -p ~/.ssh
chmod 700 ~/.ssh
touch ~/.ssh/authorized_keys
chmod 600 ~/.ssh/authorized_keys

Luego añade el contenido de tu clave pública (del cliente) dentro del archivo ~/.ssh/authorized_keys (en el servidor).

Hardening esencial para un SSH server

La seguridad de SSH no es un único ajuste: es un conjunto de decisiones razonables para tu entorno. Estos son los cambios más típicos (y útiles) para endurecer un SSH servidor.

Deshabilitar el login directo de root

En /etc/ssh/sshd_config:

PermitRootLogin no

La idea es entrar con un usuario normal y escalar con sudo.

Usar solo claves (deshabilitar contraseñas)

Cuando confirmes que tu acceso por clave funciona:

PasswordAuthentication no
KbdInteractiveAuthentication no

En algunas distribuciones aparece ChallengeResponseAuthentication; si existe, ponlo en no.

Limitar quién puede entrar (usuarios o grupos)

Por usuarios:

AllowUsers admin deploy

O por grupos:

AllowGroups sshusers

Cambiar el puerto (opcional)

No es “seguridad fuerte”, pero reduce mucho ruido de bots.

Port 2222

Recuerda ajustar:

  • El firewall
  • El cliente (por ejemplo, indicando el puerto al conectar)
ssh -p 2222 usuario@host

Desactivar opciones que no uses

Ejemplo típico:

X11Forwarding no
PermitEmptyPasswords no

Si no necesitas túneles/forwarding:

AllowTcpForwarding no

Límites y timeouts básicos contra fuerza bruta

LoginGraceTime 30
MaxAuthTries 3
MaxSessions 5
ClientAliveInterval 300
ClientAliveCountMax 2

Fail2ban (bloqueo por intentos fallidos)

En Debian/Ubuntu:

sudo apt install fail2ban
sudo systemctl enable --now fail2ban

Es especialmente útil si, por política o por compatibilidad, no puedes desactivar contraseñas todavía.

MFA/2FA (avanzado)

Puedes añadir 2FA con PAM + TOTP, pero requiere más cuidado para no bloquearte. Es una buena capa extra en servidores críticos.

Buenas prácticas operativas

Mantén un acceso alternativo por si te bloqueas

Ten a mano consola del proveedor, KVM/IPMI, acceso físico o snapshots/rollback. En SSH, un cambio mal aplicado puede dejarte sin entrada.

Usa usuarios dedicados y mínimos privilegios

Por ejemplo, un usuario deploy solo para despliegues y otro admin para administración.

Documenta cambios y actualiza OpenSSH

Anota qué cambiaste en sshd_config y por qué. Mantener el sistema actualizado reduce exposición a vulnerabilidades conocidas.

Simplifica conexiones con ~/.ssh/config

En tu cliente puedes definir host, usuario, puerto y clave para no repetirlo siempre:

Host mi-servidor
  HostName 203.0.113.10
  User admin
  Port 2222
  IdentityFile ~/.ssh/id_ed25519

Túneles SSH (port forwarding): cuándo y cómo

Un SSH servidor también permite crear túneles cifrados para acceder a servicios internos sin exponerlos.

Forward local (traer un puerto remoto a tu máquina)

Ejemplo: base de datos en el servidor (puerto 5432) accesible como localhost:15432 en tu equipo:

ssh -L 15432:127.0.0.1:5432 usuario@servidor

Forward remoto (exponer un puerto de tu cliente en el servidor)

ssh -R 18080:127.0.0.1:8080 usuario@servidor

Si no necesitas túneles, considera desactivar el forwarding o permitirlo solo para ciertos usuarios (por ejemplo con bloques Match en sshd_config).

Errores comunes y troubleshooting (checklist)

Aquí tienes un checklist rápido para los errores que más se repiten en SSH servidor.

“Connection refused”

Suele significar que no hay nada escuchando en ese puerto o que un firewall lo bloquea.

systemctl status ssh --no-pager || systemctl status sshd --no-pager
sudo ss -tulpn | grep sshd

Revisa también reglas de firewall (por ejemplo, el estado de UFW o firewalld) y, si cambiaste puerto, que estés conectando con el parámetro correcto.

“Permission denied (publickey)” o “Permission denied (password)”

Checklist típico:

  • Usuario equivocado (en SSH, el usuario importa).
  • Permisos incorrectos en la carpeta ~/.ssh o en authorized_keys.
  • Clave pública mal copiada (con saltos de línea raros o duplicada).

Permisos recomendados en el servidor:

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

Logs:

sudo journalctl -u sshd -n 200 --no-pager || sudo journalctl -u ssh -n 200 --no-pager

“REMOTE HOST IDENTIFICATION HAS CHANGED!”

Puede ser un ataque… o un cambio legítimo (reinstalación, IP reutilizada, regeneración de claves del host). Valida primero el motivo.

Si confirmas que el cambio es legítimo, en el cliente:

ssh-keygen -R hostname_o_ip

Luego reconecta y confirma la nueva huella.

sshd no arranca tras cambiar sshd_config

Valida la sintaxis:

sudo sshd -t

Y revisa el motivo exacto:

sudo journalctl -u sshd -xe --no-pager || sudo journalctl -u ssh -xe --no-pager

SELinux bloquea un puerto no estándar (RHEL/Fedora)

Si cambias el puerto de SSH y SELinux está en modo enforcing, puede que necesites autorizarlo:

sudo semanage port -a -t ssh_port_t -p tcp 2222

Si semanage no existe, suele faltar el paquete policycoreutils-python-utils (o equivalente en tu distribución).

Conclusión

Configurar un SSH server en Linux es una tarea esencial para administrar sistemas de forma remota. Con OpenSSH, podemos habilitar conexiones seguras, controlar el acceso de usuarios y gestionar servidores de manera eficiente desde la terminal.

Además de instalar el servicio, es importante revisar opciones de seguridad como el puerto de escucha, el acceso por contraseña, el uso de claves SSH y la configuración del archivo sshd_config. Dominar estos conceptos permite trabajar con servidores Linux de forma más segura, ordenada y profesional.

Referencias recomendadas

🔗 Referencia oficial: Manual de sshd_config (OpenSSH) — man.openbsd.org

Comentarios

No hay comentarios aún. ¿Por qué no comienzas el debate?

Deja una respuesta

Tu dirección de correo electrónico no será publicada. Los campos obligatorios están marcados con *