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

29

SSH con autenticación de clave pública-privada viene habilitada de forma predeterminada con la mayoría de las distribuciones de Linux. Esto es genial porque cuando creo cuentas para usuarios remotos no tengo que enviarles información confidencial (contraseñas).

Sin embargo, este proceso se vuelve inútil cuando estos usuarios necesitan ejecutar sudo ; el servidor todavía está solicitando sus contraseñas. Eso significa que todavía necesito generar contraseñas para estos usuarios y descubrir cómo obtenerlas de forma segura.

Sé sobre el archivo sudoers y el parámetro NOPASSWORD . Sin embargo, me siento incómodo habilitándolo. Todavía desearía algún tipo de autenticación antes de que los usuarios puedan ejecutar los comandos sudo .

Mientras realizaba una investigación sobre este tema, encontré el proyecto pam_ssh_agent_auth , que a mi entender permite la misma autenticación de clave pública / privada que la utilizada para conexiones ssh pero para el comando sudo .

Parece que con este módulo en su lugar, podemos tener cuentas completamente sin contraseña.

¿Por qué este módulo o proceso similar no forma parte de las configuraciones de distribución de Linux estándar? ¿Hay alguna advertencia de seguridad que me falta por qué esto no se adopta más ampliamente? ¿Por qué se considera que sudo con contraseña es más seguro que sudo de clave pública / privada ?

    
pregunta Mxx 10.11.2014 - 23:21
fuente

4 respuestas

13

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?

    
respondido por el ofrommel 25.03.2015 - 11:40
fuente
6

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.

    
respondido por el user10008 11.11.2014 - 02:41
fuente
6

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 [email protected]

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

    
respondido por el galaxy 18.07.2015 - 14:13
fuente
1

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.

    
respondido por el go2 11.11.2014 - 00:17
fuente

Lea otras preguntas en las etiquetas