Solución 1:
Me encanta la idea de acceder a los servidores a través de claves, para no tener que escribir mi contraseña cada vez que entro en un cuadro, incluso bloqueo la contraseña de mi usuario (no root) (contraseña -l nombre de usuario) para que sea imposible iniciar sesión sin clave... ¿Recomendaría/no recomendaría hacer esto para una cuenta de usuario en un servidor?
Vas a deshabilitar los inicios de sesión basados en contraseña de forma incorrecta. En lugar de bloquear la cuenta de un usuario, establezca PasswordAuthentication no en tu /etc/ssh/sshd_config .
Con ese conjunto, la autenticación de contraseña está deshabilitada para ssh, pero aún puede usar una contraseña para sudo.
El único tiempo recomiendo configurar NOPASSWD en sudo es para cuentas de servicio, donde los procesos deben poder ejecutar comandos a través de sudo mediante programación. En esas circunstancias, asegúrese de incluir explícitamente en la lista blanca solo el específico comandos que la cuenta necesita ejecutar. Para las cuentas interactivas, debe siempre deje las contraseñas habilitadas.
Respuestas a sus preguntas de seguimiento:
Pero supongo que si deshabilito la autenticación de contraseña en/etc/ssh/sshd_config para que aún tenga que tener una clave para iniciar sesión, ¿puedo usar una contraseña más simple solo para sudo que sea más fácil de escribir? ¿Es esa una estrategia válida?
Si eso es correcto. Todavía recomiendo usar contraseñas de cuentas locales relativamente fuertes, pero no ridículamente fuertes. ~8 caracteres, generados aleatoriamente es suficiente.
Si también tengo una clave para iniciar sesión como root a través de ssh, si alguien obtiene acceso a mi computadora y roba mis claves (¡aunque todavía están protegidos por la contraseña del conjunto de claves del sistema operativo!), también podrían obtener acceso directo a la cuenta raíz, omitiendo la ruta sudo.
El acceso a la raíz a través de ssh debe estar deshabilitado. Período. Establecer PermitRootLogin no en tu sshd_config .
¿Cuál debería ser la política para acceder a la cuenta raíz entonces?
Siempre debe tener un medio para obtener acceso fuera de banda a la consola de su servidor. Varios proveedores de VPS proporcionan esto, al igual que los proveedores de hardware dedicado. Si su proveedor no otorga acceso real a la consola (por ejemplo, EC2, por ejemplo), normalmente aún puede restaurar el acceso mediante un proceso como el que describo en esta respuesta.
Solución 2:
Generalmente restrinjo el uso de NOPASSWORD a comandos que son ejecutados por un proceso automatizado. Es preferible tener una cuenta de servicio para estos comandos y restringir el uso de sudo a los comandos requeridos.
Permitiendo NOPASSWORD para comandos generales, permite que cualquier persona que tenga acceso a su ID de usuario ejecute cualquier comando. Esto podría resultar de un compromiso de sus credenciales, pero podría ser tan simple como que alguien se siente en su escritorio cuando usted se aleja por un segundo.
Veo que no tengo que ingresar mi contraseña con tanta frecuencia. Una vez que ingrese su contraseña, puede ejecutar varios comandos si no espera demasiado entre ellos. El tiempo de espera es configurable.
Solución 3:
Puede tener lo mejor de ambos mundos:autenticación SSH tanto para iniciar sesión como para Sudo. Si integra el módulo pam_ssh_agent_auth, puede usar claves SSH para autenticarse sin dar una contraseña cuando sudo.
He estado usando esto en producción durante más de cinco años.
Para configurarlo, instale el módulo PAM y luego agregue una línea a /etc/pam.d/sudo o el equivalente de su sistema:
auth sufficient pam_ssh_agent_auth.so file=~/.ssh/authorized_keys
Si hace esto, asegúrese de proteger sus claves en su computadora con una frase de contraseña. De esa manera, alguien tendría que ingresar a su computadora y robar las claves para ingresar. Podrían hacerlo extrayéndolas de la memoria mientras estaban desbloqueadas si tienen acceso a su cuenta, descifrando su frase de contraseña o robando su frase de contraseña a través de un registrador de teclas o navegar con el hombro mientras lo escribes (¡mira detrás de ti!).
Puede usar la misma clave SSH que usa para iniciar sesión, o puede configurar una clave separada que solo agregue a su agente cuando sudo. Entonces, si quiere tener más cuidado, puede mantener un archivo de claves_autorizadas separado que tenga una clave SSH separada que solo agregue a su agente cuando necesite sudo:
auth sufficient pam_ssh_agent_auth.so file=~/.ssh/authorized_keys_sudo
Solución 4:
Solo usaría esto en dos circunstancias:
- Cuando es absolutamente requerido para un script automatizado que se ejecuta como un usuario específico
- Para tareas administrativas específicas (tareas administrativas de solo lectura, no aquellas que toman medidas para alterar el sistema) y luego solo para usuarios específicos, por supuesto
De forma predeterminada, la mayoría sudo Las configuraciones no volverán a preguntarte durante un tiempo en la misma sesión (si abres un nuevo shell que no tiene ningún efecto). Puedes controlar este comportamiento hasta cierto punto con el timestamp_timeout ajuste.
Sin contraseña sudo no es tan peligroso como ssh sin frase de contraseña claves, ya que un atacante remoto necesita sus credenciales para ingresar en primer lugar, pero si ingresaron comprometiendo de alguna manera su clave privada (o si son físicamente locales para usted y usted se ha conectado y desbloqueado mientras estaba fuera desde la máquina), entonces la solicitud de contraseña es una valiosa defensa adicional entre ellos y el acceso privilegiado.
Con respecto al seguimiento 2:
Si también tengo una clave para iniciar sesión como root a través de ssh
Esto también es mejor evitarlo, exactamente por la razón que describe. Si una conexión remota debe tener acceso privilegiado, haga que inicie sesión a través de una cuenta de servicio y déle el control suficiente para hacer su trabajo a través de sudo. Esto es más fácil de configurar, por supuesto, por lo que muchos no se molestan (lo que funciona a su favor si lo hace, ¡ya que hay muchos frutos más bajos que usted para que los atacantes pasen el tiempo allí!), por lo que todo se reduce a la antiguo compromiso entre la seguridad y la comodidad (consejo profesional:¡elija seguridad!).
Solución 5:
Ya que preguntaste, aquí tienes mi consejo general sobre cómo abordar el sudo problema.
Sudo no fue diseñado para brindar más seguridad (aunque puede hacerlo en cierto sentido)... sino para proporcionar una buena pista de auditoría de quién está haciendo qué en su sistema con qué privilegios.
Un Sudo correctamente configurado no usará el ALL=(ALL) ALL configuración, sino más bien algo más limitado a lo que sea específicamente que el usuario necesite. Por ejemplo, si necesita que un usuario pueda iniciar sesión y reiniciar un servicio atascado, probablemente no necesite la capacidad de instalar software nuevo o apagar su servidor, cambiar las reglas del firewall, etc.
A veces es común que las personas usen sudo para elevarse a la cuenta raíz, es decir. sudo su - . Una vez que hacen eso, deja de ver quién está haciendo qué desde la cuenta raíz (la raíz puede iniciar sesión varias veces al mismo tiempo). Entonces, a veces la gente quiere deshabilitar el sudo su - mando también. Pero, por razones prácticas, si necesita una cuenta con todos los privilegios de root para la administración, al menos que alguien emita el sudo su - el comando registraría quién se elevó a root y cuándo.
Cómo aseguro mis cajas:
Cambie el puerto SSH a otro que no sea el predeterminado. Esto es para evitar los bots tontos que buscan números de puerto y luego golpean hasta que entran (o no).
Prohibir el inicio de sesión raíz a través de SSH usando el AllowRootLogin no configuración en su sshd_config. Esto evita que alguien haga fuerza bruta en su cuenta raíz. En general, es una buena práctica no permitir nunca que alguien inicie sesión directamente en la cuenta raíz/administrador por razones de auditoría y de seguridad. Si permite el inicio de sesión de root directamente, no sabe quién inició sesión, de quién obtuvo la contraseña, etc. Pero, si alguien inicia sesión en la cuenta de Jimmy y luego eleva sus permisos a root, tiene una mejor idea de dónde comenzar su búsqueda de auditoría (y quién es la cuenta para restablecer).
Permitir SSH solo a los usuarios que lo requieran Usa el AllowUsers configuración y especifique explícitamente qué cuentas necesitan acceso SSH. De forma predeterminada, esto bloqueará todas las demás cuentas de SSH.
Edite Sudoers a través de visudo y permita solo los comandos que el usuario necesita. Hay muchas guías detalladas sobre cómo hacer esto, así que no lo detallaré aquí. Aquí hay un comienzo:http://ubuntuforums.org/showthread.php?t=1132821
La esencia de esto es evitar que una cuenta comprometida ponga en peligro su máquina. es decir. si la cuenta de Sally es vulnerada, y Sally solo puede usar sudo para reiniciar el servidor web, bueno, el atacante podría divertirse reiniciando su servidor web en un bucle, pero al menos no puede rm -rf /your/webserver/directory o abra todos sus puertos de firewall, etc.
Configure buenas reglas de cortafuegos que solo permitan los puertos que sean necesarios para que su decodificador funcione. En general, desea dejar todo y solo permitir explícitamente lo que necesita. Hay muchas iptables decentes y otros inicios de cortafuegos en línea, aquí hay uno que uso (es un inicio básico):
# Generated by iptables-save v1.4.7 on Mon Mar 3 17:55:02 2014
*filter
:INPUT DROP [4528:192078]
:FORWARD DROP [0:0]
:OUTPUT ACCEPT [39845:27914520]
-A INPUT -i lo -j ACCEPT
-A INPUT -p tcp -m tcp ! --tcp-flags FIN,SYN,RST,ACK SYN -m state --state NEW -j DROP
-A INPUT -m state --state RELATED,ESTABLISHED -j ACCEPT
-A INPUT -p tcp -m tcp --dport 4254 -m state --state NEW -j ACCEPT
-A INPUT -p tcp -m tcp --dport 8080 -m state --state NEW -j ACCEPT
-A INPUT -p tcp -m tcp --dport 8443 -m state --state NEW -j ACCEPT
-A INPUT -p icmp -m icmp --icmp-type 8 -j ACCEPT
-A INPUT -p icmp -m icmp --icmp-type 11 -j ACCEPT
-A OUTPUT -o lo -j ACCEPT
COMMIT
# Completed on Mon Mar 3 17:55:02 2014
También es clave una contraseña segura. Incluso si usa claves SSH para su acceso remoto, aún debe solicitar una contraseña para el uso de Sudo. Este es un caso en el que sudo podría proporcionar algo más de seguridad. Si alguien robara sus claves ssh, aún se les impediría hacer algo significativo en su caja si todavía tienen que forzar la contraseña de su cuenta para usar sudo. Las contraseñas no deben ser una palabra, sino una frase de paso. Piensa en una oración y utilízala. Esto generalmente le dará algo más de 8 caracteres, proporcionando mucha entropía, pero también es más fácil de recordar que una contraseña aleatoria. Por supuesto, las buenas prácticas de contraseña dicen usar una contraseña aleatoria generada por una máquina para engañar a las herramientas de craqueo como John the Ripper, que rasgará la mayoría de las frases de contraseña y contraseñas. No, cambiar E con 3 no funciona, John obtiene esas permutaciones también.