Ao fazer uma senha de login menos, faz com que um login subsequente solicite uma senha

Question

Eu preciso executar um script em uma máquina que só é alcançável por meio de alguns pulos. Então eu escrevi um pequeno roteiro:

ssh -t user1@host1 ssh -t user2@host2 ssh -t user3@host3 sript_to_run.sh

Isso funciona muito bem e solicita senhas para host1, host2, mas não host3.

Por conveniência, copiei meu rsa-key público do meu computador para o host1 para login sem senha. Agora apenas me avisando para o login no host2, mas de outra forma bem.

Então eu fiz o mesmo com o host1 & host2. Agora posso fazer o login upto host2 sem nenhum prompt de senha. Mas agora eu preciso fazer o login com uma senha no host3 ... Infelizmente eu não sei como o login sem senha funciona no host3 e não tenho permissão para acrescentar o arquivo authorized_keys .

Então eu diria que o host3 de alguma forma sabe como eu loguei no host2. Posso, de alguma forma, enganar o host3 ao pensar que o host2 estava sendo logado pelo prompt de senha? Ou existe outra maneira de executar o script sem senhas?

Aqui está a saída detalhada da última etapa ssh: (Tudo em # é removido para anonimato):

OpenSSH_4.3p2, OpenSSL 0.9.8e-fips-rhel5 01 Jul 2008
debug1: Reading configuration data /etc/ssh/ssh_config
debug1: Applying options for *
debug1: Connecting to mcc-console [#IP#] port 22.
debug1: Connection established.
debug1: identity file /reg/neh/home/#USER#/.ssh/identity type -1
debug1: identity file /reg/neh/home/#USER#/.ssh/id_rsa type -1
debug1: identity file /reg/neh/home/#USER#/.ssh/id_dsa type -1
debug1: loaded 3 keys
debug1: Remote protocol version 2.0, remote software version OpenSSH_5.3
debug1: match: OpenSSH_5.3 pat OpenSSH*
debug1: Enabling compatibility mode for protocol 2.0
debug1: Local version string SSH-2.0-OpenSSH_4.3
debug1: SSH2_MSG_KEXINIT sent
debug1: SSH2_MSG_KEXINIT received
debug1: kex: server->client aes128-ctr hmac-md5 none
debug1: kex: client->server aes128-ctr hmac-md5 none
debug1: SSH2_MSG_KEX_DH_GEX_REQUEST(1024<1024<8192) sent
debug1: expecting SSH2_MSG_KEX_DH_GEX_GROUP
debug1: SSH2_MSG_KEX_DH_GEX_INIT sent
debug1: expecting SSH2_MSG_KEX_DH_GEX_REPLY
debug1: Host '#HOST3#' is known and matches the RSA host key.
debug1: Found key in /reg/neh/home/#USER#/.ssh/known_hosts:1
debug1: ssh_rsa_verify: signature correct
debug1: SSH2_MSG_NEWKEYS sent
debug1: expecting SSH2_MSG_NEWKEYS
debug1: SSH2_MSG_NEWKEYS received
debug1: SSH2_MSG_SERVICE_REQUEST sent
debug1: SSH2_MSG_SERVICE_ACCEPT received
debug1: Authentications that can continue: publickey,gssapi-keyex,gssapi-with-mic,password
debug1: Next authentication method: gssapi-with-mic
debug1: Unspecified GSS failure.  Minor code may provide more information
No credentials cache found

debug1: Unspecified GSS failure.  Minor code may provide more information
No credentials cache found

debug1: Unspecified GSS failure.  Minor code may provide more information
No credentials cache found

debug1: Next authentication method: publickey
debug1: Trying private key: /reg/neh/home/#USER#/.ssh/identity
debug1: read PEM private key done: type DSA
debug1: Authentications that can continue: publickey,gssapi-keyex,gssapi-with-mic,password
debug1: Trying private key: /reg/neh/home/#USER#/.ssh/id_rsa
debug1: Trying private key: /reg/neh/home/#USER#/.ssh/id_dsa
debug1: Next authentication method: password

    

Answer 1

Algumas observações, não tenho certeza se responderão a todas as suas respostas:

1. Copiar sua chave privada para máquinas remotas é ERRADO , se elas não forem totalmente confiáveis (acesso físico, acesso root apenas por você). Se você realmente precisa usar sua chave da máquina remota, existe um recurso chamado AgentForwarding , que faz a coisa de uma maneira melhor (google para ler mais)

2. Configurar jumphosts também é um problema muito conhecido. Sim, você pode fazer do jeito que você faz agora, mas você cometerá erros que eu mencionei acima. E por que fazê-los, quando há melhor maneira, chamado ProxyCommand ? Com isso, você pode deixar toda a operação de chave privada em sua máquina confiável, o que é desejável (google, muitas vezes resolvido aqui no superusr ou em wikibooks ).

E para suas perguntas:

Can I somehow trick host3 in thinking that host2 was being logged into by password prompt?

Não tenho certeza do que você quer dizer com isso.

Or is there an other way to run the script passwords-less?

Existem várias maneiras de se autenticar no servidor, exceto as senhas. Existem kerberos usando GSSAPI, há autenticação baseada em host, mas todos eles precisam de alguma configuração para ser feita antes. Se você não tem controle sobre o host3 e está proibido de configurar a chave pública, você realmente precisa usar a senha. Mas sem mais informações não posso ajudar. As falhas do log do servidor também podem ser úteis para investigar o problema.