Creo que una solución adecuada para la mayoría de los casos simples [es decir, si un marco como Puppet/Chef/CfEngine/Ansible es excesivo], pero se requiere un alto nivel de control del sistema remoto es
(a) Requerir autenticación basada en clave (b) bloquear las ubicaciones que SSH puede usar, en particular para bloquear las direcciones IP que los usuarios root pueden usar (c) Asegurarse de que las máquinas con esta relación de confianza estén debidamente protegidas.
No creo que "iniciar sesión como root esté mal visto", tanto como "iniciar sesión como root para hacer cosas que no requieren permisos de root" está mal visto. Tener una contraseña que se pueda adivinar hace posible que la cuenta sea de fuerza bruta, por lo que es un problema con el que lidiar, y al permitir que las personas inicien sesión como root, pueden cometer errores estúpidos con un alcance más amplio y hacer cosas cuestionables que ocultan actividad maliciosa, pero dependiendo de la arquitectura, esto puede no ser significativo.
Este cómic de XKCD señala que, según el entorno, es posible que en realidad no importe si una cuenta raíz está comprometida.
Probablemente, la solución más simple y efectiva para el caso general es limitar exactamente quién puede iniciar sesión como root controlando las claves junto con la especificación de una línea AllowUsers apropiada en /etc/ssh/sshd.conf. Una línea adecuada para permitir a los usuarios normales pero bloquear el acceso de root podría verse así:
AllowUsers normaluser1 normaluser2 [email protected]
Por supuesto, es importante que no se permita el inicio de sesión basado en contraseña, o que la cuenta raíz no tenga una contraseña (es decir, tenga un "!" o "*" en el campo de contraseña del archivo de contraseña).
Como ha postulado, si solo se necesita ejecutar un solo programa (o una pequeña cantidad de) programas, es mejor que configure un usuario específico con autenticación basada en claves y permita el acceso sudo apropiado a los comandos requeridos.
Hay, por supuesto, muchas cosas que se pueden hacer para "bloquear" aún más el acceso, según el valor de los datos:selinux, registro remoto, shell limitado, restricciones de hora del día, notificaciones inmediatas al inicio de sesión. , el monitoreo activo de registros como fail2ban [además de las restricciones de red que veo como no opcionales] pueden ser parte de una solución. Dicho esto, si simplemente está controlando un sistema que puede volar y recrearse fácilmente, es probable que gran parte de esto sea excesivo.
Recuerde que la seguridad se construye en capas, para poder obtener acceso de raíz, una cuenta debe atravesar varias capas. Bloquear el acceso, las claves privadas de SSH, los cortafuegos, las restricciones de hora del día [y el principio de acceso mínimo, es decir, solo proporcionar acceso a lo que se necesita, no más, registros, copias de seguridad] deben funcionar juntos como parte de una buena seguridad.
Adicional:acceso SUDO
Sudo es un mecanismo que permite a un usuario regular ejecutar ciertos comandos con acceso elevado, y es bastante flexible y de alcance variado. Si bien un resumen de sudo no es apropiado aquí (pero está bien documentado si escribe man sudo en la mayoría de las distribuciones, los pasos apropiados podrían ser -
-
Edite /etc/sudoers:la mayoría de las variantes de Linux tienen un programa especial para hacer esto llamado "visudo", que debe ejecutarse como root y es aproximadamente equivalente a usar el editor del sistema para editar /etc/sudoers (que es otra forma de hacerlo). esto - aunque probablemente encontrado)
-
Agregue/cambie las líneas apropiadas para permitir que un usuario determinado haga cosas particulares. Si, por ejemplo, quisiera que pudieran montar directorios por ejemplo y sin tener que ingresar una contraseña, ingresaría una línea como:
username ALL=/sbin/mount NOPASSWD: ALL
Para luego ejecutar este comando, el usuario apropiado ejecutaría algo como
sudo mount /dev/xxx /path/to/mount
Puede enumerar varias líneas para varios comandos, usar grupos en lugar de usar:sudoers es un subsistema bastante flexible. En muchas distribuciones también es posible agregar archivos con comandos a un subdirectorio como /etc/sudoers.d
La siguiente es una respuesta de la publicación Unix Stackexchange
Cómo ejecutar remotamente el comando ssh un comando sudo sin contraseña.
Este método le permite al administrador del servidor permitir que su cuenta ejecute un comando como sudo sin especificar la contraseña. El comando es probablemente la llamada a su secuencia de comandos, y solo está permitido cuando se ejecuta en su cuenta. Como el comando permitido está completamente especificado, incluidos los argumentos, creo que este método es bastante seguro.
puede decirle a Sudo que omita la contraseña para algún comando.
p.ej. en /etc/sudoers
archemar ALL = (www-data) NOPASSWD: /bin/rm -rf /var/www/log/upload.*
esto me permite usar
sudo -u www-data /bin/rm -rf /var/www/log/upload.*
como archemar sin contraseña.
Tenga en cuenta que
sudo -u www-data rm -rf /var/www/log/upload.*
no funcionará (pedirá una contraseña) como rm difieren de /bin/rm .
Asegúrate de editar /etc/sudoers usando visudo comando.
Una vez que haya alcanzado el nivel avanzado, es posible que desee tener su propio sudo archivos en /etc/sudoers.d .