Kein Zugriff auf einen Linux-Server hinter NAT über einen umgekehrten SSH-Tunnel mit kennwortloser SSH-Anmeldung
444
Betty
Problem
Ich kann nicht auf meine Verbindung Home Server über passwordless SSH Login von meinem Clientcomputer / Remotecomputer über meine Relay .
Ich bekomme homeserver@localhost: Permission denied (publickey).
Geschichte / Verfahren bisher abgeschlossen
- Richten Sie einen Homeserver (Kali Debian) hinter NAT ein, installieren Sie open-ssh, generieren Sie die Schlüssel und bearbeiten Sie die Datei sshd_config so, dass keine Passwörter zulässig sind.
- Richten Sie den Relaysever (AWS Ubuntu AMI) ein, installieren Sie open-ssh, generieren Sie die Schlüssel und bearbeiten Sie die Datei sshd_config so, dass keine Passwörter zugelassen werden.
- Richten Sie den Clientcomputer (Kali Debian, der auf einer VMware-Workstation ausgeführt wird) ein, installiert open-ssh und generiert die Schlüssel.
Die folgenden Berechtigungen für Homeserver, Relayserver und Clientcomuter wurden geändert :
- .ssh Verzeichnisberechtigungen auf 700 (drwx ------)
- öffentlicher Schlüssel (.pub-Datei) bis 644 (-rw-r - r--)
- Privater Schlüssel (id_rsa) bis 600 (-rw -------)
- Heimatverzeichnis bis 755 (drwxr-xr-x)
Ich ging dann den Authentifizierungs - Schlüssel zu meinem Relay - Server sowohl von meinem Homeserver und meinen Clientcomputern und angemeldet. Kein Problem.
Ich GewayPorts yeshabe die ssshd_config -Datei auf dem Relayserver hinzugefügt .
Ich habe dann die folgenden Befehle ausgeführt:
Auf dem Homeserver :
ssh -fN -R 10022:localhost:22 relayserver_user@1.1.1.1 Auf dem relayserver :
relayserver~$ sudo netstat -nap | grep 10022 - um die Verbindung zu überprüfen - scheint alles gut zu sein:
Auf dem Clientcomputer (nachdem ich mich mit dem Relayserver verbunden habe ):
ssh -p 10022 homeserver_user@localhost Hier wird zuerst der Schlüssel für fehlgeschlagene Authentifizierung angezeigt. Nicht sicher, was los ist, denn wenn ich die sshd_config -Datei auf dem Homeserver auf passwordauthentication yesden Remote-Tunnel bearbeite, funktioniert das problemlos.
Wenn ich den Befehl ein zweites Mal versuche, bleibt er im Debug stecken (siehe unten).
Beachten Sie, dass ich das bin readying Homeserver über Teamviewer.
Dumps und Protokolle
Dump vom Testen des Relayservers :
tcp 0 0 0.0.0.0:10022 0.0.0.0:* LISTEN 2878/sshd: ubuntu tcp6 0 0 :::10022 :::* LISTEN 2878/sshd: ubuntu Dump vom -vvv während Clientcomputer, wenn mit den Verbindungs Home Server nach loggin in den Relay 1. Versuch:
OpenSSH_7.6p1 Ubuntu-4, OpenSSL 1.0.2n 7 Dec 2017 debug1: Reading configuration data /etc/ssh/ssh_config debug1: /etc/ssh/ssh_config line 19: Applying options for * debug2: resolving "localhost" port 10022 debug2: ssh_connect_direct: needpriv 0 debug1: Connecting to localhost [127.0.0.1] port 10022. debug1: Connection established. debug1: key_load_public: No such file or directory debug1: identity file /home/ubuntu/.ssh/id_rsa type -1 debug1: key_load_public: No such file or directory debug1: identity file /home/ubuntu/.ssh/id_rsa-cert type -1 debug1: key_load_public: No such file or directory debug1: identity file /home/ubuntu/.ssh/id_dsa type -1 debug1: key_load_public: No such file or directory debug1: identity file /home/ubuntu/.ssh/id_dsa-cert type -1 debug1: key_load_public: No such file or directory debug1: identity file /home/ubuntu/.ssh/id_ecdsa type -1 debug1: key_load_public: No such file or directory debug1: identity file /home/ubuntu/.ssh/id_ecdsa-cert type -1 debug1: identity file /home/ubuntu/.ssh/id_ed25519 type 3 debug1: key_load_public: No such file or directory debug1: identity file /home/ubuntu/.ssh/id_ed25519-cert type -1 debug1: Local version string SSH-2.0-OpenSSH_7.6p1 Ubuntu-4 debug1: Remote protocol version 2.0, remote software version OpenSSH_7.7p1 Debian-3 debug1: match: OpenSSH_7.7p1 Debian-3 pat OpenSSH* compat 0x04000000 debug2: fd 3 setting O_NONBLOCK debug1: Authenticating to localhost:10022 as 'homeserver' debug3: put_host_port: [localhost]:10022 debug3: hostkeys_foreach: reading file "/home/ubuntu/.ssh/known_hosts" debug3: record_hostkey: found key type ECDSA in file /home/ubuntu/.ssh/known_hosts:2 debug3: load_hostkeys: loaded 1 keys from [localhost]:10022 debug3: order_hostkeyalgs: prefer hostkeyalgs: ecdsa-sha2-nistp256-cert-v01@openssh.com,ecdsa-sha2-nistp384-cert-v01@openssh.com,ecdsa-sha2-nistp521-cert-v01@openssh.com,ecdsa-sha2-nistp256,ecdsa-sha2-nistp384,ecdsa-sha2-nistp521 debug3: send packet: type 20 debug1: SSH2_MSG_KEXINIT sent debug3: receive packet: type 20 debug1: SSH2_MSG_KEXINIT received debug2: local client KEXINIT proposal debug2: KEX algorithms: curve25519-sha256,curve25519-sha256@libssh.org,ecdh-sha2-nistp256,ecdh-sha2-nistp384,ecdh-sha2-nistp521,diffie-hellman-group-exchange-sha256,diffie-hellman-group16-sha512,diffie-hellman-group18-sha512,diffie-hellman-group-exchange-sha1,diffie-hellman-group14-sha256,diffie-hellman-group14-sha1,ext-info-c debug2: host key algorithms: ecdsa-sha2-nistp256-cert-v01@openssh.com,ecdsa-sha2-nistp384-cert-v01@openssh.com,ecdsa-sha2-nistp521-cert-v01@openssh.com,ecdsa-sha2-nistp256,ecdsa-sha2-nistp384,ecdsa-sha2-nistp521,ssh-ed25519-cert-v01@openssh.com,ssh-rsa-cert-v01@openssh.com,ssh-ed25519,rsa-sha2-512,rsa-sha2-256,ssh-rsa debug2: ciphers ctos: chacha20-poly1305@openssh.com,aes128-ctr,aes192-ctr,aes256-ctr,aes128-gcm@openssh.com,aes256-gcm@openssh.com debug2: ciphers stoc: chacha20-poly1305@openssh.com,aes128-ctr,aes192-ctr,aes256-ctr,aes128-gcm@openssh.com,aes256-gcm@openssh.com debug2: MACs ctos: umac-64-etm@openssh.com,umac-128-etm@openssh.com,hmac-sha2-256-etm@openssh.com,hmac-sha2-512-etm@openssh.com,hmac-sha1-etm@openssh.com,umac-64@openssh.com,umac-128@openssh.com,hmac-sha2-256,hmac-sha2-512,hmac-sha1 debug2: MACs stoc: umac-64-etm@openssh.com,umac-128-etm@openssh.com,hmac-sha2-256-etm@openssh.com,hmac-sha2-512-etm@openssh.com,hmac-sha1-etm@openssh.com,umac-64@openssh.com,umac-128@openssh.com,hmac-sha2-256,hmac-sha2-512,hmac-sha1 debug2: compression ctos: none,zlib@openssh.com,zlib debug2: compression stoc: none,zlib@openssh.com,zlib debug2: languages ctos: debug2: languages stoc: debug2: first_kex_follows 0 debug2: reserved 0 debug2: peer server KEXINIT proposal debug2: KEX algorithms: curve25519-sha256,curve25519-sha256@libssh.org,ecdh-sha2-nistp256,ecdh-sha2-nistp384,ecdh-sha2-nistp521,diffie-hellman-group-exchange-sha256,diffie-hellman-group16-sha512,diffie-hellman-group18-sha512,diffie-hellman-group14-sha256,diffie-hellman-group14-sha1 debug2: host key algorithms: ssh-rsa,rsa-sha2-512,rsa-sha2-256,ecdsa-sha2-nistp256,ssh-ed25519 debug2: ciphers ctos: chacha20-poly1305@openssh.com,aes128-ctr,aes192-ctr,aes256-ctr,aes128-gcm@openssh.com,aes256-gcm@openssh.com debug2: ciphers stoc: chacha20-poly1305@openssh.com,aes128-ctr,aes192-ctr,aes256-ctr,aes128-gcm@openssh.com,aes256-gcm@openssh.com debug2: MACs ctos: umac-64-etm@openssh.com,umac-128-etm@openssh.com,hmac-sha2-256-etm@openssh.com,hmac-sha2-512-etm@openssh.com,hmac-sha1-etm@openssh.com,umac-64@openssh.com,umac-128@openssh.com,hmac-sha2-256,hmac-sha2-512,hmac-sha1 debug2: MACs stoc: umac-64-etm@openssh.com,umac-128-etm@openssh.com,hmac-sha2-256-etm@openssh.com,hmac-sha2-512-etm@openssh.com,hmac-sha1-etm@openssh.com,umac-64@openssh.com,umac-128@openssh.com,hmac-sha2-256,hmac-sha2-512,hmac-sha1 debug2: compression ctos: none,zlib@openssh.com debug2: compression stoc: none,zlib@openssh.com debug2: languages ctos: debug2: languages stoc: debug2: first_kex_follows 0 debug2: reserved 0 debug1: kex: algorithm: curve25519-sha256 debug1: kex: host key algorithm: ecdsa-sha2-nistp256 debug1: kex: server->client cipher: chacha20-poly1305@openssh.com MAC: <implicit> compression: none debug1: kex: client->server cipher: chacha20-poly1305@openssh.com MAC: <implicit> compression: none debug3: send packet: type 30 debug1: expecting SSH2_MSG_KEX_ECDH_REPLY debug3: receive packet: type 31 debug1: Server host key: ecdsa-sha2-nistp256 SHA256:yfx8V8nVyZNs0bF1IXLB5Ud5fF1iHYgp1+0dVwHqlx4 debug3: put_host_port: [127.0.0.1]:10022 debug3: put_host_port: [localhost]:10022 debug3: hostkeys_foreach: reading file "/home/ubuntu/.ssh/known_hosts" debug3: record_hostkey: found key type ECDSA in file /home/ubuntu/.ssh/known_hosts:2 debug3: load_hostkeys: loaded 1 keys from [localhost]:10022 debug1: Host '[localhost]:10022' is known and matches the ECDSA host key. debug1: Found key in /home/ubuntu/.ssh/known_hosts:2 debug3: send packet: type 21 debug2: set_newkeys: mode 1 debug1: rekey after 134217728 blocks debug1: SSH2_MSG_NEWKEYS sent debug1: expecting SSH2_MSG_NEWKEYS debug3: receive packet: type 21 debug1: SSH2_MSG_NEWKEYS received debug2: set_newkeys: mode 0 debug1: rekey after 134217728 blocks debug2: key: /home/ubuntu/.ssh/id_rsa ((nil)) debug2: key: /home/ubuntu/.ssh/id_dsa ((nil)) debug2: key: /home/ubuntu/.ssh/id_ecdsa ((nil)) debug2: key: /home/ubuntu/.ssh/id_ed25519 (0x56263b49fb50) debug3: send packet: type 5 debug3: receive packet: type 7 debug1: SSH2_MSG_EXT_INFO received debug1: kex_input_ext_info: server-sig-algs=<ssh-ed25519,ssh-rsa,rsa-sha2-256,rsa-sha2-512,ssh-dss,ecdsa-sha2-nistp256,ecdsa-sha2-nistp384,ecdsa-sha2-nistp521> debug3: receive packet: type 6 debug2: service_accept: ssh-userauth debug1: SSH2_MSG_SERVICE_ACCEPT received debug3: send packet: type 50 debug3: receive packet: type 51 debug1: Authentications that can continue: publickey debug3: start over, passed a different list publickey debug3: preferred gssapi-keyex,gssapi-with-mic,publickey,keyboard-interactive,password debug3: authmethod_lookup publickey debug3: remaining preferred: keyboard-interactive,password debug3: authmethod_is_enabled publickey debug1: Next authentication method: publickey debug1: Trying private key: /home/ubuntu/.ssh/id_rsa debug3: no such identity: /home/ubuntu/.ssh/id_rsa: No such file or directory debug1: Trying private key: /home/ubuntu/.ssh/id_dsa debug3: no such identity: /home/ubuntu/.ssh/id_dsa: No such file or directory debug1: Trying private key: /home/ubuntu/.ssh/id_ecdsa debug3: no such identity: /home/ubuntu/.ssh/id_ecdsa: No such file or directory debug1: Offering public key: ED25519 SHA256:AvsGsfq4sXyTubnuWOgb***********jVBPIyFEQ9/UY /home/ubuntu/.ssh/id_ed25519 debug3: send_pubkey_test debug3: send packet: type 50 debug2: we sent a publickey packet, wait for reply debug3: receive packet: type 60 debug1: Server accepts key: pkalg ssh-ed25519 blen 51 debug2: input_userauth_pk_ok: fp SHA256:AvsGsfq4sXyTubnuWOgbL**********FEQ9/UY debug3: sign_and_send_pubkey: ED25519 SHA256:AvsGsfq4sXyT************ debug3: no such identity: /home/ubuntu/.ssh/id_ed25519: No such file or directory debug2: we did not send a packet, disable method debug1: No more authentication methods to try. homeserver@localhost: Permission denied (publickey). Dump vom -vvv während Clientcomputer, wenn mit den Verbindungs Home Server nach loggin in den Relay 2. Versuch:
OpenSSH_7.6p1 Ubuntu-4, OpenSSL 1.0.2n 7 Dec 2017 debug1: Reading configuration data /etc/ssh/ssh_config debug1: /etc/ssh/ssh_config line 19: Applying options for * debug2: resolving "localhost" port 10022 debug2: ssh_connect_direct: needpriv 0 debug1: Connecting to localhost [127.0.0.1] port 10022. debug1: Connection established. debug1: key_load_public: No such file or directory debug1: identity file /home/ubuntu/.ssh/id_rsa type -1 debug1: key_load_public: No such file or directory debug1: identity file /home/ubuntu/.ssh/id_rsa-cert type -1 debug1: key_load_public: No such file or directory debug1: identity file /home/ubuntu/.ssh/id_dsa type -1 debug1: key_load_public: No such file or directory debug1: identity file /home/ubuntu/.ssh/id_dsa-cert type -1 debug1: key_load_public: No such file or directory debug1: identity file /home/ubuntu/.ssh/id_ecdsa type -1 debug1: key_load_public: No such file or directory debug1: identity file /home/ubuntu/.ssh/id_ecdsa-cert type -1 debug1: identity file /home/ubuntu/.ssh/id_ed25519 type 3 debug1: key_load_public: No such file or directory debug1: identity file /home/ubuntu/.ssh/id_ed25519-cert type -1 debug1: Local version string SSH-2.0-OpenSSH_7.6p1 Ubuntu-4 Ich habe auch versucht, (ohne Erfolg) einen id_ed25519.pub-Schlüssel auf dem Clientcomputer zu erstellen und ihn dem Verzeichnis /home/.ssh/ auf dem Relayserver hinzuzufügen - wie Sie in den Dumps (oben) sehen können.
Dump aus grep 'sshd' /var/log/auth.logauf Homeserver :
Aug 14 06:04:48 homeserver-host sshd[3364]: /etc/ssh/sshd_config line 38: Deprecated option RSAAuthentication Aug 14 06:04:49 homeserver-host sshd[3364]: reprocess config line 38: Deprecated option RSAAuthentication Aug 14 06:04:49 homeserver-host sshd[3364]: Connection closed by authenticating user homeserver ::1 port 43536 [preauth] Aug 14 06:26:34 homeserver-host sudo: homeserver : TTY=pts/0 ; PWD=/home/homeserver/.ssh ; USER=root ; COMMAND=/bin/grep sshd /var/log/auth.log Aug 14 06:36:57 homeserver-host sudo: homeserver : TTY=pts/1 ; PWD=/etc/ssh ; USER=root ; COMMAND=/bin/nano sshd_config Aug 14 06:38:44 homeserver-host sshd[5932]: Server listening on 0.0.0.0 port 22. Aug 14 06:38:44 homeserver-host sshd[5932]: Server listening on :: port 22. Aug 14 06:39:56 homeserver-host sshd[5975]: Connection closed by authenticating user homeserver ::1 port 43560 [preauth] Aug 14 06:54:27 homeserver-host sudo: homeserver : TTY=pts/2 ; PWD=/home/homeserver ; USER=root ; COMMAND=/bin/nano /etc/ssh/sshd_config Aug 14 10:37:13 homeserver-host sshd[5932]: Received SIGHUP; restarting. Aug 14 10:37:13 homeserver-host sshd[5932]: Server listening on 0.0.0.0 port 22. Aug 14 10:37:13 homeserver-host sshd[5932]: Server listening on :: port 22. Aug 14 10:37:23 homeserver-host sshd[5932]: Received SIGHUP; restarting. Aug 14 10:37:23 homeserver-host sshd[5932]: Server listening on 0.0.0.0 port 22. Aug 14 10:37:23 homeserver-host sshd[5932]: Server listening on :: port 22. Aug 14 13:31:19 homeserver-host sshd[5932]: Received SIGHUP; restarting. Aug 14 13:31:19 homeserver-host sshd[5932]: Server listening on 0.0.0.0 port 22. Aug 14 13:31:19 homeserver-host sshd[5932]: Server listening on :: port 22. Aug 14 13:31:24 homeserver-host sshd[5932]: Received SIGHUP; restarting. Aug 14 13:31:24 homeserver-host sshd[5932]: Server listening on 0.0.0.0 port 22. Aug 14 13:31:24 homeserver-host sshd[5932]: Server listening on :: port 22. Aug 14 13:43:02 homeserver-host sshd[5932]: Received SIGHUP; restarting. Aug 14 13:43:02 homeserver-host sshd[5932]: Server listening on 0.0.0.0 port 22. Aug 14 13:43:02 homeserver-host sshd[5932]: Server listening on :: port 22. Aug 14 13:43:12 homeserver-host sshd[5932]: Received SIGHUP; restarting. Aug 14 13:43:12 homeserver-host sshd[5932]: Server listening on 0.0.0.0 port 22. Aug 14 13:43:12 homeserver-host sshd[5932]: Server listening on :: port 22. Aug 14 16:30:03 homeserver-host sshd[5932]: Received signal 15; terminating. Aug 14 23:00:27 homeserver-host sshd[3069]: Connection closed by authenticating user homeserver ::1 port 33912 [preauth] Aug 14 23:45:51 homeserver-host sudo: homeserver : TTY=pts/0 ; PWD=/home/homeserver ; USER=root ; COMMAND=/bin/grep sshd /var/log/auth.log Hoffe, jemand kann helfen!
Sie haben die Option `-i / path / to / private.key` im Befehl` ssh` auf Clientseite nicht angegeben. Stellen Sie außerdem sicher, dass die Datei mit dem privaten Schlüssel 600 Berechtigungen hat.
Alex vor 6 Jahren
0
Meines Erachtens sollten Sie niemals private Schlüssel übergeben? Wissen Sie, warum ich dies bei dieser Gelegenheit tun sollte. Danke für Ihre Hilfe.
Betty vor 6 Jahren
0
So funktioniert die Authentifizierung mit öffentlichen Schlüsseln. Vereinfachtes Modell: Einen Dollar in Milliarden Teile schneiden, gut mischen, dann in zwei Stapel teilen und einen als öffentlich und einen als privat bezeichnen. Die einzigen, die beide Stapel haben, können den Dollar wieder herstellen. Das Gleiche gilt für Ihren Fall, dass Sie einen öffentlichen Schlüssel auf einem Remote-Computer gespeichert haben und den privaten Schlüssel verwenden, um das Authentifizierungspuzzle abzuschließen. Deshalb nennt es [asymmetrische Kryptographie] (https://en.wikipedia.org/wiki/Public-key_cryptography), wo beide Schlüssel verwendet werden müssen. Ihr privater Schlüssel verlässt niemals Ihren PC, sondern wird (nur auf Ihrem PC) zum Verschlüsseln von Nachrichten verwendet.
Alex vor 6 Jahren
0
ich verstehe, danke. Wissen Sie, warum ich plötzlich anfangen müsste, an open-ssh anzugeben, wo sich der private Schlüssel befindet. Es schien immer zu wissen, wo sich die Schlüssel für "normale" Computer-zu-Computer-Verbindungen (Authentifizierungsschlüssel) befinden. Ist dies nur ein Merkmal von umgekehrten SSH-Tunneln mit passwortlosem SSH-Login?
Betty vor 6 Jahren
0
Wenn Sie in "sshd_config" die Option "PasswordAuthentication no" festlegen, lässt SSH nur die Authentifizierung mit öffentlichen Schlüsseln zu, unabhängig davon, wie Sie SSH verwenden, entweder für die "normale" Verbindung zum Remote-Host oder für den Reverse-Tunnel oder sogar für "scp". Die Authentifizierung mit öffentlichen Schlüsseln ist der stärkste Punkt von SSH, da reguläre Kennwörter brutal erzwungen werden können, während dies mit öffentlichen Schlüsseln praktisch unmöglich ist. Wenn Sie die Option -i nicht verwenden möchten, können Sie die Befehlszeilenoption aller SSH-Dateien in der Datei ~ / .ssh / config festlegen, die für einen bestimmten Host gelten würde.
Alex vor 6 Jahren
0
Also vom Clientcomputer nach dem Anmelden am Relay-Server: ssh -i / location / to / clientcomputer / privatekey -p 10022 homeserver_user @ localhost
Betty vor 6 Jahren
0
0 Antworten auf die Frage
Verwandte Probleme
-
9
Was ist der Unterschied zwischen den Befehlen "su -s" und "sudo -s"?
-
4
Gutes freies Ubuntu Server-VMWare-Image benötigt
-
4
Was sind die Unterschiede zwischen den großen Linux-Distributionen? Werde ich es merken
-
2
Begrenzung der CPU-Auslastung für Flash in Firefox?
-
2
Wie kann ich mein Mikrofon unter Debian GNOME zum Laufen bringen?
-
2
Conky-Setups - Beispiele / Ideen?
-
3
Was sind die Unterschiede zwischen Linux Window Managern?
-
2
ThunderBird / Lichtsynchronisation mit SE k770i
-
4
Linux-Dateisystem
-
6
Vollbild-Flash langsam in KDE 4