Parece que se excluyen mutuamente, ya que deshabilitar uno me da el otro y viceversa. La autenticación de dos factores para mis servidores ssh suena realmente bien, ¿hay alguna forma de lograr esto?
Parece que se excluyen mutuamente, ya que deshabilitar uno me da el otro y viceversa. La autenticación de dos factores para mis servidores ssh suena realmente bien, ¿hay alguna forma de lograr esto?
Con las recientes versiones de Fedora y RHEL 6, puede usar RequiredAuthentications2 pubkey,password para requerir la autenticación de contraseña de pubkey y . Por lo general, esto se hace para requerir clave de pub y token de autenticación de 2 factores, no la contraseña del usuario.
Actualización: ahora en RHEL / CentOS 7, y en cualquier sistema con una versión reciente de OpenSSH, puede usar:
AuthenticationMethods "publickey,password" "publickey,keyboard-interactive"
También es posible usar la directiva Match para excluir IPs o Usuarios.
Puede tener autenticación de clave pública y contraseña en el mismo servidor. Si la autenticación de clave pública falla, pasará a la autenticación de contraseña.
En cuanto a requerir ambos, eso parece tonto y contraproducente, y al verificar man sshd_config no hay una opción para hacer esto.
Su clave privada ssh debe tener una contraseña segura. Entonces, si un atacante obtiene su clave privada, aún no puede hacer nada sin obtener primero su frase de contraseña. Si han comprometido esa frase de contraseña (lo más probable es que con un keylogger; o debido a la fuerza bruta forzada de una frase de contraseña extremadamente débil), también pueden tomar de forma trivial / bruta forzar cualquier contraseña memorizada.
Si realmente lo desea, puede configurar algo con, por ejemplo, ForceCommand (por ejemplo, solo permitir la autenticación de clave pública y luego dirigir al usuario a un shell que solicite una contraseña). No recomiendo esto.
Una alternativa mejor si desea limitar la exposición, es tener una configuración de firewall para limitar las IP que pueden alcanzar el puerto ssh; posiblemente con una VPN adicional ejecutándose en un servidor en algún lugar si es posible que necesite hacer un túnel desde otra computadora en algún momento. También puede usar algo como knockd para abrir un agujero en un firewall después de un patrón particular de detonación de puertos, aunque reconozca que cualquiera las escuchas ilegales en el tráfico podrían reproducir el patrón de detonación para abrir un puerto.
(publicación cruzada de respuesta del SO con una solución actualizada para estos días)
Si leyó la página del manual para sshd_config(5) , existe la opción AuthenticationMethods , que toma la lista de métodos que debe pasar antes de que se le otorgue acceso. Su configuración requerida es:
AuthenticationMethods publickey,password
Este método debería funcionar con todos los sistemas Linux actuales con openssh recientes (openssh-6, openssh-7).
La única excepción que conozco es RHEL 6 (openssh-5.3), que requiere configurar diferentes opciones con los mismos valores (como se describe en la otra respuesta):
RequiredAuthentications2 publickey,password
Miré esto un poco más y encontré lo siguiente.
Puede usar PAM para la autenticación de dos factores, pero al hacerlo no usará claves SSH, sino dos factores diferentes.
Por ejemplo, podría usar google con su autenticación de dos factores y usar pam para autenticarse, como se describe en
La única solución que me funcionó es tener lo que sigue en el / etc / ssh / sshd_config (probado con un CentOS7):
PubkeyAuthentication yes
AuthenticationMethods publickey password
AuthorizedKeysFile .ssh/authorized_keys
PasswordAuthentication yes
PermitEmptyPasswords no
ChallengeResponseAuthentication no
UsePAM yes
Lo que significa tener habilitado PAM, haber habilitado todas las líneas relacionadas con la clave de publicación y, finalmente, tener AuthenticationMethods enumerando ambos métodos correctamente. Tenga en cuenta que, a pesar de lo que escribió escrito por Jakuje , no debe agregar una coma entre publickey y contraseña después de AuthenticationMethods.