SERVIDOR SSH EN LINUX: MANUAL DE

CONFIGURACIÓN PARA MÁXIMA SEGURIDAD

SSH o también conocido como Secure Shell, es un protocolo y el nombre del programa que lo
implementa. SSH es ampliamente conocido por ser el protocolo seguro para la administración
remota de servidores, routers, switches y un largo etcétera de equipos. El protocolo SSH permite
manejar por completo el servidor o dispositivo de red mediante un intérprete de órdenes, además,
también podemos redirigir el tráfico de X para ejecutar programas gráficos a través de la propia
sesión SSH.

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.

El protocolo SSH proporciona confidencialidad (los datos van cifrados punto a

punto), autenticación (podremos autenticarnos frente al servidor SSH de múltiples maneras, con
usuario/clave, criptografía de clave pública e incluso podremos configurar un segundo factor de
autenticación), integridad (si los datos se modifican o los modifica un usuario malintencionado se
podrá detectar, ya que usa HMAC para comprobar la integridad de todos y cada uno de los datos).

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.

Instalación de OpenSSH y puesta en marcha

OpenSSH es el programa servidor/cliente SSH más utilizado por los routers, switches, servidores y
un largo etcétera de dispositivos. Este programa es completamente gratuito y de código abierto.
La instalación de este servidor SSH(si es que no lo tienes ya instalado por defecto) es muy sencilla,
simplemente debemos poner en un terminal la siguiente orden:

1 sudo apt install openssh-server

Una vez instalado, debemos tener en cuenta ciertos directorios y órdenes para iniciar, parar y
reiniciar el servicio SSH.

Para editar la configuración del servidor SSH debemos hacer en consola:

1 sudo nano /etc/ssh/sshd_config
Otro directorio que tenemos que tener muy en cuenta es la de host conocidos, ya que aquí
también es donde configuraremos las claves criptográficas RSA/DSA. El directorio donde se
encuentran los hosts conocidos y las claves públicas es el siguiente:

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.

Para arrancar el servidor:

1 sudo /etc/init.d/ssh start

Para parar el servidor:

1 sudo /etc/init.d/ssh stop

Para reiniciar el servidor:

1 sudo /etc/init.d/ssh restart

Una vez que hemos instalado el servidor SSH, sabemos dónde están los archivos de configuración
del servidor y el directorio donde se almacenan las claves públicas, vamos con la configuración del
sshd_config ya que es el archivo de configuración fundamental de OpenSSH.

Configuración de sshd_config para la máxima

seguridad

Cambiar el puerto por defecto del servidor SSH

Por defecto los servidores SSH utilizan el puerto 22 para las conexiones. Es recomendable cambiar
este número de puerto, para evitar que bots o cibercriminales puedan intentar iniciar sesión,
aunque por sí solo esto no proporciona seguridad, sí podremos pasar desapercibidos a los escaneos
masivos desde Internet. Si por ejemplo queremos usar el puerto 22445 debemos poner en el
fichero de configuración lo siguiente:

 Port 22445

Bloquear el acceso root en las conexiones remotas

Por defecto, cualquier usuario en el sistema operativo que tenga permisos de Shell, podrá iniciar
sesión en el servidor. Además, debemos tener en cuenta que si tenemos activado el usuario root,
también podrá conectarse al servidor de forma local o remota, evitando al atacante tener que
“adivinar” el nombre de usuario. Por defecto, los bots siempre intentan atacar el puerto 22 y al
usuario “root”.

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.

Configuraciones de seguridad adicionales

Existen otras configuraciones recomendadas para evitar las conexiones no deseadas a nuestro
servidor SSH. Estas conexiones son:

 LoginGraceTime: Estableceremos el tiempo necesario para introducir la contraseña, evitando

que el atacante tenga que “pensar mucho”.
 MaxAuthTries: Número de intentos permitidos al introducir la contraseña antes de
desconectarnos.
 MaxStartups: Número de logins simultáneos desde una IP, para evitar que se pueda utilizar la
fuerza bruta con varias sesiones a la vez.
 AllowUsers: Es crear una lista blanca de usuario. Este parámetro nos permite configurar los
usuarios que podrán conectarse. Una medida muy restrictiva pero a la vez muy segura ya que
bloqueará todas las conexiones de los usuarios que no estén en el listado. Los usuarios que
tengamos aquí podrán conectarse, y el resto no.
 DenyUsers: Parecido al anterior, pero ahora creamos una lista negra. Los usuarios que
tengamos aquí no podrán conectarse, y el resto sí.
 AllowGroups/DenyUsers: Exactamente igual a lo anterior, pero en lugar de crear una lista
blanca/negra de usuarios, es de grupos de usuarios.

Por ejemplo, un archivo de configuración de sshd_config sería el siguiente:

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:

1 ssh-keygen -f /etc/ssh/ssh_host_rsa_key -t rsa -b 4096

Si queremos generar nuevas claves ECDSA (con máxima longitud de 512 bits) o ED25519 tendremos
que introducir los siguientes comandos:

1 ssh-keygen -f /etc/ssh/ssh_host_rsa_key -t ecdsa -b 521

2
3 ssh-keygen -f /etc/ssh/ssh_host_rsa_key -t ed25519

Autenticación en SSH: Todos los modos explicados

en detalle
En este apartado os vamos a enseñar los diferentes métodos de autenticación que tenemos
disponibles en el servidor. Normalmente tenemos dos métodos principalmente: usuario y
contraseña (algo que sabemos), y también con claves criptográficas (algo que tenemos). No
obstante, podemos dotar al sistema de una seguridad adicional, combinando estas autenticaciones
con por ejemplo un One Time Password generado por una aplicación como Google Authenticator o
Latch OTP. Además, también podremos dotar al sistema de Latch, para evitar que cualquier usuario
inicie sesión si no tenemos el “pestillo” abierto.

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.

Hay otra sentencia relacionada con esto llamada ChallengeResponseAuthentication, si ponemos la

configuración a “no”, no permitirá las conexiones donde se interactúe con el teclado, por lo que si
por ejemplo tenemos configurado un One Time Password, no podremos iniciar sesión en el
sistema. Si únicamente vamos a usar claves criptográficas, podréis ponerlo a “no” sin problemas.

Clave pública SSH

Para configurar el acceso con clave pública al servidor, deberemos poner la sentencia siguiente a
“yes”:

 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:

1 ssh-keygen -t rsa -b 4096

En el asistente de generación de estas claves, nos pondrá si queremos guardarlas en
/home/usuario/.ssh/id_rsa, le decimos que sí. Posteriormente nos permitirá poner a la clave
privada una contraseña de paso, de esta forma, si perdemos la llave privada no pasará nada porque
no podrán conectarse, debido a que es necesario siempre introducir una contraseña de paso para
poder realizar la conexión correctamente.

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:

The authenticity of host '12.34.56.78 (12.34.56.78)' can't be

1
established.
RSA key fingerprint is
2
b1:2d:33:67:ce:35:4d:5f:f3:a8:cd:c0:c4:48:86:12.
3 Are you sure you want to continue connecting (yes/no)? yes
Warning: Permanently added '12.34.56.78' (RSA) to the list of known
4
hosts.
5 user@12.34.56.78's password:
Now try logging into the machine, with "ssh 'user@12.34.56.78'", and
6
check in:
7
8 ~/.ssh/authorized_keys
9
10 to make sure we haven't added extra keys that you weren't expecting.
En esta salida, el usuario deberá confirmar que quiere añadir la identidad e introducir las
credenciales de login para la cuenta que se quiere utilizar en ese servicio. Por este motivo es
importante que en el servidor aún mantengamos la posibilidad de autenticarnos con usuario/clave.
Una vez completado este proceso, tendríamos que ser capaces de hacer inicie de sesión en este
equipo sin introducir la contraseña:

1 ssh usuario@IP
Recordad poner la directiva “PasswordAuthentication no” para no permitir accesos vía usuario y
clave.

Usuario y clave con One Time Password (Google

Authenticator o Latch OTP)
En esta parte del manual, vamos a autenticarnos con el usuario/contraseña de siempre, pero
además, deberemos usar un OTP con Google Authenticator o Latch OTP para entrar en la sesión. Es
decir, dotaremos al servidor SSH de verificación en dos pasos.

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 sudo apt install libpam0g-dev make gcc wget ssh

Una vez que las dependencias están instaladas en nuestro sistema ya podemos descargar el
software para la doble autenticación.

1 sudo apt install libpam-google-authenticator

Ya tenemos instalado Google Authenticator en nuestro sistema operativo. Los siguientes pasos a
seguir son la configuración de la herramienta para poderla utilizar en nuestro SSH.

Para comenzar con la configuración de Google Authenticator simplemente debemos teclear en el

terminal:

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 escaneo del código QR o la introducción manualmente de código se puede realizar en programas

como Google Authenticator, Authy, Latch y un largo etcétera. Recomendamos el uso de Google
Authenticator o Latch.

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:

1 sudo nano /etc/pam.d/sshd

Y añadiremos al final del fichero la siguiente línea:

1 auth required pam_google_authenticator.so

Guardamos los cambios y abrimos el fichero sshd_config con el siguiente comando:

1 sudo nano /etc/ssh/sshd_config

Y cambiamos la línea “ChallengeResponseAuthentication no” por
“ChallengeResponseAuthentication yes”.

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.

Clave pública SSH con One Time Password (Google

Authenticator o Latch OTP)
La configuración a nivel de clave pública debe ser exactamente igual que antes, y a nivel de
instalación y configuración del Google Authenticator también. La única diferencia es que en el
fichero sshd_config deberemos tener algo así:

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.

Configuración de Latch en OpenSSH y posteriormente

elegir método de autenticación
Latch para OpenSSH actualmente tiene la limitación de que solo podremos usarlo para un usuario,
es decir, si vamos a intentar iniciar sesión en el servidor SSH con varios usuarios, no podremos
proteger nuestro equipo con Latch porque está limitado a solo uno. Os recomendamos acceder a la
web oficial del plugin Latch para Unix en GitHub, ahí encontraréis el manual paso a paso para
configurarlo correctamente con el servicio SSH si os interesa. Debemos recordar que solo permite
parear un usuario.

Medidas de seguridad adicionales: firewall, port-

knocking, fail2ban y DenyHosts
En este apartado vamos a usar software adicional para proteger el servidor de SSH, ya que es
fundamental para tener una seguridad adicional. Usaremos tanto el firewall basado en iptables,
como port-knocking para ocultar siempre el servicio detrás del firewall, así como fail2bat y
DenyHost para detectar posibles ataques de fuerza bruta y pararlo con el firewall.

Configuración de firewall iptables para proteger SSH

El firewall de iptables incorporado en la mayoría de sistemas basados en Linux, nos va a permitir
limitar el número de conexiones simultáneas a nuestro servidor, y también, vamos a poder usar un
módulo especial llamado “recent” para guardar en una base de datos todos los intentos de
conexiones, ideal para evitar ataques de fuerza bruta.

Limitar el número de conexiones simultáneas en iptables

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.

iptables -A INPUT -p tcp --dport 22445 -m connlimit --connlimit-upto

1
5 --connlimit-mask 32 -j ACCEPT
2
3 iptables -A INPUT -j DROP
Configurar el módulo recent para mitigar ataques de fuerza bruta en el servicio SSH
El módulo recent sirve para limitar el número de conexiones por segundo a nivel de IP, esto es ideal
para protegernos de ataques al puerto SSH porque un atacante probará múltiples contraseñas. En
el siguiente ejemplo, daremos de alta en una base de datos todas las conexiones al puerto TCP
22445 de destino, y daremos de alta el origen de esas conexiones (la IP pública de un posible
atacante).

Posteriormente, chequeamos que en la tabla no haya más de 4 coincidencias en los últimos 60

segundos. Si hay más de 4 coincidencias, procedemos a bloquear todas las conexiones a partir de
ahí.

iptables -A INPUT -p tcp --dport 22445 -m conntrack --ctstate NEW -m

1
recent --set --name ssh --rsource
2
iptables -A INPUT -p tcp --dport 22445 -m state --state NEW -m recent
3
--rcheck --seconds 60 --hitcount 4 --name ssh --rsource -j DROP
Este módulo se diferencia del anterior, en que comprueba por tiempo estas conexiones.
Normalmente para proteger el servicio SSH es mejor utilizar este módulo recent que el anterior.

Port-Knocking para “esconder” el servicio SSH

Port knocking (tocar puertos) es un método discreto de abrir puertos que, por defecto, el firewall
mantiene cerrado. Funciona requiriendo intentos de conexión a una serie de puertos predefinidos
cerrados. Cuando la secuencia correcta de “toques” a puertos (intentos de conexión) es recibida, el
firewall abre entonces cierto(s) puerto(s). El beneficio es que, en un escaneo de puertos normal,
parecería que el servicio del puerto simplemente no está disponible.

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í:

1 sudo apt-get install knockd

Una vez instalado, debemos habilitarlo editando:

1 sudo nano /etc/default/knockd

Y poniendo: START_KNOCKD=1

A continuación, iniciamos el servicio:

1 sudo service knockd start

El fichero de configuración de knockd está en /etc/knockd.conf

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.

Fail2ban para mitigar ataques de fuerza bruta en SSH

Podemos también instalar el programa fail2ban para banear IPs que hagan muchos intentos de
conexión fallidos (que metan mal la clave). Este programa es muy conocido y utilizado, ya que es
muy fácil de configurar y poner en marcha. Podemos instalarlo poniendo

1 sudo apt install fail2ban

Ahora copiamos el archivo .conf en el mismo archivo .local para que se aplique esta configuración:

1 sudo cp /etc/fail2ban/jail.conf /etc/fail2ban/jail.local

Ahora podemos crear con fail2ban una regla personalizada para SSH, creamos un nuevo archivo de
configuración que se encargará de sobreescribir el archivo principal jail.local anterior.

1 sudo nano /etc/fail2ban/jail.d/sshjail.local

Y pegamos esto:

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:

1 sudo /etc/init.d/fail2ban restart

Para ver los LOGS de conexión tendréis que mirar en la ruta /var/log/auth.log, y para ver los logs de
fail2ban tenéis que mirarlos aquí: /var/log/fail2ban.log

DenyHosts: Como fail2ban pero orientado

específicamente a SSH
También tenemos otro programa dedicado exclusivamente al SSH, se llama DenyHost y tiene una
gran base de datos de IPs conocidas como atacantes. Es otra solución a posibles ataques si siempre
tenemos nuestro servidor SSH expuesto a Internet. El funcionamiento de DenyHosts es igual que
fail2ban, vigila los logs de conexión para detectar si estamos ante un ataque de fuerza bruta, y
además comprueba bases de datos de IP para detectar si son botnets.

SSHGuard: Una herramienta para proteger diferentes servicios de ataques por

fuerza bruta

Cómo comprobar la seguridad de mi servidor SSH

En RedesZone tenemos varios artículos hablando sobre diferentes herramientas que nos permitirán
comprobar la seguridad de nuestro servidor SSH. Gracias a estas herramientas, no solo nos dirá los
fallos que podemos tener en la configuración, sino que podremos solucionarlo configurando
correctamente nuestro servidor. Os recomendamos leer todos y cada uno de los artículos, para
comprobar si nuestro servidor SSH lo hemos configurado de manera correcta.
Mozilla lanza una herramienta para verificar la seguridad de tu servidor SSH

Comprueba la seguridad de tu servidor SSH con la herramienta online Rebex

SSH Check

ssh-audit: Conoce esta herramienta para auditar tu servidor SSH y comprobar si

es seguro
Hasta aquí hemos llegado con este manual de cómo configurar en detalle el servicio SSH en nuestro
servidor. Si tenéis cualquier duda podéis ponernos un comentario y os responderemos encantados.