SSH-Konfiguration ProxyCommand fragt nach öffentlichem Schlüssel

Question

Ich versuche, über ein Gateway eine Verbindung zu einer EC2-Instanz herzustellen.

Wenn ich mich mit dem Gateway verbinde

local> ssh gateway

Dann kann ich mich ohne Passwort mit EC2 verbinden

gateway> ssh ec2  # works

Für den Verbindungsversuch über den Proxy scheint jedoch die Identitätsdatei erforderlich zu sein.

Host gateway
    HostName <gateway>

Host ec2
    HostName ec2-<ec2>.compute.amazonaws.com
    ProxyCommand ssh gateway -W %h:%p


local> ssh ec2
Permission denied (publickey).

Ich dachte, der ProxyCommand meldet mich grundsätzlich beim Gateway an und dann beim endgültigen Ziel. Wenn ja, warum fragt er mich dann nach dem öffentlichen Schlüssel, wenn das Gateway so eingerichtet ist, dass dieser nicht erforderlich ist? Wie kann ich mich auf dieselbe Weise mit der EC2-Instanz verbinden, als ob ich mich per SSH beim Gateway und dann per SSH bei EC2 angemeldet hätte?

Bearbeiten: rsync funktioniert normal (fragt nicht nach der Schlüsseldatei)

rsync -pthrvz  --rsync-path=/usr/bin/rsync --rsh='ssh gateway ssh' . ec2:/path

ssh -v Ausgabe vongateway> ssh ec2

gateway> ssh -v ec2
OpenSSH_5.3p1, OpenSSL 1.0.1e-fips 11 Feb 2013
debug1: Reading configuration data /etc/ssh/ssh_config
debug1: Applying options for *
debug1: Connecting to ec2 port 22.
debug1: Connection established.
debug1: identity file <snip> type -1
debug1: Remote protocol version 2.0, remote software version OpenSSH_6.2
debug1: match: OpenSSH_6.2 pat OpenSSH*
debug1: Enabling compatibility mode for protocol 2.0
debug1: Local version string SSH-2.0-OpenSSH_5.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 'ec2' is known and matches the RSA host key.
debug1: Found key in ~/.ssh/known_hosts:63
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
debug1: Next authentication method: publickey
debug1: Trying private key: ~/.ssh/identity
debug1: Offering public key: ~/.ssh/id_rsa
debug1: Server accepts key: pkalg ssh-rsa blen 277
debug1: read PEM private key done: type RSA
debug1: Authentication succeeded (publickey).
debug1: channel 0: new [client-session]
debug1: Requesting [email protected]
debug1: Entering interactive session.
debug1: Sending environment.

ssh -v-Ausgabe beim Verbindungsversuch über Proxy

local$ ssh -v ec2 
OpenSSH_6.7p1 Ubuntu-5ubuntu1.3, OpenSSL 1.0.1f 6 Jan 2014
debug1: Reading configuration data /home/matt/.ssh/config
debug1: /home/matt/.ssh/config line 9: Applying options for ec2
debug1: Reading configuration data /etc/ssh/ssh_config
debug1: /etc/ssh/ssh_config line 19: Applying options for *
debug1: Hostname has changed; re-reading configuration
debug1: Reading configuration data /home/matt/.ssh/config
debug1: Reading configuration data /etc/ssh/ssh_config
debug1: /etc/ssh/ssh_config line 19: Applying options for *
debug1: Executing proxy command: exec ssh gateway -W ec2:22
debug1: permanently_drop_suid: 1000
debug1: identity file /home/matt/.ssh/id_rsa type 1
debug1: key_load_public: No such file or directory
debug1: identity file /home/matt/.ssh/id_rsa-cert type -1
debug1: key_load_public: No such file or directory
debug1: identity file /home/matt/.ssh/id_dsa type -1
debug1: key_load_public: No such file or directory
debug1: identity file /home/matt/.ssh/id_dsa-cert type -1
debug1: key_load_public: No such file or directory
debug1: identity file /home/matt/.ssh/id_ecdsa type -1
debug1: key_load_public: No such file or directory
debug1: identity file /home/matt/.ssh/id_ecdsa-cert type -1
debug1: key_load_public: No such file or directory
debug1: identity file /home/matt/.ssh/id_ed25519 type -1
debug1: key_load_public: No such file or directory
debug1: identity file /home/matt/.ssh/id_ed25519-cert type -1
debug1: Enabling compatibility mode for protocol 2.0
debug1: Local version string SSH-2.0-OpenSSH_6.7p1 Ubuntu-5ubuntu1.3
debug1: Remote protocol version 2.0, remote software version OpenSSH_6.2
debug1: match: OpenSSH_6.2 pat OpenSSH* compat 0x04000000
debug1: SSH2_MSG_KEXINIT sent
debug1: SSH2_MSG_KEXINIT received
debug1: kex: server->client aes128-ctr [email protected] none
debug1: kex: client->server aes128-ctr [email protected] none
debug1: sending SSH2_MSG_KEX_ECDH_INIT
debug1: expecting SSH2_MSG_KEX_ECDH_REPLY
debug1: Server host key: ECDSA 73:<snip>:0c
debug1: Host 'ec2.compute.amazonaws.com' is known and matches the ECDSA host key.
debug1: Found key in /home/matt/.ssh/known_hosts:11
debug1: SSH2_MSG_NEWKEYS sent
debug1: expecting SSH2_MSG_NEWKEYS
debug1: SSH2_MSG_NEWKEYS received
debug1: Roaming not allowed by server
debug1: SSH2_MSG_SERVICE_REQUEST sent
debug1: SSH2_MSG_SERVICE_ACCEPT received
debug1: Authentications that can continue: publickey
debug1: Next authentication method: publickey
debug1: Offering RSA public key: /home/matt/.ssh/id_rsa
debug1: Authentications that can continue: publickey
debug1: Trying private key: /home/matt/.ssh/id_dsa
debug1: Trying private key: /home/matt/.ssh/id_ecdsa
debug1: Trying private key: /home/matt/.ssh/id_ed25519
debug1: No more authentication methods to try.
Permission denied (publickey).

Das Problem scheint zu sein, dass versucht wird, den Schlüssel auf meinem Computer zu finden, anstatt ihn vom Gateway-Computer zu holen.

Answer 1

ProxyCommand funktioniert nicht so, wie Sie denken. Der angegebene Befehl wird nicht auf dem Gateway-Computer ausgeführt. Vielmehr wird er auf dem Verbindungscomputer ausgeführt.

Der Ausführungsablauf ist daher:

1. Der ProxyCommand „ssh gateway -W %h:%p“ wird auf dem „lokalen“ Rechner ausgeführt. Dadurch wird eine SSH-Sitzung zum Gateway eingerichtet, wobei die RSA-Identität auf Ihrem lokalen Rechner verwendet wird. Das Flag -W gibt an, dass stdin und stdout an eine TCP-Sitzungserstellung auf dem Gateway zu Ihrem endgültigen Ziel angeschlossen werden sollen.

2. Nachdem die Proxy-Sitzung hergestellt wurde, verwendet SSH auf Ihrer lokalen Box diese Sitzung erneut zur Authentifizierung bei Ihrem Remote-SSH-Server, wiederum unter Verwendung lokaler Anmeldeinformationen.

Es ist ein wenig verwirrend, aber stellen Sie sich den ProxyCommand einfach als das Einrichten einer „Pipe“ zwischen Ihrem lokalen SSH-Client und dem SSH-Server vor, der Ihr endgültiges Ziel ist. Diese einfache Pipe wird dann von Ihrem lokalen SSH-Client verwendet, um mit dem SSH-Dienst des endgültigen Ziels zu kommunizieren.

Der Schlüssel liegt darin, dass es daherzweiInstanzen von SSH, die auf Ihrer lokalen Box laufen, eine davon ist der ProxyCommand, die andere die eigentliche SSH-Verbindung, die Sie herstellen möchten! Sie sollten dies überprüfen können, indem Sie sich die Ausgabe von „ps aux“ auf Ihrer lokalen Box ansehen.

Das würde dann erklären, warum versucht wird, zur Authentifizierung Schlüsselmaterial auf Ihrer lokalen Box und nicht auf Ihrem Gateway zu verwenden. :-)

Der Grund, warum rsync funktioniert, liegt darin, dass Sie tatsächlich „ssh gateway ssh“ als Ihren --rsh-Befehl ausführen, wodurch ssh tatsächlich einmal auf der lokalen Box ausgeführt wird, um eine Verbindung mit dem Gateway herzustellen, und dann noch einmal auf der Remote-Box, die dann das Remote-Schlüsselmaterial verwendet.

Hoffe das hilft.