Autenticación de dos factores para SSH

“Secure Shell” SSH es un protocolo de red para establecer una conexión segura entre hosts, estándar a través del puerto 22 (que es mejor cambiar). Los clientes SSH y los servidores SSH están disponibles para la mayoría de los sistemas operativos. Casi cualquier otro protocolo de red funciona dentro de SSH, es decir, puede trabajar de forma remota en otra computadora, transmitir una secuencia de audio o video a través de un canal cifrado, etc. Además, a través del proxy SOCKS en un host remoto puede conectarse a otros hosts en nombre de este host remoto.

La autenticación se produce mediante una contraseña, pero los desarrolladores y administradores de sistemas tradicionalmente utilizan claves SSH. El problema es que pueden robar la clave privada. En teoría, agregar una frase de contraseña protege contra el robo de la clave privada, pero en la práctica, al reenviar y almacenar en caché las claves, todavía se puede utilizar sin confirmación. La autenticación de dos factores resuelve este problema.

Cómo implementar la autenticación de dos factores

Los desarrolladores de Honeycomb publicaron recientemente instrucciones detalladas, cómo implementar la infraestructura adecuada en el cliente y el servidor.

Las instrucciones suponen que tiene un determinado host básico abierto a Internet (bastión). Desea conectarse a este host desde computadoras portátiles o de escritorio a través de Internet y acceder a todos los demás dispositivos que se encuentran detrás de él. 2FA garantiza que un atacante no pueda hacer lo mismo incluso si obtiene acceso a su computadora portátil, por ejemplo, instalando malware.

La primera opción es OTP.

OTP: contraseñas digitales de un solo uso, que en este caso se utilizarán para la autenticación SSH junto con la clave. Los desarrolladores escriben que esta no es una opción ideal, porque un atacante podría crear un bastión falso, interceptar su OTP y usarlo. Pero es mejor que nada.

En este caso, en el lado del servidor, las siguientes líneas están escritas en la configuración de Chef:

  • metadata.rb
  • attributes/default.rb (de attributes.rb)
  • files/sshd
  • recipes/default.rb (Copiado de recipe.rb)
  • templates/default/users.oath.erb

Cualquier aplicación OTP se instala en el lado del cliente: Google Authenticator, Authy, Duo, Lastpass, instaladas brew install oath-toolkit o apt install oathtool openssl, luego se genera una cadena (clave) aleatoria de base16. Se convierte al formato Base32 que utilizan los autenticadores móviles y se importa directamente a la aplicación.

Como resultado, puedes conectarte a Bastion y ver que ahora requiere no solo una frase de contraseña, sino también un código OTP para la autenticación:

➜ ssh -A bastion
Enter passphrase for key '[snip]': 
One-time password (OATH) for '[user]': 
Welcome to Ubuntu 18.04.1 LTS...

La segunda opción es la autenticación de hardware.

En este caso, no es necesario que el usuario ingrese el código OTP cada vez, ya que el segundo factor es el dispositivo de hardware o la biometría.

Aquí la configuración de Chef es un poco más complicada y la configuración del cliente depende del sistema operativo. Pero después de completar todos los pasos, los clientes en MacOS pueden confirmar la autenticación en SSH usando una frase de contraseña y colocando un dedo en el sensor (segundo factor).

Los propietarios de iOS y Android confirman el inicio de sesión presionando un botón en su teléfono inteligente. Esta es una tecnología especial de Krypt.co, que es incluso más segura que OTP.

En Linux/ChromeOS hay una opción para trabajar con tokens USB YubiKey. Por supuesto, un atacante puede robar su token, pero aún no conoce la frase de contraseña.

Fuente: habr.com

Añadir un comentario