☰

ssh-agent no agrega clave cuando se inicia gráficamente

tag-icon • tag-icon ssh kde ssh-agent
ssh-agent no agrega clave cuando se inicia gráficamente

Recientemente agregué el siguiente script a mi inicio automático (en KDE):

eval `ssh-agent`
ssh-add

El script debe iniciarse al iniciar sesión, solicitar mi contraseña y cargar mi clave secreta. Funciona casi bien. Los scripts se ejecutan correctamente, se inicia el agente, se configuran todas las variables de entorno y se me solicita mi contraseña. El único problema es que la clave no se carga después de eso. Pero si luego ingreso ssh-add en una terminal, se me solicita mi contraseña y la clave se almacena por el resto de mi sesión X.

¿Qué estoy haciendo mal? ¿Por qué no se carga la clave, aunque me solicitan mi contraseña?

PD: Estoy ejecutando Debian jessie.

Respuesta1

Se me ocurren dos escenarios posibles que podrían estar causando esto.

Ambos surgen del hecho de que muchos administradores de escritorio lanzan su propio agente de claves ssh. Esto se hace porque el agente debe iniciarse antes que el administrador de escritorio para que las aplicaciones iniciadas por el administrador de escritorio (su emulador de terminal) recojan las variables exportadas.

  1. Su administrador de escritorio inicia su propio agente ssh después de que usted inicia el suyo y termina reemplazándolo.

    No estoy seguro de en qué momento o cómo está iniciando su agente ssh, pero si el administrador de escritorio inicia uno después del suyo, sus variables exportadas anularán las que usted creó.

  2. Su administrador de escritorio está iniciando su propio agente ssh antes que el suyo, y el suyo no persiste.

    Si simplemente está iniciando una ventana de terminal y haciendo eval $(ssh-agent); ssh-add, entonces las variables exportadas por eso ssh-agentno persistirán después de cerrar la ventana de terminal. Una vez que inicie una nueva ventana de terminal, obtendrá las variables establecidas por el agente ssh iniciado por el administrador de escritorio.

La forma en que ssh-agentfunciona es que inicia un demonio en segundo plano y luego imprime varias variables que deben configurarse.

$ ssh-agent
SSH_AUTH_SOCK=/tmp/ssh-JLbBwVBP4754/agent.4754; export SSH_AUTH_SOCK;
SSH_AGENT_PID=4755; export SSH_AGENT_PID;
echo Agent pid 4755;

Entonces, cuando lo haces eval $(ssh-agent), simplemente estás configurando todas esas variables.

Ahora las variables solo las heredan los hijos, por lo que para que persistan en su administrador de escritorio, deben configurarse antes de que se inicie su administrador de escritorio. Esto puede ser difícil de hacer bien y varía según las distribuciones. Esta es la razón por la que muchos administradores de escritorio lo hacen ellos mismos.
Tenga en cuenta que esto también se hace a veces durante la inicialización de la pila pam.

Respuesta2

Como señala Patrick, es probable que ssh-agentcompita con una instancia generada por su entorno de escritorio. Bueno, competir probablemente no sea la palabra correcta: las variables que permiten a otras aplicaciones comunicarse con el agente deben estar en su entorno. Dado que todas las aplicaciones en su sesión de escritorio son generadas de alguna manera por alguna parte del entorno de escritorio (supongamos que es el administrador de sesión), primero necesita obtener las variables en la lista de entorno del administrador de sesión. Esto puede pasar de dos maneras:

  1. el administrador de sesión lo hace internamente (dependiendo de alguna opción que haya configurado en algún lugar). Esto incluiría que el agente sea generado por un módulo PAM (llamado desde el administrador de inicio de sesión/sesión).

  2. a través de un script de usuario como el suyo. Sin embargo, esto no es tan sencillo como podría parecer. Cuando el administrador de sesión ejecuta su script, crea un nuevo proceso: el intérprete de script. En su entorno, las variables están configuradas, pero no se pueden exportar fácilmente al administrador de sesiones, su proceso principal. Esto equivale a hacer lo mismo en su shell: ejecutar el script no tendrá ningún efecto en el entorno del shell actual. Tendría que sourcehacerlo; entonces los comandos serían ejecutados por el shell actual, lo que le daría acceso a las variables actualizadas/creadas. Esto sería bastante complicado de hacer en el administrador de sesiones (ya que no es un intérprete de shell). Por lo tanto, ssh-agentrealmente no estás compitiendo. Simplemente se queda ahí con identidades cargadas ssh-adddesde su guión y nadie lo sabe realmente.

Para tener una idea de lo que está sucediendo, consulte el resultado de 1

ps fax | grep -E "(ssh|gpg)-[a]gent"

y cambia tu script a

echo "SSH_AUTH_SOCK=$SSH_AUTH_SOCK" > ~/ssh-agent.stdout
echo "SSH_AGENT_PID=$SSH_AGENT_PID" >> ~/ssh-agent.stdout
eval `ssh-agent | tee -a ~/ssh-agent.stdout`

Esto imprimirá el contenido de las variables en el archivo ~/ssh-agent.stdouty luego agregará la salida en ssh-agentese mismo lugar antes de procesarlo (y así exportar las variables). Compare el contenido del archivo con las variables de entorno SSH_AUTH_SOCKy, SSH_AGENT_PIDpor ejemplo, en una terminal Shell recién creada. En la mayoría de los casos, podrá saber cuál se inició primero, ya que los PID crecen (cíclicamente) de manera monótona. La gpg-agentparte está ahí porque algunos DE gpg-agenttambién utilizan la capacidad de proporcionar servicios de agente SSH.

También puede eliminar esa línea de llamada ssh-agentpor completo: si su secuencia de comandos se ejecuta después de que el agente SSH generó su entorno de escritorio, obtendrá el cuadro de diálogo de contraseña (por cierto, para el agente correcto), ya que las variables de entorno estarán presentes. De lo contrario, significa que su script se está ejecutando antes de la instancia del agente DE y, por lo tanto, no tiene acceso a ningún agente.

1 los corchetes son unbuen trucopara eliminarlo grepde la lista de procesos.

información relacionada