Este es un ejemplo típico de una compensación entre seguridad y conveniencia. Afortunadamente hay una serie de opciones. La solución más adecuada depende del escenario de uso y del nivel de seguridad deseado.
ssh-key con frase de contraseña, no ssh-agent
Ahora se debe ingresar la frase de contraseña cada vez que se usa la clave para la autenticación. Si bien esta es la mejor opción desde el punto de vista de la seguridad, ofrece la peor usabilidad. Esto también puede llevar a que se elija una frase de contraseña débil para disminuir la carga de ingresarla repetidamente.
ssh-key con frase de contraseña, con ssh-agent
Agregar lo siguiente a ~/.bash_profile
automáticamente iniciará ssh-agent
y cargará las claves ssh al iniciar sesión:
if [ -z "$SSH_AUTH_SOCK" ] ; then
eval `ssh-agent -s`
ssh-add
fi
Ahora se debe ingresar la frase de contraseña en cada inicio de sesión. Aunque es un poco mejor desde una perspectiva de usabilidad, esto tiene el inconveniente de que ssh-agent
solicita la frase de contraseña independientemente de si la clave se usará o no durante la sesión de inicio de sesión. Cada nuevo inicio de sesión también genera una ssh-agent
instancia distinta que permanece ejecutándose con las claves agregadas en la memoria incluso después de cerrar sesión, a menos que se elimine explícitamente.
Para matar ssh_agent
al cerrar sesión, agregue lo siguiente a~/.bash_logout
if [ -n "$SSH_AUTH_SOCK" ] ; then
eval `/usr/bin/ssh-agent -k`
fi
o lo siguiente para ~/.bash_profile
trap 'test -n "$SSH_AUTH_SOCK" && eval `/usr/bin/ssh-agent -k`' 0
ssh-agent
Se puede evitar la creación de varias instancias creando un socket de comunicación persistente con el agente en una ubicación fija en el sistema de archivos, como en la respuesta de Collin Anderson . Sin embargo, esta es una mejora con respecto a la generación de instancias de múltiples agentes, a menos que se elimine explícitamente la clave descifrada que aún permanece en la memoria después del cierre de sesión.
En los escritorios, los agentes ssh incluidos con el entorno de escritorio, como el agente SSH Gnome Keyring , pueden ser un mejor enfoque, ya que generalmente se pueden hacer para solicitar la frase de contraseña la primera vez que se usa la clave ssh durante una sesión de inicio de sesión y almacenar la clave privada descifrada en la memoria hasta el final de la sesión.
ssh-key con frase de contraseña, con ssh-ident
ssh-ident
es una utilidad que puede administrar ssh-agent
en su nombre y cargar identidades según sea necesario. Agrega claves solo una vez, ya que son necesarias, independientemente de la cantidad de terminales, ssh o sesiones de inicio de sesión que requieren acceso a un ssh-agent
. También puede agregar y usar un agente diferente y un conjunto diferente de claves dependiendo del host al que se está conectando o desde el que se invoca el directorio ssh. Esto permite aislar claves cuando se utiliza el reenvío de agentes con diferentes hosts. También permite usar varias cuentas en sitios como GitHub.
Para habilitarlo ssh-ident
, instálelo y agregue el siguiente alias a su ~/bash_profile
:
alias ssh='/path/to/ssh-ident'
ssh-key con frase de contraseña, con keychain
keychain
es una pequeña utilidad que gestiona ssh-agent
en su nombre y permite ssh-agent
que siga ejecutándose cuando finaliza la sesión de inicio de sesión. En inicios de sesión posteriores, keychain
se conectará a la ssh-agent
instancia existente . En la práctica, esto significa que la frase de contraseña debe ingresarse solo durante el primer inicio de sesión después de un reinicio. En inicios de sesión posteriores, ssh-agent
se utiliza la clave no cifrada de la instancia existente . Esto también puede ser útil para permitir la autenticación RSA / DSA cron
sin contraseña en trabajos sin claves ssh sin contraseña.
Para habilitarlo keychain
, instálelo y agregue algo como lo siguiente a ~/.bash_profile
:
eval `keychain --agents ssh --eval id_rsa`
Desde un punto de vista de seguridad, ssh-ident
y keychain
son peores que las ssh-agent
instancias limitadas a la vida útil de una sesión en particular, pero ofrecen un alto nivel de conveniencia. Para mejorar la seguridad de keychain
, algunas personas agregan la --clear
opción a su ~/.bash_profile
invocación de llavero. Al hacer esto, las frases de contraseña se deben volver a ingresar al iniciar sesión como se indicó anteriormente, pero los cron
trabajos seguirán teniendo acceso a las claves no cifradas después de que el usuario cierre sesión. La keychain
página wiki tiene más información y ejemplos.
ssh-key sin frase de contraseña
Desde el punto de vista de la seguridad, esta es la peor opción ya que la clave privada está completamente desprotegida en caso de que quede expuesta. Sin embargo, esta es la única forma de asegurarse de que la frase de contraseña no necesite volver a introducirse después de un reinicio.
ssh-key con frase de contraseña, con ssh-agent
, pasando la frase de contraseña al ssh-add
script
Si bien puede parecer una idea sencilla pasar la frase de contraseña ssh-add
de un guión, por ejemplo echo "passphrase\n" | ssh-add
, esto no es tan sencillo como parece ssh-add
que no lee la frase de contraseña stdin
, sino que se abre /dev/tty
directamente para leer .
Esto puede ser trabajado en torno a expect
, una herramienta para automatizar aplicaciones interactivas. A continuación se muestra un ejemplo de un script que agrega una clave ssh utilizando una frase de contraseña almacenada en el script:
#!/usr/bin/expect -f
spawn ssh-add /home/user/.ssh/id_rsa
expect "Enter passphrase for /home/user/.ssh/id_rsa:"
send "passphrase\n";
expect "Identity added: /home/user/.ssh/id_rsa (/home/user/.ssh/id_rsa)"
interact
Tenga en cuenta que, dado que la frase de contraseña se almacena en texto sin formato en el script, desde una perspectiva de seguridad, esto es apenas mejor que tener una clave ssh sin contraseña. Si se va a utilizar este enfoque, es importante asegurarse de que el expect
script que contiene la frase de contraseña tenga los permisos adecuados establecidos, por lo que solo el propietario de la clave puede leerlo, escribirlo y ejecutarlo.