Prácticas recomendadas de seguridad de Open SSH

Aunque Open SSH se ha convertido en la norma en lo que respecta al acceso remoto, utilizar su instalación predeterminada sigue implicando algunos riesgos de seguridad. Esta guía propone formas de aumentar considerablemente el nivel de seguridad de una instalación de Open SSH.

Utilizar autenticación con claves privadas/públicas

Utilizar claves cifradas para la autenticación resulta útil, ya que elimina la necesidad de introducir contraseñas. Ni los hackers más ingeniosos podrán interferir o colarse en una sesión, y no habrá más intentos de descifrar contraseñas.

1. Genere un par de claves pública/privada con este comando: $ ssh-keygen -t rsa. Esto crea dos ficheros en el directorio (oculto) ~/.ssh; la clave privada se llama id_rsa y la pública id_rsa.pub.
2. Elija una contraseña que se utilizará para desbloquear la clave pública en cada conexión. Opcionalmente, se puede añadir un cifrado protegido con una frase de contraseña al crear la clave.

   También funciona pulsar Enter sin introducir una frase de contraseña. Tenga en cuenta, sin embargo, que crear una clave sin frase de contraseña otorga automáticamente acceso SSH al servidor remoto a cualquiera que consiga acceso a su máquina local.
3. Copie la clave pública (id_rsa.pub) al servidor:

   Scp –p id_rsa.pub remoteuser@remotehost:
   ```   <div data-gb-custom-block data-tag="hint" data-style='danger'>The `remoteuser` should never be root. Select the default non-root user as `remoteuser` instead.</div>

4. Inicie sesión con SSH y copie la clave pública en el lugar adecuado:

   ssh remoteuser@remotehost mkdir ~/.ssh chmod 700 ~/.ssh cat id_rsa.pub >> ~/.ssh/authorized_keys chmod 600 ~/.ssh/authorized_keys mv id_rsa.pub ~/.ssh logout

5. A continuación, elimine la clave pública del servidor; de lo contrario, el cliente SSH no permite iniciar sesión en el servidor:

   rm id_rsa.pub

6. Establezca los permisos de fichero en el servidor (estos dos son necesarios si "StrictModes" está configurado como yes):

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

7. Una vez que haya iniciado sesión utilizando la frase de contraseña de la clave, se puede desactivar por completo la autenticación con contraseña. Para ello, abra el fichero /etc/ssh/sshd_config y añada las siguientes líneas:

   # Disable password authentication forcing use of keys
   PasswordAuthentication no

Desactivar la autenticación con nombre de usuario y contraseña

Para eliminar por completo la autenticación basada en contraseñas y forzar el uso de claves o certificados SSH, actualice la configuración de SSH añadiendo las siguientes líneas en el fichero /etc/ssh/sshd_config:

PasswordAuthentication no
ChallengeResponseAuthentication no
KbdInteractiveAuthentication no
UsePAM no

A continuación, reinicie el servicio SSHD introduciendo /etc/init.d/sshd restart o service sshd restart. Una vez hecho esto, el servidor debería rechazar todos los inicios de sesión con nombre de usuario/contraseña y aceptar únicamente la autenticación mediante clave o certificado.

Configurar el intervalo de tiempo de inactividad

Se puede establecer un intervalo de tiempo de inactividad para evitar tener una sesión SSH desatendida. Para ello, abra el fichero /etc/ssh/sshd_config y añada la siguiente línea:

ClientAliveInterval 360
ClientAliveCountMax 0

El intervalo de tiempo de inactividad se expresa en segundos (360 segundos = 6 minutos). Una vez transcurrido el intervalo, los usuarios inactivos se desconectan automáticamente.

Desactivar las contraseñas vacías

Para mayor seguridad, se recomiendaimpedir los inicios de sesión remotos desde cuentas con contraseñas vacías. Abra el fichero /etc/ssh/sshd_config y actualice la siguiente línea:

PermitEmptyPasswords no

Limitar el acceso SSH a unos pocos usuarios

En los casos en los que no se pueda evitar la autenticación con nombre de usuario/contraseña, se recomienda limitar el inicio de sesión SSH únicamente a determinados usuarios que necesiten acceso remoto, minimizando así el impacto de los usuarios con contraseñas débiles.

Para limitar el inicio de sesión SSH, abra el fichero /etc/ssh/sshd_config y añada una línea AllowUsers, seguida de la lista de nombres de usuario separados por espacios:

AllowUsers user1 user2

A continuación, reinicie el servicio SSHD introduciendo /etc/init.d/sshd restart o service sshd restart.

Desactivar el inicio de sesión de root

Para desactivar los inicios de sesión de root, abra el fichero /etc/ssh/sshd_config mientras esté conectado como root y cambie la línea #PermitRootLogin por PermitRootLogin no. Asegúrese de eliminar el símbolo #; de lo contrario, no funcionará.

A continuación, reinicie el servicio SSHD introduciendo /etc/init.d/sshd restart o service sshd restart.

Desactivar los cifrados débiles

Abra el fichero /etc/ssh/sshd_config y añada estas líneas:

# Ciphers moderns
Ciphers [e-mail],[e-mail],[e-mail]

# KEX robusts
KexAlgorithms curve25519-sha256,[e-mail],ecdh-sha2-nistp256,ecdh-sha2-nistp384

# MAC moderns
MACs hmac-sha2-512,hmac-sha2-256,[e-mail]

# Disable weak algorithms
PubkeyAcceptedKeyTypes ssh-ed25519,rsa-sha2-256,rsa-sha2-512
HostKeyAlgorithms ssh-ed25519,rsa-sha2-256,rsa-sha2-512

A continuación, reinicie el servicio SSHD introduciendo /etc/init.d/sshd restart o service sshd restart.

Utilizar un puerto no estándar

La gran mayoría de los hackers que buscan servidores SSH abiertos buscarán el puerto 22, ya que, de forma predeterminada, SSH escucha las conexiones entrantes en ese puerto. Para ejecutar SSH en un puerto diferente, abra el fichero /etc/ssh/sshd_config y añada las siguientes líneas:

#Run SSH on a non standard port
Port 2025 #Change me

A continuación, reinicie el servicio SSHD introduciendo /etc/init.d/sshd restart o service sshd restart.

Asegúrese de cambiar el reenvío de puertos en su router y cualquier regla de firewall necesaria. Se recomienda informar a los clientes de cualquier cambio de puerto para que sepan a qué puerto conectarse, ya que SSH ya no escuchará conexiones en el puerto estándar.

Limitar la exposición de SSH con controles de red

Si no es viable cambiar el puerto SSH, implementar un servidor de salto proporciona un sólido punto de control Zero-Trust entre los clientes y los sistemas internos. Centraliza la autenticación, aplica políticas de acceso uniformes y evita la exposición directa de los activos críticos. Consulte Remote Desktop Manager Jump (función) para conocer los pasos de configuración.

Habilitar la autenticación multifactor

La autenticación multifactor es una de las principales protecciones que se deben añadir a los servidores SSH para protegerlos del acceso no autorizado, ya que cada inicio de sesión de usuario debe estar vinculado a un usuario MFA configurado. Incluso si un hacker consigue hacerse con una contraseña o penetrar en el servidor SSH, la MFA seguirá bloqueándolo.