¿Cuáles son las diferencias entre esas formas de usar el Agente de SSH?

Tengo una pregunta sobre las diferentes formas, significados y errores usando el Agente SSH.

Estoy usando Ubuntu 14.04 LTS en Amazon Web Services.

¿Cuáles son las diferencias entre las diferentes formas de usar el Agente de SSH?

Este es el primero:

eval 'ssh-agent -s'
ssh-add id_rsa

Para comprobar si este paso funciona, uso el comando. ssh localhost para comprobar si la conexión no me pide la frase de contraseña.

Sin embargo, otras veces que usé este comando obtuvimos una conexión rechazada o la conexión nos solicitó la contraseña. Luego, para resolver este problema, encontré otra forma:

eval "$(ssh-agent)"
ssh-add id_rsa

Sin embargo, a veces obtenemos una conexión rechazada o la conexión nos pide la frase de contraseña, pero encontré una tercera forma de resolver el problema:

exec ssh-agent bash
ssh-add id_rsa

El problema es que no entiendo la razón, porque a veces tengo que usar una u otra, con la misma distribución (Ubuntu 14.04 LTS) en el mismo servicio (AWS). ¿Cual es la diferencia entre ellos?

— CGG
fuente

¿Existe esto en un contexto más amplio? Si siempre estas corriendo ssh-add De todos modos, ¿por qué el cheque? Para una explicación de eval verifique la página del manual o esta pregunta. El segundo ejemplo ejecutaría lo que sea devuelto por ssh-agent en lugar de obtener el valor de retorno de ssh-agent. Para la última visita la página del manual de exec.

— Seth

Hago la verificación para verificar que siempre funcione correctamente, porque si ssh-add no agregó correctamente la clave, entonces el programa (Hadoop) no funcionará. Por eso, si la comprobación no funcionó, tengo que hacer una de las siguientes formas de configurar Hadoop correctamente.

— CGG

¿Está ejecutando esos comandos manualmente y verifica la salida o tiene un script real que contiene lógica para hacer la verificación? Si lo haces manualmente, ¿no debería ser evidente la diferencia por el tipo de salida que se genera? Lo más probable es que haya algún otro error de configuración en tu extremo. ¿Leíste la página del manual para ssh-agent tiene una explicación para el -s camino.

— Seth

A mano. Pongo las líneas que he escrito arriba. Básicamente, el problema es que siempre he usado la misma distribución, con la misma configuración y los mismos pasos, pero a veces la primera opción no funcionó. La primera vez que sucedió, encontré la segunda solución, y otra vez que la segunda no funcionó, encontré la tercera. Sin embargo, las diferentes publicaciones (algunas de stackoverflow) nunca explicaron los problemas porque tiene que usar otro comando diferente para hacer lo mismo en caso de que el primero falle.

— CGG

Sí, he leído y dije: '-s: Generar comandos de shell Bourne en stdout. Este es el valor predeterminado si SHELL no parece ser un estilo de shell csh ". No soy un maestro en Linux, pero supongo que puedes usar diferentes bash o estilos para ejecutar los programas, ¿quizás?

— CGG

Aquí hay 2 reglas para empezar:

A menos que use explícitamente TCSH o similar, usará Bash, por lo que -s argumento es redundante
En Bash, eval no le importa el nivel de cotización, lo que significa que eval "1 2" y eval 1 2 Hará exactamente lo mismo. Sin embargo, las citas todavía cambian la interpretación de los caracteres en el interior:
```
print_args () { while [ $# -gt 0 ]; do echo "$1"; shift; done; }
eval "print_args 1 '2 3' 4"   # prints "1", "2 3", "4"
eval print_args 1 '2 3' 4     # prints "1", "2", "3", "4"
```

Con esto en mente, esto es lo que hacen estos:

eval 'ssh-agent'
eval ssh-agent

Con cualquiera de estos, la cadena ssh-agent es analizado por su shell (Bash) en el comando ssh-agent, y ejecutado. Este comando comienza ssh-agent en el fondo, e imprime algunas configuraciones a la salida estándar, como SSH_AUTH_SOCK=.... Sin embargo, estos ajustes son no interpretado por su shell, que a su vez significa que el shell no sabrá cómo ponerse en contacto con el agente. De hecho, la ssh-add comando probablemente producirá el error: Error connecting to agent: Connection refused. Por esta razón, este comando es Nunca útil. Tal vez quisiste reemplazar las comillas simples ' con citas atrás? (Desafortunadamente, no sé cómo recuperar las cotizaciones para aparecer en los fragmentos de código en línea aquí).

eval "$(ssh-agent)"
eval $(ssh-agent)
eval "`ssh-agent`"
eval `ssh-agent`

Con cualquiera de estos, Bash realiza por primera vez. sustitución de comandos . Por lo tanto, se ejecuta ssh-agent, esto comienza el programa ssh-agent en el fondo, y las configuraciones de salida como SSH_AUTH_SOCK=.... Ahora comienza la sustitución, por lo que Bash reemplaza $(ssh-agent) por su salida SSH_AUTH_SOCK=.... Segundo, el eval Se ejecuta, pero ahora en esos comandos intermedios: eval SSH_AUTH_SOCK=.... De esta manera, la configuración de salida por ssh-agent se importan en el shell en ejecución, por lo que ssh-add sabrá cómo encontrar el ssh-agent proceso. Por lo general, esto es lo que quieres hacer.

exec ssh-agent bash

Esto reemplaza su shell actual por uno donde la configuración de salida por ssh-agent Ya están incorporados. Sin embargo, esto destruye cualquier otra personalización del shell, porque el nuevo shell no los tendrá. Esta es una buena manera de agregar la configuración de ssh-agent, pero solo cuando no te importa tu shell actual.

Con todo esto dicho, no debería haber diferencia en cómo subsiguiente ssh user@server los comandos funcionan entre las opciones 2 y 3. Las diferencias que esté viendo ("a veces") no se deben a ssh-agent o la configuración del shell, sino más bien, a las condiciones de la red.

A un lado, contar ssh para conectarse sin intentar usar la autenticación de contraseña, pruebe uno de los siguientes:

ssh user@server -o BatchMode=true
ssh user@server -o PreferredAuthentications=publickey

— Matei David
fuente