¿Cómo puedo ejecutar ssh-add automáticamente, sin una solicitud de contraseña?

Este es un ejemplo típico de una compensación entre seguridad y conveniencia. Afortunadamente, existen varias opciones. La solución más adecuada depende del escenario de uso y del nivel de seguridad deseado.

clave ssh con frase de contraseña, sin 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 contraseña débil para reducir la carga de ingresarla repetidamente.

clave ssh con contraseña, con ssh-agent

Al agregar lo siguiente a ~/.bash_profile se iniciará automáticamente ssh-agent y cargue la (s) clave (s) ssh al iniciar sesión:

if [ -z "$SSH_AUTH_SOCK" ] ; then eval `ssh-agent -s` ssh-add fi 

Ahora la frase de contraseña debe ingresarse en cada acceso. Aunque es un poco mejor desde una perspectiva de usabilidad, tiene el inconveniente de que ssh-agent solicita la frase de contraseña independientemente de si la clave se utilizará 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 del cierre de 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 

La creación de varias ssh-agent puede evitarse si crear un conector de comunicación persistente con el agente en una ubicación fija en el sistema de archivos, como en respuesta de Collin Anderson . Esta es una mejora con respecto a la generación de varios agentes instancias, sin embargo, a menos que se elimine explícitamente, la clave descifrada aún permanece en la memoria después de cerrar la sesión.

En los escritorios, los agentes ssh incluidos con el entorno de escritorio, como Agente SSH de Gnome Keyring , puede ser un mejor enfoque, ya que normalmente se pueden hacer para solicitar el pase frase la primera vez que se usa la clave ssh durante una sesión de inicio de sesión y almacena la clave privada descifrada en la memoria hasta el final de la sesión.

ssh- clave 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, según sean necesarias, sin importar cuántos terminales, ssh o sesiones de inicio de sesión que requieran acceso a un ssh-agent. También puede agregar y usar un agente diferente y un conjunto diferente de claves según el host al que se esté conectado o desde el directorio desde el que se invoque ssh. Esto permite aislar claves cuando se usa el reenvío de agentes con diferentes hosts. También permite usar varias cuentas en sitios como GitHub.

Para habilitar ssh-ident, instálelo y agregue el siguiente alias a su ~/bash_profile:

alias ssh="/path/to/ssh-ident" 

clave ssh con frase de contraseña, con keychain

keychain es una pequeña utilidad que administra ssh-agent en su nombre y permite que ssh-agent siga ejecutándose cuando finaliza la sesión de inicio de sesión. En inicios de sesión posteriores, keychain se conectará a la instancia ssh-agent existente. En la práctica, esto significa que la contraseña debe ingresarse solo durante el primer inicio de sesión después de un reinicio. En inicios de sesión posteriores, se utiliza la clave no cifrada de la instancia ssh-agent existente.Esto también puede ser útil para permitir la autenticación RSA / DSA sin contraseña en trabajos cron sin claves ssh sin contraseña.

Para habilitar keychain, instálelo y agregue algo como lo siguiente a ~/.bash_profile:

eval `keychain --agents ssh --eval id_rsa` 

Desde un punto de seguridad de vista, ssh-ident y keychain son peores que las ssh-agent limitadas a la vida útil de un sesión, pero ofrecen un alto nivel de comodidad. Para mejorar la seguridad de keychain, algunas personas agregan la opción --clear a su ~/.bash_profile llavero invocación. Al hacer esto, las frases de contraseña se deben volver a ingresar al iniciar sesión como se indicó anteriormente, pero los trabajos cron seguirán teniendo acceso a las claves no cifradas después de que el usuario cierre la sesión. La keychain página wiki tiene más información y ejemplos.

clave ssh 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 esta expuesto. Sin embargo, esta es la única forma de asegurarse de que no sea necesario volver a ingresar la contraseña después de reiniciar.

clave ssh con contraseña, con ssh-agent, pasando la frase de contraseña a ssh-add del script

Si bien podría parece una idea sencilla pasar la frase de contraseña a ssh-add desde un script, p. ej. echo "passphrase\n" | ssh-add, esto no es tan sencillo como parece, ya que ssh-add no lee el contraseña de stdin, pero abre /dev/tty directamente para leer .

Esto puede ser solucionado con expect , una herramienta para automatizar la interacción aplicaciones. A continuación se muestra un ejemplo de una secuencia de comandos que agrega una clave ssh utilizando una frase de contraseña almacenada en la secuencia de comandos:

#!/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 como la frase de contraseña se almacena en texto plano en el script, desde una perspectiva de seguridad, esto no es mejor que tener una clave ssh sin contraseña. Si se va a utilizar este enfoque, es importante asegurarse de que la secuencia de comandos expect que contiene la frase de contraseña tenga los permisos adecuados configurados, lo que la hace legible, de escritura y ejecutable solo con la clave propietario.

Comentarios

• De acuerdo, pero cuando pongo su código en ~ / .bash_profile tengo que escribir la contraseña cada vez que inicio sesión, No ‘ tampoco quiero eso. No me preocupa la seguridad en absoluto. echo » pase \ n » | ssh-add no ‘ no funciona
• @ user1607072 Sí, así es como el fragmento ssh-agent en ~/.bash_profile se comporta como se explica en la respuesta. Es posible que desee consultar la utilidad keychain. Con keychain debe ingresar la contraseña en el primer inicio de sesión después del reinicio, pero en los inicios de sesión posteriores, keychain se conectará a un ssh-agent instancia con la clave descifrada en la memoria. Aparte de eso, hay ‘ la opción de generar una clave ssh sin una frase de contraseña, pero esto, por supuesto, no se recomienda.
• @ user1607072 Aunque lo haría fuertemente Sugiera uno de los enfoques más seguros, hay una manera de pasar la frase de contraseña a ssh-add desde un script. La razón por la que echo "pass\n" | ssh-add no funciona es que ssh-add no lee la contraseña de stdin, pero abre /dev/tty directamente para leer. Se actualizó la respuesta para incluir una solución para esto, usando una utilidad llamada expect.
• @ user1607072 Puede ser un poco excesivo para su caso de uso, pero Kerberos en combinación con la compatibilidad con ssh GSSAPI también se puede utilizar para inicios de sesión ssh sin contraseña. El método de autenticación correspondiente en ssh se llama gssapi-with-mic. Esto generalmente se usa en redes más grandes, pero, por supuesto, si tiene interés en esto, podría valer la pena investigarlo.
• @ErickBrown: Ya respondió aquí . La unidad del agente SSH debe detenerse al cerrar la sesión si el usuario persiste deshabilitado en el administrador de inicio de sesión de systemd . Si la persistencia del usuario está habilitada, la instancia de usuario systemd y la unidad del Agente SSH se mantienen en funcionamiento incluso después de que se cierra la última sesión de inicio de sesión.

Agregue esto a su ~/.bashrc, luego cierre la sesión y vuelva a entrar en vigor.

 if [ ! -S ~/.ssh/ssh_auth_sock ]; then eval `ssh-agent` ln -sf "$SSH_AUTH_SOCK" ~/.ssh/ssh_auth_sock fi export SSH_AUTH_SOCK=~/.ssh/ssh_auth_sock ssh-add -l > /dev/null || ssh-add  

Esto solo debería solicitar una contraseña la primera vez que inicia sesión después de cada reinicio. Seguirá reutilizando el mismo ssh-agent mientras siga funcionando.

Comentarios

• muy ordenado , de esta manera, solo tiene un agente ssh en ejecución (: varios agentes como en @thomasNyman ‘ la segunda solución me parece un riesgo de seguridad …
• Después de investigar en varios sitios y leer varias soluciones, esta parece ser la más clara, directa al grano. Muy agradable. +1
• mejor hacer esto: `alias ssh = ssh-check-agent «, y haga que la versión de agente de verificación haga lo anterior. De esa manera: a) solo obtiene un agente yb) solo obtiene el agente si lo necesita
• Creo que -s es el valor predeterminado, por lo que ‘ ya lo estamos haciendo.
• Tenga en cuenta que ssh-add sin argumentos agrega ~/.ssh/id_rsa. Es posible que desee pasar ssh-add argumentos si sus claves privadas están en otro archivo.

ssh-agent almacena en caché varias claves ssh desbloqueadas, por lo que puede tener claves ssh protegidas por contraseñas, pero sin tener que escribirlas cada vez.

Para almacenar en caché las claves desbloqueadas, obviamente necesita desbloquear esas claves. Para desbloquear claves que están bloqueadas con una contraseña, obviamente necesita conocer estas contraseñas.

Cualquier método que no requiera la autorización de un ser humano (por ejemplo, «escribir una contraseña») no solo hará que su sistema inseguro; También hará que todo el propósito del agente ssh carezca de sentido.

Habiendo dicho todo esto, simplemente puede usar claves ssh que no estén protegidas por contraseña (presione Enter cuando se le pregunte para obtener una contraseña durante la generación de claves). Como no hay ninguna contraseña, ssh-agent no necesita pedirte una para (no) almacenarla en caché.

Comentarios

• Estoy de acuerdo, siempre y cuando sus claves tengan los permisos adecuados solo para el usuario, ssh-agent tiene pocas ventajas sobre las claves sin permisos. me gusta ingresar a un servidor de inicio de sesión, y luego, ese servidor tiene un montón de claves sin permiso, cada una de las cuales solo se puede usar para desbloquear otro servidor. el servidor de inicio de sesión no hace nada más, por lo que ‘ es mucho más difícil de piratear / suplantar, etc … los otros servidores no tienen acceso con contraseña, son solo de clave.

Aquí hay una solución para automatizar su contraseña SSH.

1. Cree una secuencia de comandos de una sola línea que imprima su frase de contraseña en la salida estándar, por ejemplo:

    echo "echo MY_SSH_PASSWORD" > ~/.print_ssh_password && chmod 700 ~/.print_ssh_password 

   Importante: asegúrese copia el espacio inicial a para evitar que se guarde la contraseña en su historial .

Y utilice uno de los métodos siguientes.

• utilizando un enfoque de entrada estándar:

  cat ~/.ssh/id_rsa | SSH_ASKPASS=~/.print_ssh_password ssh-add - 

• o método de canalización con nombre :

  1. Cree una canalización con nombre (también puede probar una sustitución de proceso ):

     mkfifo --mode 0600 ~/.ssh_fifo 

  2. Ejecute ssh-add especificando el programa utilizado para la autenticación:

     cat ~/.ssh/id_rsa >~/.ssh_fifo | SSH_ASKPASS=~/.print_ssh_password ssh-add ~/.ssh_fifo 

  Ver: man ssh-add para leer más sobre SSH_ASKPASS.

Comentarios

• El echo my_passphrase es un gran agujero de seguridad. Primero, después de haberla escrito, la contraseña está en texto sin cifrar en el archivo de historial de cualquier shell que use. Y los argumentos de la segunda línea de comandos se pueden leer en todo el mundo en Unix (ps -ef). ¡Nunca ponga contraseñas en argumentos de línea de comando!
• @ceving Agregar espacio inicial adicional resuelve el problema con el archivo de historial. Se agregó información adicional.
• @kenorb: Eso no ‘ no resuelve el problema más grande de la contraseña visible en ps producción. De todos modos, el archivo de historial solo es legible por el usuario propietario, pero las líneas de comando son legibles por todos los usuarios en un sistema.

No le recomendaré ssh-add (que necesita abrir un ssh-agent) al iniciar sesión. Esto se debe a que no puede controlar cuándo finaliza la sección ssh-agent y puede crear un riesgo de seguridad cuando no necesita usar los archivos de claves en una sección de inicio de sesión.

Más bien, recomiendo escribir un script que abra un sub-shell de la sección de ssh-agent, con todos los archivos de claves agregados automáticamente, y que se llame cuando necesitaba usar ssh. Si pudieras adoptarlo, sigue leyendo.

Tendría dos opciones:

1. Eliminar todas las frases de contraseña para sus claves, que tienen seguridad débil si sus archivos clave son robados (por lo tanto, no recomendado )

2. Utilice la misma frase de contraseña para sus claves. Luego, cuando ssh-add keyfile1 keyfile2 ..., solo tendrá que escribir la frase de contraseña una vez, por sección.

En ambos casos, podría escribir el archivo de script «ssh_keys_section.sh» como se muestra a continuación:

#!/bin/bash # This script run a ssh-agent on a sub-shell and automatically ssh-add all keyfiles at once. # This agent ends when you type `exit` to close the sub-shell. exec ssh-agent bash -c "ssh-add /path/to/keyfile1 /path/to/keyfile2 ...; exec bash" 

Comentarios:

• Comando para cambiar o eliminar la frase de contraseña: ssh-keygen -p -f keyfile
• Dentro del sub-shell, puede incluso bifurcar más terminales que comparten el mismo claves desbloqueadas, usando quizás un comando como /path/to/yourterminal & (depende del sistema operativo)

Comentarios

• Por ejemplo, En Windows dentro de Cygwin, /path/to/yourterminal & == > mintty &
• Observación: después del uso, cierre la sesión con ctrl-d o exit, al igual que ha invocado un bash shell y es necesario cerrarlo.

if [ ! -S ${HOME}/.ssh/ssh_auth_sock ]; then eval $(ssh-agent) ln -sf "${SSH_AUTH_SOCK}" ${HOME}/.ssh/ssh_auth_sock fi export SSH_AUTH_SOCK=${HOME}/.ssh/ssh_auth_sock ssh_keys=$(find -E ~/.ssh -type f -regex ".*(rsa$|pem)") ssh_agent_keys=$(ssh-add -l | awk "{key=NF-1; print $key}") for k in "${ssh_keys}"; do for l in "${ssh_agent_keys}"; do if [[ ! "${k}" = "${l}" ]]; then ssh-add "${k}" > /dev/null 2>&1 fi done done 

Solía usar el script mencionado por steampowered, ahora hice el siguiente, porque no deja archivos por ahí.

Trabajando en zsh solo shell.

#!/usr/bin/env zsh AGENT_BIN=`which ssh-agent` AGENT_ADD_BIN=`which ssh-add` AGENT_PID=`ps -fe | grep ${AGENT_BIN} | awk -vuser=$USER -vcmd="$AGENT_BIN" "$1==user && $8==cmd{print $2;exit;}"` if [ -z "$AGENT_BIN" ]; then echo "no ssh agent found!"; return fi if [ "" -eq "$AGENT_PID" ]; then if read -sq "YN?Do you want to unlock your ssh keys?"; then echo "" output=`$AGENT_BIN | sed "s/echo/#echo/g"` eval $output $AGENT_ADD_BIN fi else for f in "/proc/"* do cmdline=`cat "$f/cmdline"` if [ "${AGENT_BIN}" -ef "${cmdline}" ]; then export SSH_AUTH_SOCK=`cat $f/net/unix | grep --binary-file=text -oP "((/[^/]*?)+/ssh-[^/]+/agent\.\d+$)"` export SSH_AGENT_PID=${f##*/} break; fi done fi 

Comentarios

• » Trabajando en zsh shell solo «, está bien, pero ¿por qué su línea shebang indica que solo requiere » sh «?

SSH_ENV="$HOME/.ssh/environment" function start_agent { echo "Initialising new SSH agent..." /usr/bin/ssh-agent | sed "s/^echo/#echo/" > "${SSH_ENV}" echo succeeded chmod 600 "${SSH_ENV}" . "${SSH_ENV}" > /dev/null /usr/bin/ssh-add; } # Source SSH settings, if applicable if [ -f "${SSH_ENV}" ]; then . "${SSH_ENV}" > /dev/null #ps ${SSH_AGENT_PID} doesn"t work under cywgin ps -ef | grep ${SSH_AGENT_PID} | grep ssh-agent$ > /dev/null || { start_agent; } else start_agent; fi 

Dando crédito aquí: https://www.cygwin.com/ml/cygwin/2001-06/msg00537.html

Esta solución también está respaldada aquí: http://mah.everybody.org/docs/ssh

Si está ejecutando seahorse como administrador de contraseñas … Lo que probablemente seas; D

Otra solución que logra el objetivo que estás buscando es simplemente agregar las claves ssh a seahorse para el desbloqueo automático al iniciar sesión . El principal beneficio de esto es que nunca tendrá que ingresar una contraseña para las claves después de iniciar sesión a través de gdm, o lo que sea con lo que inicie sesión, incluso si las claves tienen una contraseña. Esto REQUIERE tanto la clave privada como la clave pública. También DEBEN seguir una convención de nomenclatura para los caballitos de mar. El valor predeterminado es aceptable (id_rsa para clave privada e id_rsa.pub para clave pública … Realmente cualquier cosa que sea privatekeyname y privatekeyname.pub )

Para agregar su clave ssh a seahorse para el desbloqueo automático al iniciar sesión; (en fedora25, no estoy seguro de dónde está la ruta en otras distribuciones, aunque probablemente sea muy similar)

/lib64/seahorse/seahorse-ssh-askpass /path/to/keys/here 

Para mí, fue

/lib64/seahorse/seahorse-ssh-askpass ~/.ssh/id_rsa 

(seahorse asumirá automáticamente que la clave pública en mi caso era id_rsa.pub)

Después de ejecutar el comando, seahorse abrirá un pequeño y lindo campo de contraseña de gtk para ingresar la contraseña de la clave privada. o simplemente déjelo en blanco si generó la clave sin una contraseña.

Seahorse no le preguntará si todo salió bien. Deberá intentar ssh en la máquina de destino.Luego, seahorse le pedirá que desbloquee la clave con una contraseña gráficamente (ESTO SÓLO SUCEDERÁ UNA VEZ) nuevamente, pero esta vez debería verse un poco diferente; P (esta es también la parte en la que seahorse hace algo de caballito de mar para agregar magia ssh, creo ) y ofrece la OPCIÓN para desbloquear la clave al iniciar sesión, debes marcar esta opción para lograr su objetivo.

Solo porque no leí todas las respuestas, recomendaría deshacer lo que todos le dijeron que hiciera con ssh-add antes de intentar esta respuesta. De lo contrario, podría resultar en algo malo a sus claves, idk.

La solución de inicio de sesión único para SSH podría llevarme a pam_ssh .

Según este artículo , el concepto es:

Si trabaja con múltiples máquinas basadas en * nix a través de ssh, probablemente esté cansado de las desventajas tener que ingresar su contraseña cada vez que desee acceder a otra casilla. Existe una forma segura de permitirle acceder a todas las máquinas a las que tiene acceso ssh, sin tener que ingresar otra contraseña (que no sea la que utilizó originalmente).

En realidad, esto es bastante simple de hacer, básicamente crea un par de claves pública / privada para autenticarse en sus otras máquinas, luego tiene PAM genera un agente para cargar sus claves después de iniciar sesión, proporcionando una solución de inicio de sesión único para acceder a todas sus máquinas remotas. Esta guía lo guiará a través de la configuración.

No he verificado que esto realmente funcione.

Agregue esto a su ~/.bashrc archivo:

ssh-add -L|grep identities > /dev/null && ssh-add /path/to/ssh/private/key 

Comentarios

• No ‘ no veo cómo esto se relaciona con la pregunta, que trata de no recibir la contraseña en inicios de sesión posteriores.

Para agregar una clave (posiblemente sin contraseña) y asegurarse de que ssh-add no solicitará una contraseña, pase lo que pase, incluso cuando se ejecuta bajo X :

DISPLAY= ssh-add -k /path/to/key </dev/null &>/dev/null 

El estado de salida indica éxito o fracaso.

Aquí está el definitivo texto.

Actualice $ PASSW, luego cópielo y péguelo en su Terminal

# <sshpass> via typinator # Updated: 2017-01-18_21h36 # # apt-get update -y; apt-get install expect -qy # Pass this value to ssh-add PASSW="myfancypass123" # Define a name for this script THIS_SCRIPT="$(date +%Y-%m-%d_%H-%M-%S-%N)".sh # Create a fresh directory to work from / Clean up rm -rf ~/temp; mkdir -p ~/temp; cd ~/temp; ls -la # Output our bash script file - BEGIN cat <<< " #!/bin/bash set -u # Stop if an unbound variable is referenced set -e # Stop on first error export HISTIGNORE="expect*"; # Normal CMDs echo && echo "The process should take about 10 seconds:" && echo eval "$(ssh-agent -s)"; sleep 0.5; # Define VAR passed when this bash-script was launched password="$@" # Launch the expect magic expect -c " spawn ssh-add /root/.ssh/id_rsa expect "?assword:" send \"$password\r\" expect "?password:" send \"$password\r\" expect eof" export HISTIGNORE=""; export password=""; " > $THIS_SCRIPT # Output our bash script file - END # Ensure we are in the right path cd ~/temp; ls -la; sleep 1; # Run the bash script chmod +x ./$THIS_SCRIPT; ./$THIS_SCRIPT "$PASSW"; unset password; # Clean up rm -rf ~/temp; mkdir -p ~/temp; cd ~/temp; ls -la 

Mi La configuración en macOS es la siguiente (en .zshrc o .bash_profile para la gente de bash):

La parte || [[ $SSH_AUTH_SOCK == *"/private/tmp/"* ]] es necesaria en macOS porque el valor predeterminado es /private/tmp/com.apple.launchd.SOMETHINGHERE/Listeners. De lo contrario, la respuesta completa de @Thomas Nyman falla porque $SSH_AUTH_SOCK siempre se establece en algo.

Luego, en .zlogout (o .bash_logout para la gente de bash):

if [ -n "$SSH_AUTH_SOCK" ] ; then eval `/usr/bin/ssh-agent -k` fi 

Probado en macOS Mojave 10.14.5

Esto ha sido muy bien explicado por GitHub en Ejecución automática de ssh-agent en Git para Windows , que a su vez también funciona para Linux.

Puede ejecutar ssh-agent automáticamente cuando abre bash o Git shell. Copie las siguientes líneas y péguelas en su archivo ~/.profile o ~/.bashrc en Git shell:

 env=~/.ssh/agent.env agent_load_env () { test -f "$env" && . "$env" >| /dev/null ; } agent_start () { (umask 077; ssh-agent >| "$env") . "$env" >| /dev/null ; } agent_load_env # agent_run_state: 0=agent running w/ key; 1=agent w/o key; 2= agent not running agent_run_state=$(ssh-add -l >| /dev/null 2>&1; echo $?) if [ ! "$SSH_AUTH_SOCK" ] || [ $agent_run_state = 2 ]; then agent_start ssh-add elif [ "$SSH_AUTH_SOCK" ] && [ $agent_run_state = 1 ]; then ssh-add fi unset env  

Si su clave privada no está almacenada en una de las ubicaciones predeterminadas (como ~/.ssh/id_rsa), deberá indicarle a su agente de autenticación SSH dónde encontrarlo. Para agregar su clave a ssh-agent, escriba ssh-add ~/path/to/my_key.

Consejo: Si desea que ssh-agent olvide su clave después de un tiempo, puede configúrelo para que lo haga ejecutando ssh-add -t <seconds>.