¿Qué tan segura es la autenticación basada en clave ssh?

  

Cuando inicié sesión esta mañana, ejecuté netstat -plant y encontré un par   de conexiones establecidas en el puerto 22 de China y Francia.

¿Por cuánto tiempo los viste?

Si tiene un servidor SSH en Internet, la gente lo buscará constantemente e intentará atacar con el diccionario las contraseñas comunes. Por lo tanto, los sistemas se conectarán, intentarán varias contraseñas y aplicarán demoras entre intentos, ya que su sistema desea limitar los ataques de fuerza bruta.

Todo esto significa que las conexiones TCP están "establecidas" por segundos o incluso minutos. No son sesiones SSH autenticadas, solo son conexiones TCP.

Aquí, mira:

$ netstat -tn | grep :22 | egrep -v "[my address]"
tcp        0   1080 192.168.1.2:22         123.183.209.136:25690   ESTABLISHED
tcp        0      1 192.168.1.2:22         123.183.209.136:40117   FIN_WAIT1

un par de minutos más tarde:

$ netstat -tn | grep :22
tcp        0   1080 192.168.1.2:22         123.183.209.136:48456   ESTABLISHED

En la primera instantánea, vemos que hay una sesión establecida y otra que aún está siendo demolida. Un par de minutos más tarde, hay una nueva sesión (observe que el puerto del cliente ha cambiado a 48456). Así que esta persona está constantemente abriendo una conexión TCP, tratando de autenticarse, y cuando esa conexión se cierra por demasiados intentos, simplemente abre otro.

  

Me cuesta creer que una clave rsa de 4096 bits se pueda descifrar   en el espacio de una noche.

     

¿Hay alguna vulnerabilidad / vulnerabilidad que se pueda utilizar para   ¿Eludir la autenticación basada en clave con OpenSSH?

     

¿La autenticación basada en clave es la mejor opción para permitir el acceso con SSH? Qué son   las alternativas?

No te asustes todavía. Mira las conexiones; a menos que vea una última por un período de tiempo significativo, probablemente no tenga que preocuparse.

También puede verificar el resultado de last para ver si alguien realmente está iniciando sesión, y correlacionar su dirección de origen (por ejemplo, no se preocupe por los inicios de sesión desde la IP desde la que usted inicia sesión):

$ last
gowenfawr pts/0        192.168.1.3      Thu Aug  3 18:55   still logged in
gowenfawr pts/0        172.16.43.21     Thu Aug  3 03:29 - 03:29  (00:00)
gowenfawr pts/0        172.16.43.21     Thu Aug  3 03:19 - 03:29  (00:09)
gowenfawr pts/0        172.16.43.21     Thu Aug  3 03:04 - 03:06  (00:02)
gowenfawr pts/1        192.168.1.3      Wed Aug  2 19:44 - 21:09  (01:25)

wtmp begins Wed Aug  2 19:44:26 2017

Aunque, por supuesto, si alguien hizo comprometer su sistema, no podría confiar en last o netstat de todos modos.

Las claves RSA son lo suficientemente seguras para el futuro previsible, y 4096 bit incluso podrían ser excesivo .

Si te preocupa, puedes configurar algo como fail2ban, pero si no permites la autenticación de contraseña y tienes claves RSA con > = 2048 bits, estás bien.

Supongo que si revisa sus registros de autenticación encontrará muchas fallas de autenticación en esas direcciones, y eso es bastante normal. En este momento, mi servidor público ssh tiene un registro de autenticación de 14MB, con más de 82,000 intentos fallidos de inicio de sesión para la raíz:

sudo grep -i root /var/log/auth.log -c
82023

Mientras lo configures correctamente, la clave no se ha roto.

Si solo aparecen en netstat, probablemente solo estén en el indicador de inicio de sesión de SSH.

Asegúrese de deshabilitar las contraseñas de texto claro con túneles en su archivo /etc/ssh/sshd_config para evitar los inicios de sesión normales. Asegúrese de tener otra forma de ingresar a su servidor si pierde sus claves.

PermitRootLogin se debe establecer en no . No debe iniciar sesión como root, especialmente a través de SSH. Usa otra cuenta con acceso sudo.

La autenticación de clave SSH es la mejor manera de autenticarse en un servidor SSH, especialmente en un servidor SSH que está expuesto a Internet. También hay un software que implementa la autenticación de dos factores para los inicios de sesión de SSH mediante Google Authenticator. Esto es algo que vale la pena analizar.