Servidor SSH en Linux
Servidor SSH en Linux
Servidor SSH en Linux
Otras características fundamentales de SSH son que nos va a permitir copiar datos de manera
segura, tanto archivos como carpetas, a través del protocolo SFTP (SSH FTP), un protocolo hecho
desde cero y que no tiene nada que ver con FTPS o FTPES (FTP sobre SSL/TLS). El protocolo SSH es
fundamental en el ámbito de las redes y sistemas, además, podremos configurarlo en detalle para
dotar a nuestro sistema de la máxima seguridad posible.
Existen dos versiones de SSH, la versión 1 no se recomienda hoy en día usarla, de hecho, por
defecto siempre se utiliza ya la versión SSHv2. Por defecto SSH utiliza el protocolo TCP de la capa
de transporte, y el número de puerto es el 22, no obstante, podremos cambiar el número de
puerto para mitigar posibles escaneos de bots al servicio SSH.
En este manual que hoy os presentamos, os vamos a enseñar a configurar el servidor SSH de
OpenSSH, un programa que está disponible para sistemas operativos basados en Unix y Linux,
como por ejemplo FreeBSD, OpenBSD, Debian, Red Hat Enterprise Linux y un largo etcétera de
distribuciones. En esta guía no solo aprenderemos a configurar correctamente el archivo de
configuración sshd_config, sino que usaremos programas adicionales para dotar al sistema de la
máxima seguridad posible. En este manual todas las configuraciones las realizaremos con Debian,
no obstante, todas las medidas de seguridad pueden ser implementadas en cualquier sistema
operativo basado en Linux y Unix.
1 /home/usuario/.ssh/
Este directorio por defecto está oculto (.ssh) y hay un directorio por cada usuario que haya en el
sistema operativo y que se conecte a un servidor remoto.
Port 22445
Desactivando al propio usuario root, y usando “sudo” para elevar a permisos de superusuario,
evitaremos esto. Además, OpenSSH también nos permitirá deshabilitar el login del usuario root
para dotar al sistema de mayor seguridad:
PermitRootLogin no
De esta manera las conexiones root quedarán bloqueadas evitando que usuarios no autorizados
puedan realizar ataques de fuerza bruta contra nuestro servidor SSH para adivinar los credenciales
del usuario Root. También tenemos otras opciones en este apartado, como por ejemplo
“PermitRootLogin without-password” donde se permite autenticación pero no con usuario y
contraseña, sino con claves criptográficas RSA.
1 Port 22445
2
3 PermitRootLogin no
4
5 LoginGraceTime 30
6
7 MaxAuthTries 3
8
9 MaxStartups 3
10
11 AllowUsers sergio sergio2
12
13 DenyUsers adrian adrian2
Una medida de seguridad adicional es configurar los algoritmos de intercambio de claves, el cifrado
simétrico y también, la configuración del HMAC para la comprobación de la integridad.
Actualmente es recomendable aplicar la siguiente configuración para tener una seguridad muy alta:
KexAlgorithms curve25519-sha256@libssh.org,ecdh-sha2-nistp521,ecdh-
1
sha2-nistp384,ecdh-sha2-nistp256,diffie-hellman-group-exchange-sha256
Ciphers chacha20-poly1305@openssh.com,aes256-gcm@openssh.com,aes128-
1
gcm@openssh.com,aes256-ctr,aes192-ctr,aes128-ctr
MACs hmac-sha2-512-etm@openssh.com,hmac-sha2-256-
1 etm@openssh.com,umac-128-etm@openssh.com,hmac-sha2-512,hmac-sha2-
256,umac-128@openssh.com
Con esta configuración tendremos las mejores suites criptográficas para el servidor, sin embargo,
es posible que clientes antiguos no puedan conectarse al no soportar estos algoritmos. Debemos
tener este detalle muy en cuenta, y probar qué algoritmos son compatibles y cuáles no.
Si hemos creado nuevas claves de RSA o DSA por unas con mayor longitud de bits, deberemos
ponerlo en el fichero de configuración (o sustituir las anteriores, y así no tendremos que tocar el
fichero de configuración), de esta forma obtendremos una seguridad adicional si por ejemplo
usamos claves RSA de 4096 bits o superior.
1 HostKey /etc/ssh/ssh_host_ed25519_key
2 HostKey /etc/ssh/ssh_host_rsa_key
3 HostKey /etc/ssh/ssh_host_ecdsa_key
Para generar unas claves RSA de 4096 bits nuevas, simplemente deberemos ejecutar el siguiente
comando:
Usuario y clave
Si queremos habilitar el login en el servicio a través del usuario y contraseña del sistema, el archivo
de configuración deberá tener esta sentencia:
PasswordAuthentication yes
De lo contrario, si queremos impedir la autenticación a través de usuario/clave, y permitir
únicamente las conexiones a través de claves criptográficas, deberemos indicar no:
PasswordAuthentication no
Esta sentencia afecta a todos los usuarios del sistema. Para no quedarnos sin acceso al servidor,
deberíamos asegurarnos de que la sentencia PubkeyAuthentication esté configurada a “yes”, para
permitir el inicio de sesión con claves criptográficas.
PubkeyAuthentication yes
Así es como activamos la configuración con clave pública SSH en el sistema, no obstante, aún hay
algunos pasos que deberemos hacer para que nos podamos conectar a dicho servidor, y es pasar la
clave pública al propio equipo. Para hacerlo, deberemos permitir (de momento) la autenticación
con usuario/clave, una vez que terminemos todos los pasos podremos denegar la autenticación
con usuario y contraseña sin ningún problema.
Desde el ordenador donde nos queramos conectar al servidor con claves criptográficas, debemos
crear dichas claves y pasárselas al servidor. Para crear unas claves RSA de 4096 bits tenemos que
poner en el cliente SSH la siguiente orden:
Una vez que hayamos creado la clave pública y privada en nuestro equipo, debemos enviar la clave
pública al servidor SSH donde nos queramos conectar, ojo: la clave pública.
1 ssh-copy-id usuario@IP_servidor
Automáticamente la clave pública se copiará a dicho servidor, y ya podremos habilitar la
autenticación con solo clave pública y automáticamente nos habremos dado de alta. La salida
ofrecida por este comando debería ser similar a esto:
1 ssh usuario@IP
Recordad poner la directiva “PasswordAuthentication no” para no permitir accesos vía usuario y
clave.
Lo primero que debemos hacer es instalar una serie de dependencias necesarias para poder
configurar la doble autenticación en nuestro servidor SSH. Para ello abriremos un terminal y
teclearemos:
1 google-authenticator
A continuación veremos un sencillo asistente desde el terminal. Lo primero que nos preguntará es
si queremos que nuestros tokens de acceso estén basados en el tiempo. A continuación veremos la
clave privada, la clave de verificación y los códigos de emergencia si no tenemos nuestro móvil a
mano. Debemos guardar todos estos datos de forma segura de manera que podamos recuperar el
acceso en caso de pérdida de la clave de autenticación.
Después le decimos que guarde los cambios en el archivo de nuestra carpeta /home y nos
preguntará si queremos que cada token sea utilizado una única vez, aunque eso limite a un inicio
de sesión cada 30 segundos. Para protegernos frente a posibles ataques MITM seleccionamos que
sí. Por último, nos preguntará si queremos ampliar el periodo de validez de cada código en lugar de
solo 1 minuto y 30 segundos (para evitar problemas de sincronización de tiempo). Para evitar
ataques de fuerza bruta también podemos limitar las conexiones a 3 por cada 30 segundos.
El siguiente paso que debemos hacer es abrir el fichero de configuración de “sshd” para indicarle
que utilice este módulo para el inicio de sesión. Para ello podemos hacer un “clear” para limpiar el
terminal y teclear en él:
Reiniciamos el servidor con “sudo /etc/init.d/ssh restart” y una vez que vuelva a arrancar, ya
tendremos la autenticación en dos pasos habilitada.
Una vez hecho, con el inicio de sesión también nos pedirá una clave de un solo uso, el código
generado por nuestra aplicación móvil.
1 PasswordAuthentication no
2 ChallengeResponseAuthentication yes
3 PubKeyAuthentication yes
4 UsePAM yes
5 AuthenticationMethods publickey,keyboard-interactive
Y en el fichero /etc/pam.d/sshd debemos tener algo como esto:
1 #@include common-auth
2 auth required pam_google_authenticator.so
Muy importante poner una almohadilla (#) para comentar el @include, de esta forma, nos
autenticaremos correctamente con clave pública más el código OTP generado por el móvil. De esta
forma, estaremos diciéndole al servidor que acepte autenticación con clave pública únicamente.
Si un atacante intenta conectarse múltiples veces desde la misma IP, podremos limitar dicho
número de conexiones para mitigar su ataque. Esto no corta de raíz un posible ataque, sino que lo
mitiga con dos objetivos: no tener un gran consumo de memoria y CPU en el equipo por abrir
múltiples conexiones SSH, retrasar un posible ataque por fuerza bruta abriendo múltiples
conexiones.
Esta sentencia ACEPTA hasta 5 conexiones que provengan de la misma IP pública, a partir de la
sexta conexión lo bloqueamos. Si tenemos varias interfaces de red, deberemos usar el “-i” para
poner por qué interfaz estamos aplicando esta regla, si no ponemos nada se aplicará a todas ellas.
Port Knocking es una aplicación, que por defecto no se encuentra instalada en los sistemas
operativos, podéis instalarla a través de los repositorios oficiales. En nuestro caso, al usar Debian 9,
la instalación sería así:
Debemos editarlo con cualquier editor de archivos, necesario permisos de root. El fichero tendrá el
siguiente aspecto:
1 [options]
2 UseSyslog
3
4 [openSSH]
5 sequence = 7000,8000,9000
6 seq_timeout = 5
command = /sbin/iptables -A INPUT -s %IP% -p tcp --dport 22445 -j
7
ACCEPT
8 tcpflags = syn
9
10 [closeSSH]
11 sequence = 9000,8000,7000
12 seq_timeout = 5
command = /sbin/iptables -D INPUT -s %IP% -p tcp --dport 22445 -j
13
ACCEPT
14 tcpflags = syn
Y para poder “abrir” el puerto del servicio SSH, deberemos poner en consola “knock IP_address
7000 8000 9000”. Una vez que hayamos utilizado el servicio, podremos cerrarlo con la sentencia
que hayamos puesto anteriormente en el fichero de configuración, no tiene por qué ser justo al
revés (depende de cómo hayas configurado el fichero de arriba).
Otra opción que tenemos en Port Knocking es el desbloqueo temporal del servidor, de esta
manera, abriremos el puerto durante 10 segundos (o los que quieras), y es entonces cuando
deberemos iniciar sesión en el servicio. Posteriormente, el puerto se cerrará y si estamos logueados
no nos echará de dicho servidor.
1 [options]
2 UseSyslog
3
4 [SSH]
5 sequence = 5438,3428,3280,4479
6 tcpflags = syn
7 seq_timeout = 15
start_command = /sbin/iptables -A INPUT -s %IP% -p tcp --dport 22445
8
-j ACCEPT
9 cmd_timeout = 10
stop_command = /sbin/iptables -D INPUT -s %IP% -p tcp --dport
10
22445 -j ACCEPT
De esta forma, al salirnos del servidor no hará falta que “cerremos” la puerta como ocurría en el
caso anterior, ya que solo ha estado abierta durante 10 segundos.
1 [sshd]
2 enabled = true
3 port = 22445
4 bantime = 3600
5 findtime = 600
6 filter = sshd
7 maxretry = 3
Y lo iniciamos, paramos y reiniciamos haciendo como si fuera el SSH, en este caso start=iniciar: