Intentando obtener SSH con clave pública (sin contraseña) + autenticador de Google trabajando en Ubuntu 14.04.1


20

Estoy usando Ubuntu 14.04.1 (con OpenSSH 6.6 y libpam-google-authenticator 20130529-2).

Estoy tratando de configurar los inicios de sesión SSH donde la clave pública se autentica (sin contraseña) y se le solicita al usuario un código del Autenticador de Google.

Seguir / adaptar estas instrucciones me ha proporcionado una solicitud de contraseña y una solicitud de autenticación de Google:

He instalado el paquete, editado mi /etc/ssh/sshd_configy /etc/pam.d/ssharchivos

En /etc/ssh/sshd_config:

ChallengeResponseAuthentication yes
AuthenticationMethods  publickey,keyboard-interactive
UsePAM yes

y en la parte inferior de /etc/pam.d/ssh:

auth required pam_google_authenticator.so nullok # (I want to give everyone a chance to set up their 2FA before removing "nullok")

Sé que PAM depende del orden, pero sshd_configtambién lo es .

¿Qué estoy haciendo mal? Cualquier ayuda sería apreciada.

Respuestas:


28

Lo tengo funcionando bien, primero lo hice:

apt-get install libpam-google-authenticator

En /etc/pam.d/sshdHe cambiado / agregado las siguientes líneas (en la parte superior):

# @include common-auth
auth required pam_google_authenticator.so

Y en /etc/ssh/sshd_config:

ChallengeResponseAuthentication yes
UsePAM yes
AuthenticationMethods publickey,keyboard-interactive
PasswordAuthentication no

Funciona bien y ahora recibo un mensaje de "Código de verificación" después de la autenticación con clave pública. No estoy seguro de cómo permitiría la autenticación con contraseña + token O clave + token, ya que ahora he eliminado efectivamente el método de autenticación de contraseña de PAM.

Uso de Ubuntu 14.04.1 LTS (GNU / Linux 3.8.0-19-generic x86_64) con ssh -v: OpenSSH_6.6.1p1 Ubuntu-2ubuntu2, OpenSSL 1.0.1f 6 de enero de 2014


Entonces, por el bien de la posteridad, me di cuenta de mi problema. También lo intenté PasswordAuthentication no, pero no fue así. El problema es / era que tenía / have ControlMaster autoy ControlPathdirectivas en mi archivo ~ / .ssh / config. Quería asegurarme de no bloquearme, por lo que siempre dejaría abierta una sesión SSH. Como mi computadora los reutilizaba, siempre entraba sin que el sistema pidiera un token. Marqué su respuesta como correcta, ya que alguien que la siguiera obtendría una configuración funcional. ¡Gracias!
JT.

2
Estoy usando CentOS 7. Tengo PasswordAuthentication no, ChallengeResponseAuthentication yes, AuthenticationMethods publickey,keyboard-interactive, y UsePAM yesen sshd_config. Valida mi clave y luego me pide mi token de Google Authenticator y luego también me pide mi contraseña. Me hace hacer los tres, no puedo omitir ninguno de ellos. También lo intenté AuthenticationMethods publickey,keyboard-interactive:pamcomo lo sugiere la página del manual, pero eso no cambió nada. ¿Algunas ideas?
Nick Williams

66
@NickWilliams Estaba teniendo el mismo problema. Lo que me solucionó fue que necesitaba elogiar la @include common-authlínea que muestran las respuestas. Solo pensé que era un comentario para la pam_google_authenticatorlínea en /etc/pam.d/sshd al principio.
freb

55
¡Gracias! Mi solución no era exactamente la misma (necesitaba comentar auth substack password-auth), ¡pero su comentario resolvió mi problema!
Nick Williams


7

Finalmente pude hacer que esto funcione al colocarlo auth [success=done new_authtok_reqd=done default=die] pam_google_authenticator.so nulloken la parte superior de /etc/pam.d/sshd.

De acuerdo con la página de manual de pam.d :

  • success=done significa que si Google Authenticator cierra la sesión, no se realizará más autenticación, lo que significa que no se solicitará una contraseña adicional.
  • default=die significa que si Google Authenticator rechaza el intento de inicio de sesión, la autenticación fallará inmediatamente, omitiendo la solicitud de contraseña.

Por [success=done new_authtok_reqd=done default=die]lo tanto, es una especie de mezcla entre los valores de control sufficienty requisite, ya que queremos un comportamiento de ambos: si tiene éxito, finalice inmediatamente (suficiente), y si falla, también finalice inmediatamente (requisito).

Tenga en cuenta que el nullokargumento de pam_google_authenticator.so significa que si ~/.google_authenticatorno se encuentra un archivo para un usuario, la autenticación de clave pública se realiza normalmente. Esto es útil si quiero bloquear solo un subconjunto de mis cuentas con 2FA.


6

La respuesta de Linus Kendall debería funcionar en sistemas más antiguos, pero en máquinas Linux más nuevas es problemática; en mi servidor web basado en arch linux, esa configuración hace que pam solicite mi código de autenticador y mi contraseña después de recibir mi clave ssh (es decir, necesito los 3).

Una solución más simple que previene este problema y que debería funcionar en cada sistema es cambiar la entrada /etc/pam.d/sshda:

auth sufficient pam_google_authenticator.so

Y luego hacer las mismas ediciones a `` / etc / ssh / sshd` que Linus mencionó:

ChallengeResponseAuthentication yes
UsePAM yes
AuthenticationMethods publickey,keyboard-interactive
PasswordAuthentication no

Eso debería pedirle su token de autenticación después de que el servidor acepte su clave pública. No debe pedir su contraseña.

Como nota al margen, si desea tener una cuenta de usuario sftp, es probable que deba omitir el autenticador de Google para que funcione. Aquí hay una sugerencia de cómo hacerlo de forma segura utilizando una cárcel sftp. En etc/ssh/sshd_config:

Subsystem sftp internal-sftp
Match User ftp-user
  PasswordAuthentication yes
  AuthenticationMethods password
  ChrootDirectory /path/to/ftp/dir
  ForceCommand internal-sftp

Tendrá que hacer que los permisos en / path / to / ftp / dir solo escriban raíz (por ejemplo chown root:root /path/to/ftp/dir, chmod 755 /path/to/ftp/dirtodos los padres encima de ese directorio también necesitan permisos seguros. La forma en que lo hago generalmente es creando el directorio chroot /home/shared/user, creando un directorio allí (por ejemplo, 'datos') y luego montar el directorio que quiera compartir así:sudo mount -o bind /path/to/ftp/dir /home/shared/user/data

Si sigue todos estos pasos, tendrá una clave pública + inicio de sesión de autenticador de Google para sus usuarios ssh, y una cuenta sftp protegida con contraseña funcional para la transferencia de datos.


Esto funciona muy bien. Y dado que por alguna razón no me siento cómodo comentando la autenticación común, esto fue más ideal que la solución de Linus.
Luke Sapan el

¡Muchas gracias! desperdicié una noche depurando ssh, preguntándome por qué todavía tengo que escribir la contraseña después de pubkey + authcode ......
felix021
Al usar nuestro sitio, usted reconoce que ha leído y comprende nuestra Política de Cookies y Política de Privacidad.
Licensed under cc by-sa 3.0 with attribution required.