Ich möchte mich mit einem entfernten Server anmelden, indem ich sth ausführt. wie ssh remoteServer . Der Remote-Server ist nur über einen Login-Server (von denen es zwei gibt) erreichbar.
Es gibt zwei Wege, die ich möchte (falls kein Login-Server verwendet werden kann):
A → B → D
A → C → D
Einige Infos:
A : Mein lokaler Computer
B : Anmeldeserver; erlaubt nur Benutzername / Passwort-Login (keine Schlüsseldatei); Ich kann keine Änderungen vornehmen (Schlüsseldatei speichern usw.)
C : Anmeldeserver; ermöglicht die Anmeldung von Schlüsseldateien; Ich kann einige Änderungen vornehmen (allerdings kein Superuser)
D : Zielserver; kann nur von B oder C erreicht werden; ermöglicht die Anmeldung der Schlüsseldatei
Ich verwende eine kennwortgeschützte private Schlüsseldatei (auf A und C; dieselbe), mit der ich mich bei C und D anmelden kann. Folgendes möchte ich:
ssh B_D : Fordern Sie das Kennwort von Benutzername B @ B und dann das Kennwort der privaten Schlüsseldatei für Benutzernamen D @ D an. Da ich den privaten Schlüssel nicht auf B speichern kann, muss er irgendwie weitergeleitet werden. Falls ich es mit ssh-agent geladen habe, sollte es nicht erneut nach dem Passwort gefragt werden.
ssh C_D : Einmaliges Kennwort für den privaten Schlüssel anfordern und dann zum Anmelden an usernameC @ C und dann usernameD @ D verwenden. Wenn der Schlüssel zuvor mit ssh-agent geladen wurde, sollte er nicht zur Eingabe eines Kennworts aufgefordert werden.
Teilweise kann ich den folgenden Befehl verwenden, um das obige zu erreichen (aber nur, wenn der Schlüssel mit ssh-agent geladen wurde):
ssh -A -t usernameB@B ssh usernameD@D ssh -A -t usernameC@C ssh usernameD@D
Gibt es vielleicht eine Änderung, die die Schlüsseldatei zuerst lädt, jedoch nur für diese Sitzung? Wenn ich mich abmelden sollte die Schlüsseldatei dann entladen werden.
Der obige Befehl hat zwei Probleme:
Ich möchte den Schlüssel nicht zuerst manuell mit ssh-agent laden. Dies verhindert den Zweck, nur einen Befehl eingeben zu müssen.
Ich möchte diesen oder einen gleichwertigen Befehl in die ssh-Konfigurationsdatei einfügen. Wenn es einen anderen Weg gibt, um das zu erreichen, was ich will, wäre das auch in Ordnung (solange ich nichts an B ändern oder Superuser-Rechte für C benötige).
Ich konnte etw erreichen. ähnlich mit der ssh-Konfigurationsdatei:
Host C HostName addressOfC User usernameC IdentityFile ~/.ssh/id_rsa ForwardAgent yes Host C_D HostName addressD User usernameD IdentityFile ~/.ssh/id_rsa Port 22 ProxyCommand ssh -A -W %h:%p C
Wieder zwei Probleme:
Ich muss den Schlüssel zuerst mit ssh-agent laden. Andernfalls werden Sie zweimal nach dem Kennwort gefragt.
Der Verbindungsaufbau dauert 24 Sekunden. Ich sollte hier erwähnen, dass ich unter Windows mit mobaXterm arbeite, falls dies für die 24 Sekunden verantwortlich ist.
Nach den Bemerkungen von @jakuje habe ich die Konfigurationsdatei folgendermaßen geändert:
Host C HostName addressOfC User usernameC IdentityFile ~/.ssh/id_rsa Host C_D HostName addressD User usernameD IdentityFile ~/.ssh/id_rsa Port 22 ProxyCommand ssh -W %h:%p C
Beim Laufen ssh -vvv C_Dbekomme ich folgendes Log (MobaXterm 7.4):
OpenSSH_6.2p2, OpenSSL 1.0.1g 7 Apr 2014 debug1: Reading configuration data /home/mobaxterm/.ssh/config debug1: /home/mobaxterm/.ssh/config line 24: Applying options for C_D debug1: Reading configuration data /etc/ssh_config debug2: ssh_connect: needpriv 0 debug1: Executing proxy command: exec ssh -W addressOfD:22 C debug1: permanently_drop_suid: 1000 debug3: Incorrect RSA1 identifier debug3: Could not load "/home/mobaxterm/.ssh/id_rsa" as a RSA1 public key debug1: identity file /home/mobaxterm/.ssh/id_rsa type 1 debug1: identity file /home/mobaxterm/.ssh/id_rsa-cert type -1 debug1: Enabling compatibility mode for protocol 2.0 debug1: Local version string SSH-2.0-OpenSSH_6.2 debug1: Remote protocol version 2.0, remote software version OpenSSH_5.3 debug1: match: OpenSSH_5.3 pat OpenSSH_5* debug2: fd 5 setting O_NONBLOCK debug2: fd 4 setting O_NONBLOCK debug3: load_hostkeys: loading entries for host "addressOfD" from file "/home/mobaxterm/.ssh/known_hosts" debug3: load_hostkeys: found key type RSA in file /home/mobaxterm/.ssh/known_hosts:1 debug3: load_hostkeys: loaded 1 keys debug3: order_hostkeyalgs: prefer hostkeyalgs: ssh-rsa-cert-v01@openssh.com,ssh-rsa-cert-v00@openssh.com,ssh-rsa debug1: SSH2_MSG_KEXINIT sent debug1: SSH2_MSG_KEXINIT received debug2: kex_parse_kexinit: ecdh-sha2-nistp256,ecdh-sha2-nistp384,ecdh-sha2-nistp521,diffie-hellman-group-exchange-sha256,diffie-hellman-group-exchange-sha1,diffie-hellman-group14-sha1,diffie-hellman-group1-sha1 debug2: kex_parse_kexinit: ssh-rsa-cert-v01@openssh.com,ssh-rsa-cert-v00@openssh.com,ssh-rsa,ecdsa-sha2-nistp256-cert-v01@openssh.com,ecdsa-sha2-nistp384-cert-v01@openssh.com,ecdsa-sha2-nistp521-cert-v01@openssh.com,ssh-dss-cert-v01@openssh.com,ssh-dss-cert-v00@openssh.com,ecdsa-sha2-nistp256,ecdsa-sha2-nistp384,ecdsa-sha2-nistp521,ssh-dss debug2: kex_parse_kexinit: aes128-ctr,aes192-ctr,aes256-ctr,arcfour256,arcfour128,aes128-gcm@openssh.com,aes256-gcm@openssh.com,aes128-cbc,3des-cbc,blowfish-cbc,cast128-cbc,aes192-cbc,aes256-cbc,arcfour,rijndael-cbc@lysator.liu.se debug2: kex_parse_kexinit: aes128-ctr,aes192-ctr,aes256-ctr,arcfour256,arcfour128,aes128-gcm@openssh.com,aes256-gcm@openssh.com,aes128-cbc,3des-cbc,blowfish-cbc,cast128-cbc,aes192-cbc,aes256-cbc,arcfour,rijndael-cbc@lysator.liu.se debug2: kex_parse_kexinit: hmac-md5-etm@openssh.com,hmac-sha1-etm@openssh.com,umac-64-etm@openssh.com,umac-128-etm@openssh.com,hmac-sha2-256-etm@openssh.com,hmac-sha2-512-etm@openssh.com,hmac-ripemd160-etm@openssh.com,hmac-sha1-96-etm@openssh.com,hmac-md5-96-etm@openssh.com,hmac-md5,hmac-sha1,umac-64@openssh.com,umac-128@openssh.com,hmac-sha2-256,hmac-sha2-512,hmac-ripemd160,hmac-ripemd160@openssh.com,hmac-sha1-96,hmac-md5-96 debug2: kex_parse_kexinit: hmac-md5-etm@openssh.com,hmac-sha1-etm@openssh.com,umac-64-etm@openssh.com,umac-128-etm@openssh.com,hmac-sha2-256-etm@openssh.com,hmac-sha2-512-etm@openssh.com,hmac-ripemd160-etm@openssh.com,hmac-sha1-96-etm@openssh.com,hmac-md5-96-etm@openssh.com,hmac-md5,hmac-sha1,umac-64@openssh.com,umac-128@openssh.com,hmac-sha2-256,hmac-sha2-512,hmac-ripemd160,hmac-ripemd160@openssh.com,hmac-sha1-96,hmac-md5-96 debug2: kex_parse_kexinit: zlib@openssh.com,zlib,none debug2: kex_parse_kexinit: zlib@openssh.com,zlib,none debug2: kex_parse_kexinit: debug2: kex_parse_kexinit: debug2: kex_parse_kexinit: first_kex_follows 0 debug2: kex_parse_kexinit: reserved 0 debug2: kex_parse_kexinit: diffie-hellman-group-exchange-sha256,diffie-hellman-group-exchange-sha1,diffie-hellman-group14-sha1,diffie-hellman-group1-sha1 debug2: kex_parse_kexinit: ssh-rsa,ssh-dss debug2: kex_parse_kexinit: aes128-ctr,aes192-ctr,aes256-ctr,arcfour256,arcfour128,aes128-cbc,3des-cbc,blowfish-cbc,cast128-cbc,aes192-cbc,aes256-cbc,arcfour,rijndael-cbc@lysator.liu.se debug2: kex_parse_kexinit: aes128-ctr,aes192-ctr,aes256-ctr,arcfour256,arcfour128,aes128-cbc,3des-cbc,blowfish-cbc,cast128-cbc,aes192-cbc,aes256-cbc,arcfour,rijndael-cbc@lysator.liu.se debug2: kex_parse_kexinit: hmac-md5,hmac-sha1,umac-64@openssh.com,hmac-sha2-256,hmac-sha2-512,hmac-ripemd160,hmac-ripemd160@openssh.com,hmac-sha1-96,hmac-md5-96 debug2: kex_parse_kexinit: hmac-md5,hmac-sha1,umac-64@openssh.com,hmac-sha2-256,hmac-sha2-512,hmac-ripemd160,hmac-ripemd160@openssh.com,hmac-sha1-96,hmac-md5-96 debug2: kex_parse_kexinit: none,zlib@openssh.com debug2: kex_parse_kexinit: none,zlib@openssh.com debug2: kex_parse_kexinit: debug2: kex_parse_kexinit: debug2: kex_parse_kexinit: first_kex_follows 0 debug2: kex_parse_kexinit: reserved 0 debug2: mac_setup: found hmac-md5 debug1: kex: server->client aes128-ctr hmac-md5 zlib@openssh.com debug2: mac_setup: found hmac-md5 debug1: kex: client->server aes128-ctr hmac-md5 zlib@openssh.com debug1: SSH2_MSG_KEX_DH_GEX_REQUEST(1024<1024<8192) sent debug1: expecting SSH2_MSG_KEX_DH_GEX_GROUP debug2: dh_gen_key: priv key bits set: 135/256 debug2: bits set: 533/1024 debug1: SSH2_MSG_KEX_DH_GEX_INIT sent debug1: expecting SSH2_MSG_KEX_DH_GEX_REPLY debug1: Server host key: RSA [...] debug3: load_hostkeys: loading entries for host "addressOfD" from file "/home/mobaxterm/.ssh/known_hosts" debug3: load_hostkeys: found key type RSA in file /home/mobaxterm/.ssh/known_hosts:1 debug3: load_hostkeys: loaded 1 keys debug1: Host 'addressOfD' is known and matches the RSA host key. debug1: Found key in /home/mobaxterm/.ssh/known_hosts:1 debug2: bits set: 515/1024 debug1: ssh_rsa_verify: signature correct debug2: kex_derive_keys debug2: set_newkeys: mode 1 debug1: SSH2_MSG_NEWKEYS sent debug1: expecting SSH2_MSG_NEWKEYS debug2: set_newkeys: mode 0 debug1: SSH2_MSG_NEWKEYS received debug1: Roaming not allowed by server debug1: SSH2_MSG_SERVICE_REQUEST sent debug2: service_accept: ssh-userauth debug1: SSH2_MSG_SERVICE_ACCEPT received debug2: key: /home/mobaxterm/.ssh/id_rsa (0x20072e98), explicit debug1: Authentications that can continue: publickey,gssapi-keyex,gssapi-with-mic,password debug3: start over, passed a different list publickey,gssapi-keyex,gssapi-with-mic,password debug3: preferred hostbased,publickey,password,keyboard-interactive debug3: authmethod_lookup publickey debug3: remaining preferred: password,keyboard-interactive debug3: authmethod_is_enabled publickey debug1: Next authentication method: publickey debug1: Offering RSA public key: /home/mobaxterm/.ssh/id_rsa debug3: send_pubkey_test debug2: we sent a publickey packet, wait for reply debug1: Server accepts key: pkalg ssh-rsa blen 279 debug2: input_userauth_pk_ok: fp [...] debug3: sign_and_send_pubkey: RSA [...] debug1: Enabling compression at level 6.
Hier macht es etwa 22 Sekunden Pause.
debug1: Authentication succeeded (publickey). Authenticated to addressOfD (via proxy). debug1: channel 0: new [client-session] debug3: ssh_session2_open: channel_new: 0 debug2: channel 0: send open debug1: Requesting no-more-sessions@openssh.com debug1: Entering interactive session. debug2: callback start debug2: x11_get_proto: /bin/xauth list :0.0 2>/dev/null debug1: Requesting X11 forwarding with authentication spoofing. debug2: channel 0: request x11-req confirm 1 debug2: client_session2_setup: id 0 debug2: channel 0: request pty-req confirm 1 debug2: channel 0: request shell confirm 1 debug2: callback done debug2: channel 0: open confirm rwindow 0 rmax 32768 debug2: channel_input_status_confirm: type 99 id 0 debug2: X11 forwarding request accepted on channel 0 debug2: channel_input_status_confirm: type 99 id 0 debug2: PTY allocation request accepted on channel 0 debug2: channel 0: rcvd adjust 2097152 debug2: channel_input_status_confirm: type 99 id 0 debug2: shell request accepted on channel 0
Edit 2:
Ich habe das ssh config-Setup unter Ubuntu 16.04 ausprobiert und die Verzögerung von 24 Sekunden nicht erhalten (die Verbindung wurde in weniger als 2 Sekunden hergestellt). Ich habe die neueste Version von MobaXterm (v9.1) heruntergeladen und nur der erste Verbindungsaufbau war langsam. Ich habe MobaXterm auch unter Windows 10 (vorher: Windows 7) getestet, dasselbe Ergebnis. Ich denke, das ist ein Problem mit Windows / MobaXterm oder was auch immer es unter der Haube benutzt.
Fazit:
Es scheint, dass das Beste, was ich tun kann, ist, zu Linux zu wechseln (etwas übertrieben) oder den SSH-Agenten weiterzuleiten (wenn ich Glück habe) oder mich zurückzulehnen und ein wenig zu warten. In beiden Fällen muss ich den ssh-Schlüssel im Voraus laden, um zu vermeiden, dass das Passwort zweimal eingegeben werden muss.
können Sie localcommand verwenden, um eine Portweiterleitungsverbindung zu D zu öffnen, nachdem Sie eine Verbindung zu C hergestellt haben, um den Tunnel einzurichten.
Jasen vor 8 Jahren
0
hmm "Es sollte nicht für interaktive Befehle verwendet werden." Ich denke keine Lösung.
Jasen vor 8 Jahren
0
1 Antwort auf die Frage
2
Jakuje
Ich muss den Schlüssel zuerst mit ssh-agent laden. Andernfalls werden Sie zweimal nach dem Kennwort gefragt.
Du brauchst es nicht. Wenn Ihr Schlüssel über eine Passphrase verfügt, ist dies hilfreich.
Der Verbindungsaufbau dauert 24 Sekunden. Ich sollte hier erwähnen, dass ich unter Windows mit mobaXterm arbeite, falls dies für die 24 Sekunden verantwortlich ist.
Das Verbinden dauert einige Zeit. Wenn Sie es schneller machen wollen (für separate Verbindungen verwenden Sie die ControlMasterOption).
ProxyCommand ssh -A -W %h:%p C
Sie benötigen hier keine Agentenweiterleitung. Die Authentifizierung erfolgt immer von Ihrem lokalen Computer aus.
ForwardAgent yes
Weder hier noch, es sei denn, Sie möchten Ihre Schlüssel vom Server verwenden C.
Ich verstehe deine erste Bemerkung nicht. Vielleicht war mir nicht klar: Ich kann mich mit demselben Schlüssel bei C und D anmelden. Mit dem erwähnten Eintrag in der Konfigurationsdatei werde ich zweimal aufgefordert, dasselbe Passwort einzugeben. Das sollte nicht nötig sein. Zu den 24s für die Verbindung: Wenn ich mich über die erste Methode "ssh -A -t usernameC @ C ssh usernameD @ D" verbinde (nachdem der Schlüssel zuvor geladen wurde), dauert es weniger als 2 Sekunden. Also 24 Sekunden sind einfach zu viel. Danke für den Rest der Korrekturen. Getestet und bestätigt.
nx105 vor 8 Jahren
0
1) Du meinst die Passphrase für einen Schlüssel? Sie haben zwei Möglichkeiten. Starten Sie den Agenten mit Ihrem System und fügen Sie dort den Schlüssel hinzu (einmal beim Booten) oder entfernen Sie die Passphrase aus dem Schlüssel (geringere Sicherheit). 2) Überprüfen Sie also das Debug-Protokoll (`ssh -vvv` sowohl für den Proxy-Befehl als auch für Ihren Befehl) mit Zeitmarken.
Jakuje vor 8 Jahren
1
1) Schade, dass es keine dritte Lösung gibt. Ich denke, ich werde mich für den ersten entscheiden (mobaXterm hat eine Option dafür). 2) Zwischen "debug1: Aktivieren der Komprimierung auf Stufe 6" und "debug1: Authentifizierung erfolgreich (publickey)." Hängt es fest. Der Rest läuft sehr schnell ab. Ich werde meinen Fragenbeitrag bearbeiten und das vollständige Protokoll hinzufügen.
nx105 vor 8 Jahren
0