Quais são as diferenças entre as formas de usar o SSH -Agent?

Question

Eu tenho uma pergunta sobre as diferentes maneiras, significados e erros usando o SSH-Agent.

Estou usando o Ubuntu 14.04 LTS no Amazon Web Services.

Quais são as diferenças entre as diferentes maneiras de usar o SSH -Agent?

Este é o primeiro:

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

Para verificar se esta função de etapa eu uso o comando ssh localhost para verificar se a conexão não me pede a frase secreta.

No entanto, outras vezes em que usei este comando, obtivemos uma conexão recusada ou a conexão solicitou a senha. Então, para resolver esse problema, encontrei outra maneira:

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

No entanto, às vezes nós obtivemos novamente uma conexão recusada ou a conexão nos pede a senha, mas eu encontrei uma terceira maneira de resolver o problema:

exec ssh-agent bash
ssh-add id_rsa

O problema é que eu não entendo o motivo, porque às vezes eu tenho que usar um ou outro - com a mesma distro (Ubuntu 14.04 LTS) no mesmo serviço (AWS). Qual a diferença entre eles?

    

Answer 1

Aqui estão 2 regras para começar:

• A menos que você use explicitamente o TCSH ou algo semelhante, você usará o Bash, portanto, o argumento -s é redundante.

• No Bash, eval não se importa com o nível de cotação, o que significa que eval "1 2" e eval 1 2 farão exatamente a mesma coisa. No entanto, as citações ainda mudam a interpretação dos personagens dentro:

  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"
  

Com isso em mente, veja o que eles fazem:

eval 'ssh-agent'
eval ssh-agent

Com um desses, a string ssh-agent é analisada pelo seu shell (Bash) no comando ssh-agent e executada. Esse comando inicia ssh-agent no segundo plano e imprime algumas configurações para stdout, como SSH_AUTH_SOCK=... . No entanto, essas configurações não são interpretadas pelo seu shell, o que, por sua vez, significa que o shell não saberá como entrar em contato com o agente. Na verdade, o comando ssh-add provavelmente produzirá o erro: Error connecting to agent: Connection refused . Por este motivo, este comando é nunca útil. Talvez você quisesse substituir as aspas simples ' por citações anteriores? (Infelizmente eu não sei como recuperar as cotações para aparecer nos snippets de código embutidos aqui.) Se assim for, leia.

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

Com qualquer um destes, o Bash primeiro executa a substituição do comando . Portanto, ele executa ssh-agent , isso inicia o programa ssh-agent no plano de fundo e gera configurações como SSH_AUTH_SOCK=... . Agora a substituição entra em ação, então Bash substitui $(ssh-agent) por sua saída SSH_AUTH_SOCK=... . Segundo, o eval é executado, mas agora nesses comandos intermediários: eval SSH_AUTH_SOCK=... . Dessa forma, as configurações geradas por ssh-agent são importadas para o shell em execução, portanto, ssh-add saberá como localizar o processo ssh-agent . Normalmente, isso é o que você quer fazer.

exec ssh-agent bash

Isso substitui seu shell atual por um onde as configurações geradas por ssh-agent já estão incorporadas. No entanto, isso destrói outras personalizações de shell, porque o novo shell não as terá. Esta é uma maneira correta de adicionar as configurações de ssh-agent , mas apenas quando você não se importa com o seu shell atual.

Com tudo isso dito, não deve haver diferença em como os comandos ssh user@server subseqüentes funcionam entre as opções 2 e 3. Quaisquer diferenças que você esteja vendo ("às vezes") não se devem a ssh-agent ou as configurações da shell, mas sim às condições da rede.

Como um aparte, para informar ssh para se conectar sem tentar usar a autenticação por senha, tente um dos seguintes:

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