Aut. de clave SSH, ¿pero aún necesita una contraseña para sudo?

Estoy probando un enfoque diferente que no requiere la creación y administración de contraseñas: configuro la autenticación basada en clave con la clave pública del usuario, la autenticación deshabilitada basada en contraseña para ssh y configuro las cuentas de usuario con un valor vacío pero caducado contraseña ( passwd -de ). De esa manera, los usuarios reciben una solicitud en su primer inicio de sesión y pueden elegir sus propias contraseñas.

Me siento un poco incómodo con la contraseña vacía pero, por lo que puedo decir, está bien siempre que la autenticación de contraseña para ssh esté deshabilitada y no haya otros servicios en ejecución que requieran autenticación (IMAP o algo así). ¿Alguna opinión sobre esto?

En mi opinión, sudo para los administradores de servidores es un poco excesivo. Si las personas inician sesión y tienen acceso de root (a través de algún mecanismo), generalmente realizan tareas de mantenimiento, donde usarán sudo para > 90% del tiempo. El propósito de sudo es dar a las cuentas que están registradas una separación entre las aplicaciones que no son de confianza y las tareas similares a las de un administrador, y hacer que los usuarios sepan que están cambiando el sistema (y que deben tener cuidado). Para los escritorios, ambos se aplican. Sin embargo, para los servidores, la mayoría de las tareas ya requieren sudo, por lo que ambos puntos se debilitan. sudo tiene algunas ventajas con su control de grano fino, pero para confiar en sus capacidades de registro, deberá configurar el registro remoto, ya que de lo contrario las personas con acceso raíz pueden falsificar los registros anteriores.

  

¿Hay alguna advertencia de seguridad que estoy perdiendo por qué esto no es más ampliamente   adoptado?

pam_ssh_agent_auth requiere el reenvío de ssh-agent para funcionar sobre ssh. Entonces, sin embargo, es un poco inútil usarlo, ya que entonces todos los procesos (no agrupados) que se ejecutan bajo la cuenta del usuario podrían usar el agente para ejecutar comandos como root. Esto permite que cada proceso de este tipo ejecute sudo , que es precisamente lo que hace el parámetro NOPASSWORD .

Mi consejo sería tener NOPASSWORD y estar contento con él. Todavía le da a la gente la sensación de "ahora cambio el sistema", pero no tiene contraseñas molestas.

Si aún desea tener contraseñas, puede enviarlas por correo electrónico de manera clara, pero debe cambiarlas la primera vez que se utilicen. Un atacante necesitaría tanto el correo electrónico como la clave privada del usuario para tener éxito. Si ya tienen acceso a la clave privada, podrían hacer cosas desagradables para .bashrc y obtener acceso la próxima vez que el usuario obtenga sudo con una contraseña que el atacante no necesita saber.

Sugiero evitar incluso instalar sudo en sus sistemas: es un vector de ataque adicional que generalmente no tiene justificación para tenerlo. Escribí un artículo sobre el uso de sudo (mis) si está interesado en obtener más información sobre el tema: enlace

Re: la pregunta original: si necesitas que un comando sin privilegios sea ejecutado por usuarios sin privilegios, puedes utilizar el siguiente truco:

1. generar una clave SSH sin frase de contraseña
2. anteponga la parte pública con lo siguiente: from="127.0.0.1",command="your_desired_command_here",no-pty,no-port-forwarding,no-agent-forwarding (también puede restringir la sesión SSH más adelante, consulte "man sshd"). Tenga en cuenta que la clave debe estar separada de este encabezado por un carácter de espacio.
3. instala esa clave pública en la cuenta privilegiada ~ / .ssh / authorized_keys
4. proporcione al usuario la clave privada (o cree un script que simplemente haga SSH a través de la interfaz de loopback a la cuenta privilegiada usando la clave privada)

Por ejemplo, si la cuenta privilegiada es r_service (creada con useradd -om -u0 -g0 -d /root/service -s /bin/bash r_service ), la llamada a ese comando privilegiado desde una cuenta no privilegiada sería algo así como:

$ ssh -i ~/.ssh/privileged_command r_service@0

De esta manera, otorgará a sus usuarios la ejecución de ese comando privilegiado sin comprometer el modelo de seguridad.

La autenticación SSH y los privilegios de seguridad son dos cosas diferentes, por lo tanto, no tiene sentido tenerla como una característica predeterminada. Sin embargo, abre un vector más para el ataque (hay un CVE ) y desde mi punto de vista lo hace más fácil para los usuarios para abusar de ella, lo que es malo.

Sobre el tema de las contraseñas, una forma es enviar una contraseña de corta duración al usuario y pedirle que la cambie después del inicio de sesión inicial. O permítales "registrar" su cuenta y solo trabajar con el hash. Hay ventajas y desventajas en cada enfoque, pero un buen lugar para inspirarse son los servicios comerciales y gratuitos de la cuenta Shell.