¿Existe una forma segura de almacenar contraseñas utilizadas para ssh por un script?

Primero, lo sé, debería usar la autenticación de clave con SSH. No hay necesidad de explicarme eso.

El problema aquí es que tengo un (gran) grupo de servidores, y necesito tener un script para poder conectar cada uno de estos.

Uso una autenticación de clave siempre que puedo, sin embargo, no es posible en todos los servidores (no tengo control sobre esto). Entonces SSH con inicio de sesión, o a veces telnet.

Entonces, para algunos, acabo de almacenar las contraseñas en una base de datos, y mi script lo toma cuando es necesario. El problema es que no parece realmente seguro hacerlo de esa manera. ¿Hay alguna manera de hacerlo un poco más seguro?

¿Te gusta alguna forma específica de almacenarlo?

Si su script puede conectarse a cualquiera de esos servidores, cualquier persona con acceso al script (o acceso privilegiado a la máquina en la que se ejecuta el script) puede conectarse a cualquiera de esos servidores.

Si el script necesita ejecutarse de forma autónoma, todas las apuestas están desactivadas. La respuesta aquí es no, no existe una forma absolutamente segura de almacenar contraseñas en dicho entorno . No hay una forma absolutamente segura y práctica de hacer nada.

En lugar de tratar de evitar lo inevitable, debes concentrarte en la defensa en profundidad .

Fristly, por supuesto, debe proteger las contraseñas adecuadamente . Esto generalmente significa mantenerlos en un archivo separado de su script y configurar permisos restrictivos del sistema de archivos . Eso es todo lo que puede hacer en este frente, desde una perspectiva de seguridad.

Sin duda, otras medidas pueden agregar oscuridad al proceso. Cifrar las contraseñas hará que el atacante necesite buscar la clave de descifrado. El uso de algún tipo de almacenamiento protegido del sistema operativo generalmente protege contra otros usuarios que acceden a su clave (por lo que no ofrece ninguna ventaja sobre los permisos del sistema de archivos, aparte de ser complejo de atacar y usar). Estas medidas retrasarán un ataque, pero ciertamente no lo impedirán contra un atacante determinado.

Ahora, tratemos las contraseñas como públicas por un momento. ¿Qué puedes hacer para mitigar el daño?

Una solución antigua y probada es restringir lo que esas credenciales pueden hacer. En un sistema UNIX, una buena manera de hacer esto es configurar un usuario separado para su script y limitar las capacidades de ese usuario , tanto en el acceso como en los servidores accedidos. Puede limitar las capacidades del usuario en el nivel SSH , en el nivel de shell o posiblemente utilizando un mecanismo de control de acceso obligatorio como SELinux .

Algo que quizás también desee considerar es mover la lógica del script a los servidores . De esa manera, obtienes una interfaz más pequeña que es más fácil de controlar, y especialmente ...

Monitor . Siempre supervise el acceso a los servidores. Preferiblemente, la autenticación de registro y los comandos ejecutados en un registro de solo agregar . No olvide monitorear los cambios en el archivo de script usando auditd, por ejemplo.

Por supuesto, muchos de estos mecanismos no son útiles si no tiene control sobre los servidores, ya que su pregunta parece implicar. Si ese es el caso, le aconsejo que se ponga en contacto con las personas que administran los servidores y les informe sobre su secuencia de comandos y las posibles dificultades de seguridad.

La respuesta corta es no.

La respuesta larga es: No, no hay una forma completamente segura. (Esto incluye variables de entorno, a las que otros pueden acceder en el servidor). Lo más cercano que puede obtener es almacenarlas en algún formato cifrado: keepass, un archivo cifrado por GPG u otra cosa en ese sentido. Pero en algún momento debe descifrar la contraseña para que su script pueda usarla, y en ese momento será vulnerable.

En otras palabras, debe analizar detenidamente la seguridad en profundidad, tanto en el servidor desde el que se ejecuta el script, en la red como en los servidores de destino.

Puede encriptar las contraseñas en su base de datos con una segunda contraseña y almacenar esta contraseña en una máquina separada (tercera) y tener un sistema en el lugar donde el script que necesita contraseñas de la base de datos primero conecta esta tercera máquina para obtener la contraseña de descifrado , descifra la contraseña en la base de datos con la contraseña que obtuvo de la tercera máquina y funciona.

Por supuesto, esto realmente no agrega ninguna seguridad adicional, un atacante con privilegios suficientes también podría simplemente solicitar la contraseña de la tercera máquina.

Pero el punto es que una tercera parte podría controlar la tercera máquina, por ejemplo, su jefe u oficial de seguridad, o la tercera parte en el control de los servidores que usted no controla.

De esta manera, puede decirles, si alguna vez tienen un problema, si renuncia a su trabajo y no confían en el tipo que lo reemplaza, o simplemente quieren que sus scripts dejen de acceder a sus máquinas, pueden desconectar el 3er. máquina, y sus scripts ya no tendrán acceso a las contraseñas.