Un enfoque consistente y seguro para cuentas sin contraseña con SSH

Debo admitir que me gustan los servidores sin contraseñas en algunos casos. Un servidor típico es vulnerable a cualquiera que tenga acceso físico a él. Entonces, en algunos casos es práctico bloquearlo físicamente y desde entonces confiar en cualquier acceso físico.

Conceptos básicos

En teoría, cuando llegue físicamente a dicho servidor, debería poder realizar tareas de administración sin contraseña simplemente escribiendo rootcomo inicio de sesión y no se me debe pedir una contraseña. Lo mismo puede aplicarse a las cuentas de usuario, pero en realidad no se accedería físicamente a ellas. Por lo tanto, no se necesitan contraseñas del sistema para el acceso local (ocasional).

Al acceder al servidor de forma remota, ya sea para la administración o para la cuenta de usuario, espero usar siempre una clave privada SSH. Es muy fácil configurar una clave SSH para una cuenta recién creada y, por lo tanto, no se necesitan contraseñas del sistema para el acceso remoto (regular).

# user=...
# 
# useradd -m "$user"
# sudo -i -u "$user"

$ keyurl=...
$
$ mkdir -p .ssh
$ curl -o .ssh/authorized_keys "$keyurl"

La conclusión es que, en teoría, no necesitaríamos ninguna contraseña del sistema para casos de uso como ese. Entonces, la pregunta es, ¿cómo configuramos el sistema y las cuentas de usuario para que suceda de una manera consistente y segura?

Detalles de acceso local

¿Cómo nos aseguramos de que se pueda acceder localmente a la cuenta raíz sin una contraseña? No creo que podamos usarlo, passwd -dya que esto hará que el acceso a la raíz sea demasiado permisivo y un usuario sin privilegios podría cambiar a la raíz de forma gratuita, lo cual está mal. No podemos usarlo passwd -lya que nos impide iniciar sesión.

Tenga en cuenta que el acceso local se trata exclusivamente del acceso mediante el teclado local. Por lo tanto, una solución válida no debe permitir ningún cambio de usuario (ya sea usando suo sudo).

Detalles de acceso remoto

Hasta hace poco, la solución anterior funcionaría, pero ahora SSH comenzó a buscar cuentas de usuario bloqueadas. Probablemente no podamos usarlo passwd -dpor las mismas razones. No podemos usarlo, passwd -uya que solo se queja de que conduciría a lo que passwd -dhace.

Hay una solución alternativa con contraseña ficticia para esta parte.

user=...

echo -ne "$user:`pwgen 16`\n" | chpasswd

También podría ser posible desactivar por completo la cuenta bloqueada en SSH, pero sería mejor retener el soporte de cuentas bloqueadas y simplemente poder desbloquearlas.

Notas finales

Lo que me interesa es una solución que le permita iniciar sesión en la cuenta raíz localmente y en todas las cuentas, incluida la raíz de forma remota, sin ninguna contraseña. Por otro lado, una solución no debe afectar la seguridad, excepto en formas explícitamente descritas, especialmente no permitiendo que los usuarios remotos tengan acceso a la cuenta raíz u otra cuenta de usuario. La solución debe ser lo suficientemente robusta para que no cause problemas de seguridad indirectamente.

Una respuesta aceptada y premiada puede o no describir la configuración detallada de herramientas individuales, pero debe contener los puntos clave para alcanzar los objetivos establecidos. Tenga en cuenta que esto probablemente no puede ser resuelto a través del uso convencional de herramientas como passwd, ssh, su, sudoy similares.

Más ideas después de leer las primeras respuestas.

Solo una idea: el acceso raíz local podría lograrse iniciando shells raíz en lugar de procesos de inicio de sesión. Pero todavía existe la necesidad de bloquear solo la autenticación de contraseña, no la autenticación de clave pública.

Requisitos para los cuales ofreceré soluciones, como viñetas:

1. Inicio de sesión de consola raíz sin contraseña
2. Inicio de sesión remoto root sin contraseña de usuarios preautorizados
3. Inicio de sesión remoto sin contraseña para cuentas específicas de usuarios preautorizados
4. Inicio de sesión remoto sin contraseña para cualquier cuenta de usuarios autorizados previamente

Los siguientes ejemplos están basados ​​en Debian, ya que eso es lo que tengo aquí para probar. Sin embargo, no veo ninguna razón por la cual los principios no puedan aplicarse a ninguna distribución (o de hecho a cualquier derivado * ix basado en PAM).

Inicio de sesión de consola raíz sin contraseña

Creo que la forma en que abordaría esto sería aprovechar PAM y el /etc/securettyarchivo de configuración.

Como requisito previo, se debe establecer una contraseña raíz "suficientemente segura". Esto no es necesario para iniciar sesión en la consola, pero existe para que los intentos de craqueo por fuerza bruta no sean realistas. La cuenta es, por lo demás, una cuenta raíz perfectamente normal.

En /etc/pam.d/loginTengo el siguiente conjunto estándar de líneas para la autenticación (las que comienzan con la palabra clave auth):

auth       optional   pam_faildelay.so  delay=3000000
auth [success=ok new_authtok_reqd=ok ignore=ignore user_unknown=bad default=die] pam_securetty.so
auth       requisite  pam_nologin.so

@include common-auth
auth       optional   pam_group.so

El common-autharchivo de inclusión al que se hace referencia contiene las siguientes líneas relevantes:

auth    [success=1 default=ignore]      pam_unix.so nullok_secure
auth    requisite                       pam_deny.so
auth    required                        pam_permit.so
auth    optional                        pam_cap.so

El common-autharchivo le indica a PAM que omita una regla (la denegación) si un "inicio de sesión UNIX" tiene éxito. Por lo general, esto significa una coincidencia en /etc/shadow.

La auth ... pam_securetty.solínea está configurada para evitar inicios de sesión de raíz, excepto en los dispositivos tty especificados en /etc/securetty. (Este archivo ya incluye todos los dispositivos de la consola).

Al modificar authligeramente esta línea, es posible definir una regla que permita un inicio de sesión raíz sin una contraseña desde un dispositivo tty especificado en /etc/securetty. El success=okparámetro debe modificarse para que okse reemplace por el número de authlíneas que se omitirán en caso de una coincidencia exitosa. En la situación que se muestra aquí, ese número es 3, que salta a la auth ... pam_permit.solínea:

auth [success=3 new_authtok_reqd=ok ignore=ignore user_unknown=bad default=die] pam_securetty.so

Inicio de sesión remoto root sin contraseña de usuarios preautorizados

Esta es una inclusión directa de claves ssh para aquellos usuarios autorizados que se agregan al authorized_keysarchivo raíz .

Inicio de sesión remoto sin contraseña para cuentas específicas de usuarios preautorizados

Esta es también una inclusión directa de claves ssh para usuarios autorizados que se agregan al .ssh/authorized_keysarchivo del usuario correspondiente y correspondiente . (El usuario remoto típico chris quiere un inicio de sesión sin contraseña para el escenario chris del usuario local ).

Tenga en cuenta que las cuentas pueden permanecer en el estado bloqueado predeterminado después de la creación (es decir, solo !en el campo de contraseña /etc/shadow) pero permiten el inicio de sesión basado en la clave SSH. Esto requiere root para colocar la clave en el .ssh/authorized_keysarchivo del nuevo usuario . Lo que no es tan obvio es que este enfoque solo está disponible cuando UsePAM Yesse establece /etc/ssh/sshd_config. PAM se diferencia !como "cuenta bloqueada por contraseña pero se pueden permitir otros métodos de acceso" y !..."cuenta bloqueada. Período". (Si UsePAM Noestá configurado, OpenSSH considera cualquier presencia de !inicio del campo de contraseña para representar una cuenta bloqueada).

Inicio de sesión remoto sin contraseña para cualquier cuenta de usuarios autorizados previamente

No estaba del todo claro para mí si querías esta instalación o no. A saber, ciertos usuarios autorizados podrían iniciar sesión ssh sin una contraseña para cualquier cuenta local.

No puedo probar este escenario, pero creo que esto se puede lograr con OpenSSH 5.9 o posterior, lo que permite authorized_keysdefinir múltiples archivos /etc/ssh/sshd_config. Edite el archivo de configuración para incluir un segundo archivo llamado /etc/ssh/authorized_keys. Agregue las claves públicas de los usuarios autorizados seleccionados a este archivo, asegurándose de que los permisos sean de propiedad de root y tenga acceso de escritura solo por root (0644).

Parece que quiere cuentas de usuario reales (no root) con claves ssh y NOPASSWDacceso completo a través de sudo(que está disponible de forma predeterminada en la mayoría de las distribuciones de Linux en estos días y también es trivial de instalar manualmente). Puede tener contraseñas en blanco para cada cuenta de usuario (que no funcionará de forma remota), luego el usuario se ejecuta sudo -so ~/.bash_profilesimplemente contiene ese comando.

Sudo

Agregue cada usuario al sudogrupo UNIX (p usermod -a -G sudo USERNAME. Ej. , Aunque los sistemas más antiguos tendrán formas menos intuitivas de hacerlo; en el peor de los casos, edita /etc/groupsdirectamente).

En /etc/sudoerso /etc/sudoers.d/local, quieres una línea como esta:

%sudo    ALL=(ALL:ALL) NOPASSWD: ALL

Si desea acceso raíz automático, agréguelo al perfil del usuario. Pues basheso sería ~/.bash_profile:

sudo -s

Esto le permitirá ver quién ha iniciado sesión (intente whoo last) y dejará registros /var/log/auth.log.

Inicio de sesión sin contraseña

En sistemas mucho más antiguos, puede editar /etc/passwd(o en sistemas un poco más antiguos /etc/shadow) y eliminar el hash, por lo que, por ejemplo, se bob:$1$salt$hash:12345:0:99999:7:::vuelve justo bob::12345:0:99999:7:::. Esto era todo lo que necesitabas. A los sistemas modernos no les gusta esto. Probablemente hay otras formas de hacer esto, pero la forma que acabo de verificar es la siguiente ^{_{(fuente: Cosas al azar de Leo )}} :

Abra /etc/shadowy observe una cuenta con información real. Esto incluirá tres elementos delimitados por signos de dólar ( $). Estos representan el mecanismo de hash, luego la sal , luego el hash. Tenga en cuenta la sal, luego ejecute esto:

openssl passwd -1 -salt SALT

(Esto usa MD5 como mecanismo de hash. Es una contraseña en blanco, por lo que no debería importarle). Cuando se le solicite una contraseña, presione enter. Guarde esa cadena, incluidos los puntos finales, y péguela después del primer colon en la línea de ese usuario /etc/shadow(esto debería reemplazar cualquier contenido preexistente entre el primer y el segundo colon). (¡No lo uses literalmente SALTcomo tu sal!)

SSH

Su sshconfiguración de demonio vive en /etc/sshd_configo /etc/ssh/sshd_config. Para una seguridad adecuada, le recomiendo que incluya estas líneas:

PermitRootLogin no
PermitEmptyPasswords no

Consulte la escritura de Secure Secure Shell para conocer las medidas de seguridad adicionales que puede agregar a su configuración ssh para fortalecerla mejor contra los atacantes sofisticados.

Ahora sus usuarios no pueden iniciar sesión a través sshde tener contraseñas vacías (esta es una medida de seguridad necesaria). Esto significa que solo pueden iniciar sesión con claves ssh.

Cada usuario, para cada uno de sus sistemas cliente, debe crear un par de claves ssh, p. Ej.

ssh-keygen -t rsa -b 4096 -f $HOME/.ssh/id_rsa -o -a 100 -C "Bob Roberts on his laptop"

Esto produce una clave privada en $HOME/.ssh/id_rsay una clave pública en $HOME/.ssh/id_rsa.pub. Haga que ese usuario le envíe sus claves públicas y las agregue a las de este servidor $HOME/.ssh/authorized_keys(tenga en cuenta que cada usuario $HOME/.sshdebe estar en modo 700, por ejemplo mkdir -p ~user/.ssh && chmod 700 ~user/.ssh).

Los usuarios que no desean claves ssh pueden ser dirigidos al sistema físico. Allí, su contraseña en blanco los iniciará sesión, momento en el que pueden escribir passwddesde el shell y establecer una contraseña, lo que les permite el acceso remoto.

(De hecho, utilicé esta técnica para dar a las personas acceso a una colección de sistemas cuando dirigía un departamento de TI. Obligó a los usuarios a usar claves ssh y no tuve que darles contraseñas. Sus iniciales ~/.bash_profiletenían dos líneas en la parte inferior: passwdy luego mv ~/.bash_profile.real ~/.bash_profilepara que establezcan una nueva contraseña en el primer inicio de sesión).

Riesgos

Está depositando plena confianza en sus usuarios. No hay nada que impida que un usuario se meta con el ~/.ssh/authorized_keysarchivo de otro usuario y, por lo tanto, altere su capacidad de revocar y auditar el acceso, pero esto es inevitable si está dando acceso completo a la raíz.

Conclusión

Cada usuario ahora es miembro del grupo sudo y tiene acceso completo sin contraseña a un shell raíz. Estos usuarios no tienen contraseñas para sus cuentas y pueden iniciar sesión de forma remota con las teclas ssh.

Si pierde a uno de sus empleados, puede eliminar su cuenta. Si le roban una de las computadoras portátiles de sus empleados, puede eliminar la clave ssh de esa computadora portátil del authorized_keysarchivo de ese usuario . Si tiene una violación de seguridad, tiene registros que muestran quién inició sesión.