¿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?

ssh password password-management

— wokati
fuente

Variables Env. Duplicar desde SO: stackoverflow.com/a/4410137/2579527

— Travis Stoll

@TravisStoll Las variables de entorno no son seguras.

— Jenny D

Me temo que para su configuración, el almacenamiento de las contraseñas en una base de datos es lo más seguro posible. Puede convertirlo en una base de datos cifrada, como un archivo keepass (creo que hay al menos un módulo perl para acceder a la base de datos keepass), pero aún así tendría que almacenar la contraseña en la base de datos en algún lugar, si no desea ingresar cada vez que invocas tu script. Tal vez un poco mejor IFF ingrese solo la contraseña maestra cada vez que invoque su script.

— Isaac

Incluso si usa claves de autenticación SSH en lugar de contraseñas, eso es una garantía de seguridad: cualquiera que pueda robar su base de datos de contraseñas podría robar su clave privada. Puede encriptar su clave privada tal como podría encriptar su base de datos de contraseñas, pero dado que su script necesita desbloquear la clave (o la base de datos de contraseñas), aún es vulnerable a un atacante. El uso de contraseñas en lugar de claves aumenta un poco su vulnerabilidad, ya que abre más vías para robar la contraseña, pero incluso el uso de claves en lugar de contraseñas no es una seguridad perfecta.

— Johnny

"a veces telnet" parece implicar que la contraseña a veces incluso se transferirá de forma clara por cable ...?

— Hagen von Eitzen

Respuestas:

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.

— goncalopp
fuente

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.

— Jenny D
fuente

No estoy tan seguro de que este sea un NO definitivo. Su sesión es segura; el sistema de archivos podría ser seguro, con los permisos adecuados establecidos; así que si puede obtener cosas del sistema de archivos (una contraseña almacenada) y canalizarlas a través de stdin al comando ssh, debería estar bien, ¿no? Por favor vea los enlaces que di en otro comentario arriba. ¿Qué piensas?

— pgr

Si los canaliza a través de stdin, entonces hay una vulnerabilidad. Con sus sugerencias será más seguro, pero no será completamente así. Especialmente dado que algunas de las sesiones se realizan a través de Telnet.

— Jenny D

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.

— Jens Timmerman
fuente