Configurando o arquivo de configuração do ssh com id_rsa através do túnel

Question

Eu tenho lutado para configurar uma configuração válida para abrir uma conexão com uma segunda máquina, passando por outra, e usando um id_rsa (que me solicita uma senha) para conectar-me à terceira máquina.

Eu fiz esta pergunta em outro fórum, mas não recebi nenhuma resposta que pudesse ser considerada muito útil.

O problema, melhor descrito, é o seguinte:

Local machine: user1@localhost
Intermediary machine: user1@inter
Remote target: user2@final

Consigo fazer toda a conexão usando pseudo-tty:

ssh -t inter ssh user2@final

(isso me perguntará a senha do arquivo id_rsa que tenho na máquina "inter")

No entanto, para acelerar as coisas, eu gostaria de definir o meu arquivo .ssh / config, para que eu possa simplesmente conectar à máquina "final" usando:

ssh final

O que eu tenho até agora - o que não funciona - é, no meu arquivo .ssh / config:

Host inter
    User user1
    HostName inter.com
    IdentityFile ~/.ssh/id_rsa

Host final
    User user2
    HostName final.com
    IdentityFile ~/.ssh/id_rsa_2
    ProxyCommand ssh inter nc %h %p

O arquivo id_rsa é usado para conectar a máquina do meio (isto requer que eu não digite senhas), e o arquivo id_rsa_2 é usado para conectar a máquina "final" (este requer uma senha).

Eu tentei misturar alguns campos LocalForward e / ou RemoteForward e colocar os arquivos id_rsa na primeira e na segunda máquina, mas não consegui ter sucesso sem configuração alguma.

P.S .: o tópico Eu tentei obter ajuda de:

link

    

Answer 1

MÉTODO 1 (use ssh-key no inter)

Se você quiser manter o fluxo de autenticação

local -- authenticate --> inter -- authenticate (ask password) --> final

Isso não pode ser feito com proxy host .ssh / config.

O que você precisa é o alias do shell bash (espero que você esteja usando o bash).

Em ~/.bashrc , adicione a seguinte linha

alias ssh-final='ssh -t inter ssh [email protected]'

No prompt de comando, basta digitar o seguinte

ssh-final

A seção

final em ~/.ssh/config não é usada.

Detalhes da conexão (1)

ssh -t inter ssh [email protected] pode ser visto como segue

local# ssh inter
inter# ssh [email protected]

local está apenas "falando" com inter . Não há conexão ssh direta ou indireta entre local e final . local está apenas exibindo a saída de ssh [email protected] .

MÉTODO 2 (use a chave ssh no local)

Autenticação com a mesma chave ssh

Host inter
    User user1
    HostName inter.example.com

Host final
    User user2
    Hostname <final.com / final IP Address>
    Port 22
    ForwardAgent yes
    ProxyCommand ssh inter nc %h %p

Copie local ~/.ssh/id_ras.pub para

/home/user1/.ssh/authorized_keys in 'inter'
/home/user2/.ssh/authorized_keys in 'final'

Detalhes da conexão (2)

tunelamento ssh

Antes de entrarmos em detalhes de ProxyCommand , vamos ver o exemplo a seguir

Passo 1, na janela do terminal 1

local# ssh inter -L 2000:final.com:22

Passo 2, na janela do terminal 2

local# ssh localhost -p 2000

No terminal 1, um túnel é configurado entre a porta local 2000 e a porta final.com 22. Qualquer coisa enviada à porta local 2000 será encaminhada para a porta final.com 22 e vice-versa.

No terminal 2, o ssh se conecta à porta local 2000, mas na verdade está se comunicando com a porta final.com 22, que é o sshd.

Com o tunelamento, o cliente ssh local na Etapa 2 é conectado diretamente com o final.com sshd.

A "saída" da porta local 2000, é o tráfego do daemon ssh "bruto".

O uso comum desse túnel é acessar o servidor da Web interno ou o servidor de e-mail. A seguir, um exemplo de servidor da web

local# ssh inter -L 2000:final.com:80

No navegador, use o seguinte URL

http://localhost:2000

Os dois pontos finais do túnel são a porta local 2000 e a porta final.com 80.

Tráfego entrando e saindo do ponto final do túnel "COMO ESTÁ". Vamos chamar esse tráfego "bruto".

ProxyCommand

Host final
    User user2
    Hostname <final.com / final IP Address>
    Port 22
    ForwardAgent yes
    ProxyCommand ssh inter nc %h %p

O ProxyCommand leva um passo adiante. Ele pula a etapa de criar uma porta local e se conectar a ela.

Um cliente ssh executará o comando ever de ProxyCommand e tratará a saída desse comando como tráfego "bruto". Ele está segurando o ponto final local e, em seguida, inicia uma conexão ssh com ele.

Por que um trabalho o outro não?

O seguinte comando

ssh inter nc final.com 22

basicamente significa (1) conectar-se a inter , então (2) em inter , executar o comando nc final.com 22 .

nc - arbitrary TCP and UDP connections and listens

Portanto, nc final.com 22 se conectará à porta final.com, imprimirá todo o tráfego de entrada para stdout e enviará todos os stdin para o outro lado. É um "túnel" entre nc stdin / out e final.com port 22.

Como nc é executado na sessão ssh, todo o stdout é passado de volta para o cliente ssh, como tráfego "bruto". E o cliente ssh pode passar o tráfego para o nc stdin, que terminará na porta 22 do final.com.

Através do "túnel" acima, o cliente ssh local iniciará uma sessão ssh com final.com diretamente.

O seguinte comando

ssh -t inter ssh [email protected]

não funciona com ProxyCommand porque o tráfego não é "bruto" de um daemon ssh. É o stdout de um cliente ssh . A conversa do cliente com o cliente não significa negócios.

Autenticação com ssh-key diferente (configuração original do OP)

Host inter
    User user1
    HostName inter.com
    IdentityFile ~/.ssh/id_rsa

Host final
    User user2
    HostName final.com
    IdentityFile ~/.ssh/id_rsa_2
    ProxyCommand ssh inter nc %h %p

Copie local ~/.ssh/id_ras.pub para

/home/user1/.ssh/authorized_keys in 'inter'

Copie local ~/.ssh/id_ras_2.pub para

/home/user2/.ssh/authorized_keys in 'final'

Ambos os itens acima permitirão o uso a seguir

local# ssh final

Verificação Adicional

Use verbose

local# ssh -v final

Isso deve ajudar a identificar o problema do ssh.

Verifique nc

ProxcyCommand está executando nc on inter . Verifique se nc está realmente disponível em inter .

local# ssh inter
inter# nc final.com 22

Verifique se a chave rsa está configurada corretamente

Se chaves diferentes forem usadas para inter e final , os arquivos a seguir deverão existir na máquina local

local# ls ~/.ssh
id_rsa id_rsa_2 id_rsa.pub id_rsa_2.pub

Como você já pode ssh para inter , verifique a configuração da chave em final . De sua máquina local

local# ssh -t inter ssh user2@final
final# cat .ssh/authorized_keys

Você deve ver o conteúdo de id_rsa_2.pub .

    

Answer 2

Não vi nenhum erro listado ou ssh -v que ajudasse a ver onde ele está desconectado.

Ei cara, você tem quase certo --- a melhor e mais segura maneira é ter ambas chaves na máquina local. Em seguida, você usaria o encaminhamento do ssh-agent para conectar-se em vez de deixar as chaves nas etapas intermediárias. Você também tem a vantagem de precisar digitar sua frase secreta de chave apenas uma vez por logon.

Se você tem um SO moderno / amigável como o Ubuntu (em sua máquina local), isso não deve funcionar sem nenhum * massageamento *. Eu deixei o arquivo de identidade intencionalmente, você não precisará dele.

Seu arquivo de configuração ficaria assim:

Host inter
    User user1
    ForwardAgent yes
    HostName inter.com

Host final
    ForwardAgent yes
    User user2
    HostName final.com
    ProxyCommand ssh inter nc %h %p

Se isso não ocorrer, execute estas etapas para garantir que o ssh-agent esteja em execução:

'ssh-add -l' (lower case L) will list your private keys if any are loaded, or will be blank, or will say can’t connect to ssh-agent, if so, start ssh-agent.
'eval 'ssh-agent'' (those are backticks) starts ssh agent
'ssh-add' will add your key… you can add a path argument if you have a key in a non-default area. At this point you will enter your passphrase.

Há um bom guia explicando como isso funciona, aqui