Cómo proteger y fortalecer el servidor OpenSSH

Cómo proteger y fortalecer el servidor OpenSSH

Cuando se trata de acceder a dispositivos remotos como servidores, enrutadores y conmutadores, el protocolo SSH es muy recomendable dada su capacidad para cifrar el tráfico y protegerse de cualquiera que intente espiar sus conexiones.

Sea como fuere, la configuración predeterminada de SSH. no es infalible y se necesitan ajustes adicionales para que el protocolo sea más seguro. En esta guía, exploramos diferentes formas que puede utilizar para proteger y fortalecer la instalación de OpenSSH en el servidor.

1. Configure la autenticación sin contraseña SSH

De forma predeterminada, SSH. requiere que los usuarios proporcionen sus contraseñas al iniciar sesión. Pero aquí está la cuestión: los piratas informáticos pueden adivinar las contraseñas o incluso realizar un ataque de fuerza bruta utilizando hackear herramientas y obtener acceso a su sistema. Para estar seguro, se recomienda encarecidamente el uso de la autenticación sin contraseña SSH.

El primer paso es generar un par de claves SSH que consta de una clave pública. y una clave privada. La clave privada. reside en su sistema host mientras que la clave pública. se copia al servidor remoto.

Una vez que la clave pública. se ha copiado correctamente, ahora puede SSH en el servidor remoto sin problemas sin tener que proporcionar una contraseña.

freestar.config.enabled_slots.push

El siguiente paso es deshabilitar la autenticación de contraseña. Para lograr esto, necesita modificar el archivo de configuración SSH.

$ sudo vim/etc/ssh/sshd_config

Dentro del archivo de configuración, desplácese y ubique el siguiendo la directiva. Descomente y cambie la opción ‘yes’ a ‘no’

PasswordAuthentication no  Deshabilitar la autenticación de contraseña SSH  Desactivar autenticación de contraseña SSH Desactivar autenticación de contraseña SSH

Luego reinicie el demonio SSH.

# sudo systemctl restart sshd

En este punto, solo tendrá acceso al servidor remoto usando la autenticación de clave SSH.

2. Deshabilitar las solicitudes de conexión sin contraseña SSH de usuario

Otra forma recomendada de fortalecer la seguridad de su servidor es deshabilitar los inicios de sesión SSH de los usuarios sin contraseña. Esto suena un poco extraño, pero a veces los administradores del sistema pueden crear cuentas de usuario y olvidarse de asignar contraseñas, lo cual es una muy mala idea.

Para rechazar solicitudes de usuarios sin contraseña, nuevamente, diríjase al archivo de configuración en/etc/ssh/sshd_config y asegúrese de tener la siguiente directiva:

PermitEmptyPasswords no Desactivar inicios de sesión sin contraseña SSH de usuario Deshabilitar inicios de sesión sin contraseña SSH de usuario Deshabilitar inicios de sesión sin contraseña SSH de usuario

Luego reinicie el servicio SSH para que se efectúe el cambio.

$ sudo systemctl restart sshd

3. Desactivar los inicios de sesión de root SSH

Es obvio lo que puede suceder si un pirata informático logra forzar brutalmente su contraseña de root. Permitir el inicio de sesión de root remoto es invariablemente una mala idea que podría poner en peligro la seguridad de su sistema.

Por esta razón, siempre se recomienda que desactive el inicio de sesión de root remoto SSH y, en su lugar, se ciña a un usuario que no sea root. Una vez más, diríjase al archivo de configuración y modifique esta línea como se muestra.

PermitRootLogin no  Desactivar inicios de sesión raíz SSH  Deshabilitar inicios de sesión de raíz SSH Deshabilite los inicios de sesión de root SSH

Una vez que haya terminado, reinicie el servicio SSH para que se efectúe el cambio.

$ sudo systemctl restart sshd

De ahora en adelante, el inicio de sesión de root remoto se desactivará.

4. Use SSH Protocol 2

SSH viene en dos versiones: SSH protocolo 1. y protocolo 2. El protocolo 2. SSH se introdujo en 2006 y es más seguro que el protocolo 1. gracias a sus sólidas comprobaciones criptográficas, cifrado masivo y algoritmos robustos.

De forma predeterminada, SSH utiliza el protocolo 1. Para cambiar esto al Protocolo 2. más seguro, agregue la línea siguiente al archivo de configuración:

Protocolo 2  Usar el protocolo SSH 2  Usar protocolo SSH 2 Usa el protocolo SSH 2

Como siempre, reinicia SSH para que los cambios entren en vigor.

$ sudo systemctl restart sshd

En el futuro, SSH usará Protocolo 2. por defecto.

Para probar si el protocolo 1. SSH ya es compatible, ejecute el comando:

$ ssh-1 [email protected ]

Obtendrá un error que dice “ El protocolo SSH v.1 ya no es compatible. .

I En este caso, el comando fue:

$ ssh-1 [correo electrónico protegido]  Comprobar protocolo SSH Comprobar protocolo SSH Verificar protocolo SSH

Además, puede sim especifique la etiqueta-2 solo para asegurarse de que Protocolo 2. es el protocolo predeterminado en uso.

$ ssh-2 [email protected]  Usar el protocolo SSH 2  Usar protocolo SSH 2 Utilice el protocolo SSH 2

5. Establezca el valor inactivo del tiempo de espera de la conexión SSH

Dejar su PC desatendida durante períodos prolongados con una conexión SSH inactiva puede representar un riesgo para la seguridad. Alguien puede simplemente pasar y hacerse cargo de su sesión SSH y hacer lo que quiera. Para abordar el problema, es prudente, por lo tanto, establecer un límite de tiempo de espera inactivo que, cuando se exceda, se cerrará la sesión SSH.

Una vez más, abra su archivo de configuración SSH y ubique la directiva ” ClientAliveInterval ”. Asigne un valor razonable, por ejemplo, he establecido el límite en 180. segundos.

ClientAliveInterval 180

Esto implica que la sesión SSH se eliminará si no se registra actividad después de 3 minutos que es el equivalente a 180 segundos.

 Establecer valor de tiempo de espera de conexión SSH  Establecer valor de tiempo de espera de conexión SSH Establecer tiempo de espera de conexión SSH Valor

Luego reinicie el demonio SSH para efectuar los cambios realizados.

$ sudo systemctl restart sshd

6. Limitar el acceso SSH a ciertos usuarios

Para una capa de seguridad adicional, puede definir los usuarios que requieren el protocolo SSH para iniciar sesión y realizar tareas remotas en el sistema. Esto evita que otros usuarios intenten acceder a su sistema sin su aprobación.

Como siempre, abra el archivo de configuración y agregue la directiva “ AllowUsers. seguida de nombres de usuarios que desea otorgar. En el siguiente ejemplo, he permitido que los usuarios “ tecmint. y “ james. tengan acceso remoto al sistema a través de SSH. Cualquier otro usuario que intente obtener acceso remoto será bloqueado.

AllowUsers tecmint james  Limitar inicios de sesión de usuario SSH  Limitar inicios de sesión de usuario SSH Limitar inicios de sesión de usuario SSH

A partir de entonces, reinicie SSH para que los cambios persistan.

$ sudo systemctl restart sshd

7. Configure un límite para los intentos de contraseña

Otra forma en que puede agregar una capa de seguridad es limitando el número de intentos de inicio de sesión SSH de modo que después de varios intentos fallidos, la conexión se interrumpa. Así que, una vez más, diríjase al archivo de configuración y localice la directiva “ MaxAuthTries. y defina un valor para el número máximo de intentos.

En este ejemplo, se ha establecido el límite a 3. intentos como se muestra.

MaxAuthTries 3  Limitar intentos de contraseña SSH  Limitar intentos de contraseña SSH Limit SSH Password Intents

Y finalmente, reinicie el servicio SSH como en el anterior escenarios.

También puede encontrar útiles estos siguientes artículos relacionados con SSH:

  • Cómo instalar OpenSSH 8.0 Server desde el código fuente en Linux
  • Cómo instalar Fail2Ban para proteger SSH en CentOS/RHEL 8
  • Cómo cambiar el puerto SSH en Linux
  • Cómo crear tunelización SSH o reenvío de puertos en Linux
  • 4 formas de Acelere las conexiones SSH en Linux
  • Cómo encontrar todos los intentos de inicio de sesión SSH fallidos en Linux
  • Cómo desconectar las conexiones SSH inactivas o inactivas en Linux

Conclusión

Ese fue un resumen de algunas de las medidas que puede tomar para asegurar sus conexiones remotas SSH. Es importante agregar que siempre debe asignar contraseñas seguras a los usuarios que tienen acceso remoto para frustrar los ataques de fuerza bruta. Esperamos que haya encontrado útil esta guía. Sus comentarios son bienvenidos.