Eu tenho lutado para definir 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-se à terceira máquina.

Fiz essa 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

Eu sou capaz de fazer toda a conexão usando pseudo-tty:

ssh -t inter ssh user2@final

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

No entanto, para acelerar as coisas, eu gostaria de definir meu arquivo .ssh / config, para que eu possa simplesmente conectar-me à 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-se à máquina do meio (isso não requer digitação de senha), e o arquivo id_rsa_2 é usado para conectar-se à máquina "final" (esta solicita uma senha).

Tentei misturar alguns campos LocalForwarde / ou RemoteForwardcolocar os arquivos id_rsa na primeira e na segunda máquinas, mas não consegui ter sucesso sem nenhuma configuração.

PS: o tópico em que tentei obter ajuda:

http://www.linuxquestions.org/questions/linux-general-1/proxycommand-on-ssh-config-file-4175433750/

MÉTODO 1 (use a tecla ssh no inter)

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

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

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

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 user2@final.com'

No prompt de comando, digite:

ssh-final

finalseção ~/.ssh/confignão é usada.

Detalhes da conexão (1)

ssh -t inter ssh user2@final.com pode ser visto como segue

local# ssh inter
inter# ssh user2@final.com

localestá apenas "conversando" com inter. Não há conexão ssh direta ou indireta entre locale final. localestá apenas exibindo a saída de ssh user2@final.com.

MÉTODO 2 (use a tecla 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

Copiar 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 ProxyCommand, vamos ver o exemplo a seguir

Etapa 1, na janela do terminal 1

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

Etapa 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 22 do final.com. Tudo o que for enviado para a porta local 2000 será encaminhado para a porta 22 do final.com e vice-versa.

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

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

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

O uso comum desse túnel é acessar o servidor Web interno ou servidor de email. A seguir, é apresentado um exemplo para 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 80 do final.com.

Tráfego que entra e sai do ponto final do túnel "COMO ESTÁ". Vamos chamar isso de tráfego "bruto".

ProxyCommand

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

A ProxyCommanddar um passo mais longe. Ele pula a etapa de criação de uma porta local e se conecta a ela.

Um cliente ssh executará o que já foi dado por trás ProxyCommande tratará a saída desse comando como tráfego "bruto". Ele está segurando o ponto final local e inicie 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 que (1) conecte e inter, em seguida, (2) interexecute o comando nc final.com 22.

nc - arbitrary TCP and UDP connections and listens

Portanto, nc final.com 22ele se conectará à porta 22 do final.com, imprimirá todo o tráfego recebido no stdout e enviará todo o stdin para o outro lado. É um "túnel" entre a nc stdin / out e a porta 22 do final.com.

Como ncé executado dentro da sessão ssh, todo o seu stdout é passado de volta ao 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 final.comdiretamente.

O seguinte comando

ssh -t inter ssh user2@final.com

não funciona ProxyCommandporque o resultado não é um tráfego "bruto" de um daemon ssh. É o stdout de um cliente ssh . Conversar com cliente não significa negócio.

Autenticação com chave ssh 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

Copiar local ~/.ssh/id_ras.pub para

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

Copiar local ~/.ssh/id_ras_2.pub para

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

Ambos os itens acima permitirão o seguinte uso

local# ssh final

Verificação Adicional

Use verbose

local# ssh -v final

Isso deve ajudar a identificar o problema ssh.

Verifique nc

ProxcyCommandestá executando ncno inter. Verifique se ncestá realmente disponível em inter.

local# ssh inter
inter# nc final.com 22

Verifique se a chave rsa está configurada corretamente

Se chaves diferentes devem ser usadas para intere final, os seguintes arquivos devem existir na máquina local

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

Como você interjá pode usar o ssh , verifique a configuração das teclas final. Da 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.publá.

Na verdade, não vi nenhum erro listado ou instruções ssh -v que ajudariam a ver onde ele está desligando.

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

Se você tem um sistema operacional moderno / amigável como o ubuntu (na sua máquina local), isso não deve funcionar sem nenhum * massageador *. 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

Caso contrário, execute estas etapas para verificar se o ssh-agent está executando:

'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.