Encaminhamento de SSH Agent usando nomes de usuários e chaves diferentes

Question

Há uma pergunta muito semelhante que, se respondida, pode ter sido a resposta a essa pergunta. Infelizmente, é um caso de "não há necessidade de responder à pergunta que fiz porque o problema não era o que eu pensava que era".

A configuração

1. O servidor bastion.ec2 aceita uma conexão ssh da minha estação de trabalho via ssh -i mykey.pem [email protected]
2. O servidor service1.ec2 aceita conexões ssh somente de bastion.ec2 via ssh -i sharedkey.pem [email protected]

Os requisitos

1. Ambas as chaves são apenas na minha estação de trabalho , por isso não posso realmente executar o segundo comando sem copiar a chave
2. Por motivos de segurança, quero usar o encaminhamento de ssh-agent em vez de copiar as chaves ssh para bastion.ec2

A solução

É aqui que você entra. Como posso encaminhar uma chave diferente para a segunda conexão?

Se o shareduser tivesse mykey.pub no seu ~/.ssh/authorized_keys , isso funcionaria:

ssh -i mykey.pem [email protected] ssh [email protected]

No entanto, não quero que todos os usuários precisem colocar a chave pública em todos os servidores.

    

Answer 1

Etapa 1

Certifique-se de que seu agente local esteja pronto

Só porque você pode usar ssh em seu servidor de bastiões sem especificar o caminho da chave ou ser solicitado a fornecer a senha, doesn ' Isso significa que seu agente ssh está executando e segurando sua chave. Alguns sistemas operacionais modernos (por exemplo: OSX) lidam com isso para você.

Na sua máquina local

$ ssh-add -L
ssh-rsa ObahfCbvagGbLbhSbeHfvatEBG13== ~/.ssh/mykey.pem
ssh-rsa LbhNerWhfgJnnlGbbPyrireEBG13== ~/.ssh/sharedkey.pem

^fig.1

Isso significa que seu agente está em execução e tem sua chave.

$ ssh-add -L
The agent has no identities.

^fig.2

Isso significa que você não adicionou nenhuma chave ao seu agente. Corrigir isso com:

ssh-add ~/.ssh/mykey.pem ~/.ssh/sharedkey.pem

^fig.3

Etapa 2

Certifique-se de que seu agente remoto esteja pronto

SSH no seu servidor de bastiões e repita o cheque de fig.1 & fig.2 . No entanto, o erro que você tem mais chances de obter é o seguinte:

$ ssh-add -L
Could not open a connection to your authentication agent.

^fig.4

Isso provavelmente significa que seu cliente SSH não está encaminhando sua conexão com o agente de autenticação.

Você pode forçar isso com o sinalizador -A (desde que a configuração sshd no servidor permita, que é o padrão ).

$ ssh -A bastion.ec2

^fig.5

Etapa 3

Verifique se você está usando as teclas certas

Se você adicionou chaves ao seu agente, seu agente está encaminhando e seu agente remoto lista suas chaves locais. Existem apenas duas razões prováveis para você não estar obtendo uma conexão. Ou você não está usando a chave certa ou não está usando o nome de usuário correto.

Envie a contraparte pública para sua chave privada:

$ cd
$ cd .ssh
$ ssh-keygen -y -f mykey.pem
ssh-rsa ObahfCbvagGbLbhSbeHfvatEBG13
$ ssh-keygen -y -f sharedkey.pem
ssh-rsa LbhNerWhfgJnnlGbbPyrireEBG13

^fig.6

Estes devem ser os mesmos que você estava vendo de ssh-add -L até o == perto do fim.

Agora, de uma forma ou de outra, você precisa entrar na caixa em que não está conseguindo se conectar e examinar o conteúdo do arquivo $HOME/.ssh/authorized_keys do usuário com o qual está tentando se conectar. Você precisa ter certeza de que a chave pública que você imprime com o comando acima está nesse arquivo em uma linha por si só. Você não pode confiar que o sharedkey.pub que os cubos do Bro 2 enviaram por e-mail está correto. Verifique! Isso pode exigir que alguém que possa usar o SSH como usuário, obtenha o arquivo authorized_keys ou obtenha acesso root. Se você chegou até aqui e ainda não está funcionando, você está além de tomar atalhos.

Etapa 4

Facilite

Espero que os passos acima tenham o ajudado. Agora vamos fazer essa dor de cabeça desaparecer enquanto você estiver usando esta estação de trabalho.

Configure seu ssh-client local

Host *
    # A lot of people put an IdentityFile line in this Host * section.
    # Don't do that unless you will use only 1 key everywhere forever.
    #IdentityFile id_rsa

Host bastion.ec2
    # You want to make sure you always forward your agent to this host.
    # But don't forward to untrusted hosts. So don't put it in Host *
    ForwardAgent yes
    # Go a head and put the IP here in case DNS ever fails you.
    # Comment it out if you want. Having it recorded is a good backup.
    HostName 172.31.0.1
    # You don't want to create a proxy loop later, so be explicit here.
    ProxyCommand none
    # SSH should try using all keys in your .ssh folder, but if you
    # know you want this key, being explicit speeds authentication.
    IdentityFile ~/.ssh/mykey.pem

# Connect effortlessly by hostname or IP address
# This assumes that your internal DNS uses the fake TLD ec2
# This assumes that 172.31.0.0 is your C-Class subnet
Host *.ec2 172.31.*
    # This command says proxy all ssh connections through bastion as if
    # you had done an ssh -A
    ProxyCommand ssh -W %h:%p bastion.ec2
    ForwardAgent yes
    # These next lines are documentation you leave as a love letter to
    # your future self when all else fails or you have to help a
    # coworker and decide to look at your own config.
    # ssh-add ~/.ssh/*.pem
    # ssh -At bastion.ecs ssh [email protected]

^fig.7

Se você não tirar mais nada de fig.7 , deve ser o uso adequado de ProxyCommand & ForwardAgent .

Preencher seu .bash_profile

automaticamente

Você não precisa fazer ssh-add manualmente toda vez que fizer login em sua máquina. ~/.bash_profile é um script que é executado toda vez que você faz o login **. Coloque a linha de fig. 3 lá e você sempre deve ter seu agente pronto.

** Não confunda isso com .bashrc , que é executado para cada novo terminal [interativo]. Seu agente continua em execução mesmo se você fechar todas as suas sessões de terminal. Não precisa recarregar suas chaves

Alternativa ao uso de .bash_profile

Eu também criei uma essência que adiciona um Agente de Lançamento do OSX / macOS . Você pode usar esse método para iniciar seu ssh-agent na inicialização. É muito fácil de instalar:

curl -sSL https://gist.github.com/RichardBronosky/429a8fff2687a16959294bcee336dd2a/raw/install.sh | bash

    

Answer 2

This is where you come in. How can I forward a different key for the 2nd connection?

Você não encaminha as chaves. Você encaminha agente e pode ter chaves completamente independentes do que você está usando para autenticação no primeiro salto. Verifique as chaves no seu agente usando ssh-add -L .

Mas, melhor ainda, execute a conexão acima de ProxyCommand ssh -W %h:%p [email protected] , o que evitará a necessidade de encaminhar o agente, as opções de heap ou de linha de comando e a necessidade de autenticar a partir do host imediato.

Você pode simplesmente colocar isso na sua configuração (veja man ssh_config ).