Configuración de OpenSSH

Autor: Joel Barrios Dueñas
Correo electrónico: darkshram en gmail punto com
Sitio de Red: https://www.alcancelibre.org

Licencia Creative Commons
© 1999-2026 Joel Barrios Dueñas. Este manual se distribuye bajo la licencia Creative Commons Reconocimiento-NoComercial-CompartirIgual 4.0 Internacional (CC BY-NC-SA 4.0). Usted es libre de compartir y adaptar el material bajo los siguientes términos: debe dar crédito al autor, no puede utilizarlo para fines comerciales y debe compartir las obras derivadas bajo la misma licencia. La licencia completa está disponible en https://creativecommons.org/licenses/by-nc-sa/4.0/legalcode.es.

Introducción

OpenSSH es una solección de herramientas de conectividad esencial para la administración segura de sistemas en red. Proporciona los canales cifrados que permiten el acceso remoto confiable, la ejecución de mandatos y la transferencia de archivos, sustituyendo a protocolos heredados inseguros como Telnet o FTP. Comprender sus componentes fundamentales —SSH, SFTP y SCP— es el primer paso para implementar y gestionar estas conexiones con criterios de seguridad sólidos.

¿Qué es SSH?

SSH (Secure Shell) es un conjunto de estándares y un protocolo de red que permite establecer una comunicación a través de un canal seguro entre un cliente local y un servidor remoto. Utiliza criptografía de llave pública para autenticar el servidor remoto y, de modo opcional, permitir al servidor autenticar al usuario. SSH provee confidencialidad e integridad en la transferencia de datos mediante cifrado y MAC (Message Authentication Codes o Códigos de Autenticación de Mensaje). De modo predeterminado, escucha peticiones a través del puerto 22 por TCP.

¿Qué es SFTP?

SFTP (SSH File Transfer Protocol) es un protocolo que provee funcionalidad para la transferencia y manipulación de archivos a través de un flujo confiable de datos. Se utiliza comúnmente con SSH para ofrecer transferencia segura de archivos. SFTP ha ido sustituyendo gradualmente a los protocolos FTP y FTPS debido a su seguridad superior (cifrado integral de la conexión) y su simplicidad (utiliza un solo puerto).

¿Qué es SCP?

SCP (Secure Copy o Copia Segura) es un protocolo seguro para transferir archivos entre un anfitrión local y otro remoto a través de SSH. Básicamente, es idéntico a RCP (Remote Copy), con la diferencia crucial de que los datos se cifran durante la transferencia, lo que impide la extracción potencial de información mediante programas de captura de tramas de red (packet sniffers). SCP sólo implementa la transferencia de archivos, delegando toda la autenticación a SSH.

¿Qué es OpenSSH?

OpenSSH (Open Secure Shell) es la implementación de código fuente abierto del protocolo SSH, publicada bajo una licencia tipo BSD. Es desarrollada por el equipo de OpenBSD y se considera muy segura gracias a la auditoría constante de su código por parte de una amplia comunidad, una ventaja inherente del software libre. OpenSSH incluye el servicio (daemon) y los clientes para los protocolos SSH, SFTP y SCP.

Equipamiento lógico necesario y actualización

Las instalaciones mínimas de las distribuciones modernas (AlmaLinux, Rocky Linux, Red Hat Enterprise Linux y ALDOS) incluyen el cliente openssh de modo predeterminado. El servidor openssh-server también suele estar presente. En lugar de una instalación, se recomienda verificar y aplicar actualizaciones de seguridad para estos paquetes, dada la crítica importancia del protocolo.

Ejecute lo siguiente según su distribución:

Si tras la actualización algún paquete carecía de instalación previa, el gestor lo instalará de modo automático.

Gestión del servicio sshd

A continuación se presentan los mandatos para gestionar el servicio sshd, diferenciando entre sistemas que utilizan Systemd (distribuciones modernas) y SysVinit (como ALDOS).

Con Systemd (AlmaLinux, Rocky Linux, RHEL)

Acción Mandato
Habilitar al inicio systemctl enable sshd
Iniciar ahora systemctl start sshd
Reiniciar (aplica config) systemctl restart sshd
Ver estado systemctl status sshd
Deshabilitar systemctl disable sshd
Detener systemctl stop sshd

Con SysVinit (ALDOS)

Acción Mandato
Habilitar al inicio chkconfig sshd on
Iniciar ahora service sshd start
Reiniciar (aplica config) service sshd restart
Ver estado service sshd status
Deshabilitar chkconfig sshd off
Detener service sshd stop

Modificaciones necesarias en el muro cortafuegos

Es indispensable abrir el puerto TCP que utilizará el servicio SSH (por defecto, el 22) en el muro cortafuegos.

firewall-cmd --add-service=ssh --permanent
firewall-cmd --reload

SELinux y el servicio sshd

AlmaLinux o Red Hat™ Enterprise Linux incluyen políticas de seguridad específicas para el servicio sshd.

Puerto distinto al predeterminado (22)

Si configura el servicio para utilizar un puerto distinto al 22, debe autorizar ese puerto en la política de SELinux. En el siguiente ejemplo se permite el puerto 52341:

semanage port -a -t ssh_port_t -p tcp 52341

Recuerde abrir también este puerto personalizado en el muro cortafuegos:

firewall-cmd --add-port=52341/tcp --permanent
firewall-cmd --reload

🔄 Rotación periódica del puerto (Opcional avanzado): Para entornos de seguridad elevada o que sufran escaneos constantes, algunos administradores implementan una rotación programada del puerto SSH. Esto implica cambiar el valor de Port en sshd_config y la regla del muro cortafuegos en un intervalo predefinido (ej: trimestral). Si bien esta práctica incrementa la ofuscación, también complica la operativa (hay que actualizar configuraciones en clientes, guiones de automatización, documentación). Considere este enfoque sólo si los beneficios superan la carga administrativa adicional y jamás como sustituto de la autenticación por clave, listas de control de acceso (AllowUsers) y sistemas de detección de intrusos.

Políticas booleanas de SELinux relevantes

Política Descripción y Valor Predeterminado Mandato para Habilitar
ssh_chroot_rw_homedirs Habilita permisos de lectura y escritura en directorios de inicio para usuarios con chroot (jaula). Valor predeterminado: 0 (deshabilitado). setsebool -P ssh_chroot_rw_homedirs 1
fenced_can_ssh Permite a usuarios con chroot ingresar mediante SSH (además de SFTP). Se recomienda evitar su uso. Valor predeterminado: 0. setsebool -P fenced_can_ssh 1
ssh_sysadm_login Permite el acceso a usuarios con el rol de administrador de sistema (contexto sysadm_t). Valor predeterminado: 0. setsebool -P ssh_sysadm_login 1
allow_ssh_keysign Habilita el uso de firmas digitales para autenticación. Valor predeterminado: 0. Es necesario para el método descrito en el manual de autenticación por clave pública. setsebool -P allow_ssh_keysign 1

Contexto ssh_home_t

El contexto de SELinux para los directorios ~/.ssh —y todo su contenido— debe ser ssh_home_t. Reasigne los contextos ejecutando:

restorecon -Rv /root/.ssh /home/*/.ssh

Archivos de configuración clave

Archivo Propósito
/etc/ssh/sshd_config Archivo principal de configuración del servidor SSH.
/etc/ssh/ssh_config Archivo de configuración global para los clientes SSH del sistema.
~/.ssh/config Archivo de configuración personal para cada usuario. Tiene precedencia sobre el archivo global /etc/ssh/ssh_config.
~/.ssh/known_hosts Almacena las «huellas digitales» de las llaves de los servidores a los que el usuario se ha conectado, para verificar su identidad en futuras conexiones.
~/.ssh/authorized_keys Almacena las llaves públicas de los clientes autorizados para conectarse a este servidor con la cuenta del usuario, permitiendo la autenticación sin contraseña.

Cuando se utilizan cuentas con acceso al intérprete de mandatos, el orden de precedencia es: 1) opciones en la intérprete de mandatos de ssh, 2) archivo ~/.ssh/config, 3) archivo /etc/ssh/ssh_config.

Gestionar advertencias de clave cambiada (known_hosts)

Si reinstala su servidor o cambia sustancialmente su software SSH, los clientes mostrarán una advertencia indicando que la clave del anfitrión ha cambiado. Una vez que haya verificado la legitimidad del nuevo servidor, puede eliminar la entrada antigua de forma segura con:

ssh-keygen -R nombre.o.ip.del.servidor

El próximo intento de conexión añadirá la nueva clave de modo automático.

Clientes SSH y SFTP recomendados

Para conectarse a un servidor OpenSSH necesitará un cliente. La siguiente lista incluye opciones de software libre para distintos sistemas operativos.

Cliente Sistema Operativo Protocolos Soportados Nota / Recomendación
Cliente OpenSSH (ssh, sftp) Linux, macOS, Windows (WSL) SSH, SFTP, SCP Incluido de serie. El más directo, universal y utilizado por administradores.
FileZilla Windows, macOS, Linux SFTP, FTP, FTPS GPL. Cliente gráfico muy popular y recomendado para transferencias SFTP. Descargar FileZilla.
PuTTY Windows, Linux SSH, Telnet, SFTP (con psftp) MIT. Clásico cliente terminal. En Linux está disponible, pero su uso es minoritario. Descargar PuTTY.
Remmina Linux SSH, SFTP, RDP, VNC GPL. Cliente gráfico predilecto en muchos entornos Linux (ej: GNOME). Es extensible y amigable.
WinSCP Windows SFTP, SCP, FTP, WebDAV GPL. Excelente integración con el entorno Windows y PuTTY.
Cyberduck Windows, macOS SFTP, WebDAV, Almacenamiento cloud GPL. Alternativa sólida para macOS y Windows.

Procedimientos de configuración del servidor

Edite el archivo principal de configuración del servidor:

vim /etc/ssh/sshd_config

A continuación se analizan las opciones básicas que se recomienda modificar.

Opción Port

Port 22

Una forma de elevar la seguridad del servicio consiste en cambiar el número de puerto predeterminado. A este tipo de técnicas se les conoce como Seguridad por Oscuridad. La mayoría de los ataques automatizados buscan servidores en el puerto 22. Cambiarlo reduce el ruido de estos intentos. Por ejemplo, para usar el puerto 52341:

Port 52341

⚠️ Nota de seguridad realista: Cambiar el puerto predeterminado es una capa de defensa básica que detiene ataques automatizados no dirigidos. Sin embargo, jamás constituye una protección suficiente por sí sola. Esta medida debe combinarse siempre con otras como: deshabilitar PermitRootLogin, usar autenticación por clave pública, emplear AllowUsers para restringir acceso e implementar herramientas como Fail2Ban.

Opción ListenAddress

De modo predeterminado el servicio escucha en todas las interfaces de red. Puede restringirse a una dirección IP específica. Por ejemplo, para escuchar sólo en la IP local 192.168.1.254:

ListenAddress 192.168.1.254

Opción PermitRootLogin

Establece si se permite el ingreso directo del usuario root. Es una medida de seguridad crítica. Se recomienda deshabilitarlo y acceder primero con una cuenta de usuario normal, usando sudo para tareas privilegiadas.

PermitRootLogin no

Opción PasswordAuthentication

Habilita o deshabilita la autenticación con contraseñas. Se recomienda deshabilitarla sólo después de haber configurado e probado exitosamente la autenticación por llave pública.

PasswordAuthentication yes

Opción X11Forwarding

Permite la ejecución remota de aplicaciones gráficas (X11). Puede ser útil para tareas administrativas específicas.

X11Forwarding yes

Opción AllowUsers

Permite restringir el acceso al servidor SSH por usuario y/o por dirección IP de origen. Ejemplo para permitir sólo a los usuarios fulano y mengano desde cualquier lugar:

AllowUsers fulano mengano

Ejemplo para restringirlos a conexiones desde las direcciones IP 10.1.1.1 y 10.2.2.1:

AllowUsers fulano@10.1.1.1 mengano@10.1.1.1 fulano@10.2.2.1 mengano@10.2.2.1

Opción UseDNS

Cuando un cliente se conecta, el servidor intenta resolver la dirección IP del cliente a un nombre de dominio. En redes sin un servidor DNS interno adecuado, esto puede retrasar la conexión. Algunos administradores la desactivan para agilizar las conexiones.

UseDNS no

Nota de seguridad: El cliente SSH tiene una opción CheckHostIP (activada por defecto) que ayuda a detectar suplantaciones de identidad (spoofing) de DNS. Desactivar UseDNS en el servidor elimina una capa de verificación. Se recomienda dejarla en yes salvo que cause problemas reales de rendimiento en un entorno controlado.

Probando la conexión y uso

Es importante realizar comprobaciones del servicio antes de poner en marcha en entornos productivos.

🔍 Identificación del servicio y versión

Un método rápido para verificar que el servicio SSH está escuchando y conocer su versión (información que, por seguridad, se recomienda ocultar) es utilizar una herramienta como ncat (de Nmap) o telnet para conectarse al puerto. Esto resulta útil para diagnósticos o para confirmar que un cambio de puerto ha surtido efecto.

ncat servidor.ejemplo.com 22

La salida mostrará la cadena de identificación del servidor, similar a:

SSH-2.0-OpenSSH_8.7p1

Nota sobre seguridad: Exponer la versión exacta del software puede facilitar a un atacante la búsqueda de vulnerabilidades específicas. Se recomienda combinar la directiva ServerTokens (si se usa un intermediario como Apache) con las prácticas de hardening generales. Esta técnica es principalmente una herramienta de diagnóstico para el administrador.

Acceso con intérprete de mandatos desde Linux/macOS

ssh usuario@nombre.o.ip.servidor

Si el servidor utiliza un puerto distinto al 22, utilice la opción -p:

ssh -p 52341 juan@192.168.100.15

Transferencia de archivos con SFTP

Para una sesión interactiva de transferencia de archivos:

sftp usuario@servidor

Para un puerto personalizado:

sftp -o Port=52341 juan@192.168.100.15

Ejemplo de sesión SFTP con salida realista:

[usuario@cliente ~]$ sftp curso@192.168.100.15
Conectado a 192.168.100.15.
sftp> pwd
Directorio remoto: /home/curso
sftp> ls -la
drwxr-xr-x    6 curso    curso        4096 22 Dec 18:30 .
drwxr-xr-x    4 root     root         4096 15 Mar  2025 ..
-rw-------    1 curso    curso        1243 22 Dec 17:45 .bash_history
-rw-r--r--    1 curso    curso          18 22 Dec 10:22 .bash_logout
-rw-r--r--    1 curso    curso         193 22 Dec 10:22 .bash_profile
-rw-r--r--    1 curso    curso         231 22 Dec 10:22 .bashrc
drwxr-xr-x    3 curso    curso        4096 22 Dec 15:10 public_html
sftp>

Los entornos de escritorio como GNOME (con Nautilus/Files) o KDE (con Dolphin) permiten acceder a servidores SFTP directamente desde el administrador de archivos escribiendo sftp://usuario@servidor en la barra de direcciones.

Jaulas (chroot) para usuarios SFTP

Configurar una jaula (chroot) para usuarios de SFTP es una práctica de seguridad excelente, especialmente en entornos de hosting o educativos. Limita el acceso del usuario únicamente a su directorio de inicio, impidiendo que exploren el sistema de archivos del servidor. Esto es ideal para usuarios que sólo necesitan administrar archivos de servidor web, como en sitios construidos con WordPress o Grav CMS, debido a que se puede configurar Nginx para servir contenidos desde su directorio ~/public_html.

  1. Edite /etc/ssh/sshd_config y reemplace (o comente) la línea del subsistema SFTP por la siguiente configuración:

    #Subsystem   sftp    /usr/libexec/openssh/sftp-server
    Subsystem    sftp    internal-sftp
    Match Group sftpusers
        ChrootDirectory %h
        ForceCommand internal-sftp
        AllowTcpForwarding no
  2. Reinicie el servicio sshd con systemctl restart sshd o service sshd restart.

  3. Cree el grupo sftpusers y añada usuarios a él:

    groupadd sftpusers
    usermod -G sftpusers nombreyapellido
  4. Ajuste permisos y propiedad del directorio de inicio del usuario. La propiedad debe ser root:root para que el chroot funcione, pero dentro puede crear subdirectorios para el usuario:

    chown root:root /home/nombreyapellido
    chmod 755 /home/nombreyapellido
    mkdir -p -m 0755 /home/nombreyapellido/{public_html,private,.ssh}
    chown nombreyapellido:nombreyapellido /home/nombreyapellido/{public_html,private,.ssh}

    🔒 Nota de seguridad crítica: Propiedad root del directorio de chroot Es indispensable que el directorio utilizado para la jaula (/home/nombreyapellido) pertenezca a root:root. Este requisito lo impone el servicio sshd por una razón fundamental: si el directorio fuera propiedad del usuario, éste podría —en teoría— manipularlo (incluso eliminarlo), comprometiendo la integridad de la jaula y arriesgando una «fuga» hacia el directorio raíz (/) del sistema. Configurar la pertenencia a root garantiza que el punto de anclaje de la jaula sea inmutable para el usuario enjaulado, manteniendo así el confinamiento seguro.

  5. Cambie el intérprete de mandatos del usuario a /sbin/nologin para impedir el acceso por SSH convencional:

    usermod -s /sbin/nologin nombreyapellido

Resultado: El usuario nombreyapellido podrá conectarse vía SFTP (por ejemplo, con FileZilla) y sólo verá su directorio / (que en realidad es /home/nombreyapellido/). Podrá subir archivos a public_html u otros subdirectorios creados.

Alternativa Avanzada: Jailkit

Para jaulas chroot más complejas que requieran incluir bibliotecas o comandos específicos, existe una herramienta especializada llamada Jailkit. Es un conjunto de utilidades que facilita la creación y gestión de jaulas de seguridad más sofisticadas. Si bien es una herramienta potente y estable utilizada en entornos de alta seguridad, está ausente en los almacenes de sóftware oficiales base de las distribuciones (como EPEL o Remi). Su instalación y configuración detallada escapan al alcance de este manual introductorio.

Transferencia de archivos con SCP

Para copiar archivos de forma segura:

Conclusión y siguiente paso

Ha configurado un servidor OpenSSH con medidas de seguridad básicas como cambiar el puerto predeterminado, deshabilitar el acceso directo a root y configurar jaulas SFTP. Recuerde que la seguridad es un proceso en capas.

El siguiente paso natural es eliminar por completo la dependencia de las contraseñas configurando la autenticación mediante firma digital (clave pública). Continúe con el manual dedicado a este tema: OpenSSH con autenticación a través de firma digital