Quiero comunicarme entre varias computadoras en mi red (Ethernet estática), a través de SSH. Para hacer eso, necesito ejecutar ssh-add cada vez que inicio sesión en una máquina específica, ¿cómo puedo hacerlo para que se configure una vez y no me pida la contraseña cada vez que inicie sesión? o reiniciar mi máquina?
Sé que hay una forma en la que debes agregar algunas líneas al archivo bash_profile
, pero aún necesito escribir la contraseña cada vez que reinicio / inicio sesión en una máquina específica.
if [ -z "$SSH_AUTH_SOCK" ] ; then eval `ssh-agent -s` ssh-add fi
Comentarios
- similar a esta pregunta stackoverflow.com/questions/18880024/start-ssh-agent-on-login
- stackoverflow.com/a/52671286/217408 lo resolvió para que pasara la frase de contraseña de bitwarden
- @steampowered sí, pero creo que la respuesta principal dada aquí es mejor y Unix SE es un lugar más apropiado para esta pregunta
Respuesta
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 utilidadkeychain
. Conkeychain
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 unssh-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 queecho "pass\n" | ssh-add
no funciona es quessh-add
no lee la contraseña destdin
, pero abre/dev/tty
directamente para leer. Se actualizó la respuesta para incluir una solución para esto, usando una utilidad llamadaexpect
. - @ 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.
Responder
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 pasarssh-add
argumentos si sus claves privadas están en otro archivo.
Respuesta
No está estrechamente relacionado con la pregunta del OP, pero podría ser útil para otros: ya que 7.2.0 ssh (1) tiene una opción que permite agregar una clave a ssh-agent en la primera autenticación; la opción es AddKeysToAgent
y se puede configurar en yes
, no
, ask
, o confirm
, en todo el sistema o en su archivo .ssh/config
personal.
Referencia : https://www.openssh.com/txt/release-7.2
Comentarios
- Aplicable a aquellos que son nuevos en el archivo
.ssh/config
: esto se aplica assh
y cualquier cosa que usessh
detrás de él, por ejemploscp
, y se puede hacer por host. - Todavía me pide la contraseña cada vez que inicio sesión y trato de git pull, por ejemplo.
- @trainosis El problema es que probablemente no tenga una instancia de ssh-agent ejecutándose para mantener la (s) clave (s) descifrada en la memoria para uso futuro. Solo debe ingresar la contraseña para una clave determinada una vez por sesión de inicio de sesión cuando utilice ssh-agent.
Responder
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.
Respuesta
Aquí hay una solución para automatizar su contraseña SSH.
-
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 :
-
Cree una canalización con nombre (también puede probar una sustitución de proceso ):
mkfifo --mode 0600 ~/.ssh_fifo
-
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 sobreSSH_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.
Respuesta
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:
-
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 )
-
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
oexit
, al igual que ha invocado unbash
shell y es necesario cerrarlo.
Responder
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
Respuesta
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 «?
Responder
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
Respuesta
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.
Respuesta
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.
Respuesta
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.
Responder
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.
Respuesta
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
Respuesta
La mejor forma que conozco es utilizar un script de inicio de sesión de PAM que adapté de trabajos anteriores porque no pude encontrar una respuesta satisfactoria en esta pregunta.
Su frase de contraseña se almacenado cifrado con la contraseña de su sistema y una función de derivación pesada. Al iniciar sesión, su contraseña del sistema se usa para descifrar su contraseña y agregarla al agente.
https://github.com/capocasa/systemd-user-pam-ssh
La ventaja sobre cualquier otra solución presentada es que combina seguridad equivalente a ejecutar ssh-add manualmente en el arranque sin esfuerzo. Requiere no tiene herramientas adicionales y tiene una dependencia adicional que ya está instalada de forma predeterminada en la mayoría de los sistemas (OpenSSL).
Respuesta
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
Respuesta
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>
.