¿Debo eliminar las contraseñas de los usuarios una vez que configuro la autenticación de clave pública para SSH?

Es mejor usar claves públicas para SSH. Entonces mi sshd_configtiene PasswordAuthentication no.

Algunos usuarios nunca inician sesión, por ejemplo, un usuario sftp con shell /usr/sbin/nologin. O una cuenta del sistema.

Entonces puedo crear un usuario sin contraseña con adduser gary --shell /usr/sbin/nologin --disabled-password.

¿Es esa una buena / mala idea? ¿Hay ramificaciones que no he considerado?

— lonix
fuente

Mientras estas no sean cuentas de usuarios reales, o no necesiten su contraseña para sudoacceder (ya sea por no tener permisos sudo en absoluto o por tener permisos sudo con NOPASSWD), la respuesta que seleccionó debería ser adecuada. Envié una edición sobre esa respuesta para incluir la preocupación de sudo, pero pensé que te lo diría aquí mientras tanto.

— Doktor J

Respuestas:

Si tiene acceso de root al servidor y puede regenerar claves ssh para sus usuarios en caso de que los pierdan

está seguro de que un usuario (como persona) no tendrá varias cuentas de usuario y necesita cambiar entre las de una sesión SSH (bueno, también puede abrir varias sesiones SSH si surge la necesidad)

ellos no necesitan "física" (a través del monitor + teclado oa través de la consola remota de una máquina virtual) de acceso al servidor

ningún usuario tiene sudoacceso con contraseña (es decir, no tiene acceso a sudo o no tiene acceso a sudo NOPASSWD)

Creo que estarás bien.

Tenemos muchos servidores en el trabajo configurados de esta manera (solo algunas cuentas necesitan acceso a la VM a través de la consola remota vmware, las otras solo se conectan a través de SSH con autenticación de clave pública).

— Señor shunz
fuente

También agregaría "sabes que los usuarios nunca tendrán que acceder al sistema desde sistemas remotos que carecen de su clave SSH privada". Y "Estás dispuesto a tratar con usuarios que se encuentran con una situación en la que no pensaste".

— Andrew Henle

La primera condición es IMO no necesaria. Sus usuarios deben crear sus claves ellos mismos. Simplemente autorizas sus claves públicas cuando te las dan. Si pierden una clave, solo generarán otra y reemplazará la anterior en el servidor.

— Christophe Drevet-Droguet

@AndrewHenle Ese es un buen punto, sin embargo, si sshd tiene PasswordAuthentication noun problema diferente (el usuario no podrá iniciar sesión de todos modos).

— lonix

"Nunca" es tanto tiempo. El administrador puede volver a agregar fácilmente la autenticación de contraseña, si surge la necesidad.

— hyde

Bueno, la pregunta se relaciona claramente con las cuentas que definitivamente no inician sesión (y probablemente no deberían), como las cuentas del sistema utilizadas por servicios específicos o usuarios de solo sftp. La pregunta también establece que los usuarios no tienen un shell de inicio de sesión. Para estos tipos de usuarios, creo que es aconsejable deshabilitar explícitamente el inicio de sesión mediante contraseña.

— Christian Gawron

Esta pregunta mencionó originalmente passwd --delete <username> que no es seguro : con eso, el campo de contraseña encriptada /etc/shadowestará completamente vacío.

username::...

Si ha configurado su sshdpara rechazar la autenticación de contraseña, entonces eso es seguro con SSH ... Pero si cualquier otro servicio en su sistema usa autenticación de contraseña y no está configurado para rechazar contraseñas nulas, ¡esto permite el acceso sin contraseña! No quieres esto.

adduser --disabled-passwdproducirá una /etc/shadowentrada donde el campo de contraseña cifrada es solo un asterisco, es decir

username:*:...

Esta es "una contraseña cifrada que nunca se puede ingresar con éxito", es decir, la cuenta es válida y técnicamente permite inicios de sesión, pero hace que la autenticación por contraseña sea imposible de tener éxito . Entonces, si tiene otros servicios basados en autenticación de contraseña en su servidor, este usuario está bloqueado.

Solo los métodos de autenticación que usan algo diferente a la contraseña de cuenta estándar (por ejemplo, las claves SSH) funcionarán para este usuario, para cualquier servicio que use los archivos de contraseña del sistema en este sistema. Cuando necesite un usuario que pueda iniciar sesión solo con claves SSH, esto es lo que desea.

Si necesita establecer una cuenta existente en este estado, puede usar este comando:

echo 'username:*' | chpasswd -e

Hay un tercer valor especial para el campo de contraseña cifrada: adduser --disabled-loginel campo contendrá solo un signo de exclamación.

username:!:...

Al igual que el asterisco, esto hace que la autenticación de contraseña sea imposible de tener éxito, pero también tiene un significado adicional: marca la contraseña como "bloqueada" para algunas herramientas de administración. passwd -ltiene el mismo efecto al prefijar el hash de contraseña existente con un signo de exclamación, lo que nuevamente hace que la autenticación de contraseña sea imposible de usar.

Pero aquí hay una trampa para los incautos: en el año 2008, la versión del passwdcomando que viene del shadowpaquete anterior se cambió para redefinir passwd -lde "bloquear la cuenta" a "bloquear la contraseña". La razón indicada es "por compatibilidad con otra versión passwd".

Si usted (como yo) aprendió esto hace mucho tiempo, puede ser una sorpresa desagradable. Tampoco ayuda a asuntos que adduser(8)aparentemente aún no conocen esta distinción.

La parte que desactiva la cuenta de todos los métodos de autenticación está realmente dando un valor de fecha de caducidad de 1 para la cuenta: usermod --expiredate 1 <username>. Antes del año 2008, passwd -leso se origina en el shadowkit de origen utilizado para hacer esto además de anteponer la contraseña con un signo de exclamación, pero ya no lo hace.

El registro de cambios del paquete Debian dice:

debian / patches / 494_passwd_lock-no_account_lock: Restaura el comportamiento anterior de passwd -l (que cambió en # 389183): solo bloquea la contraseña del usuario, no la cuenta del usuario. Documente también explícitamente las diferencias. Esto restaura un comportamiento común con las versiones anteriores de passwd y con otras implementaciones. Cierra: # 492307

Los historiales de errores para Debian bug 492307 y bug 389183 pueden ser útiles para comprender el pensamiento detrás de esto.

— telcoM
fuente

Gracias por la advertencia ... ¡Voy a editar la pregunta para que nadie cometa ese error!

— lonix

¿Su advertencia también se aplica al caso en el que uso adduser --disabled-passwd, por lo que si algún otro servicio permite la autenticación con contraseña, entonces el usuario puede iniciar sesión sin una contraseña?

— lonix

No, adduser --disabled-passwordespecíficamente hace que la autenticación de contraseña sea imposible para esa cuenta.

— telcoM

Debido a que eliminar la contraseña parece tan inocente pero es tan peligroso, sugiero cambiar el párrafo al respecto por el párrafo sobre el uso, *por lo que es lo primero que la gente lee.

— Capitán Man

Wow, eso es una sorpresa desagradable esperando a suceder ... y, como siempre, aparentemente hay un problema de compatibilidad a quien culpar. Apareció en el passwdcódigo fuente en 2008. ¿No te encanta cuando algo que alguna vez aprendiste y en el que confiabas ya no es así?

— telcoM