SSH Password Eingabe dauert extrem lange.

L

LingLink

New member
Guten Morgen zusammen,

ich habe ein Problem mit SSH Verbindungen auf meinem Windows 10 PC. Wenn ich gegen eine lokale VM (VBox) per SSH connecten möchte, dauert es nach der Passworteingabe ~30 Sekunden, bis ich dann tatsächlich eingeloggt bin. Ich habe schon verschiedene Clients probiert: Das neue und native OpenSSH über Powershell, MobaXTerm, Putty. Das Verhalten ist jedes mal gleich. Das Problem scheint nur auf dem PC selbst zu bestehen. Nutze ich mein Android Handy und verbinde mich direkt über JuiceSSH auf die gleiche VM, geht es sofort.

Ich sehe ehrlich gesagt im DEBUG Modus jetzt auch nichts auffälliges.

PS C:\Users\andre> ssh root@elktest.fritz.box -vv
OpenSSH_for_Windows_7.6p1, LibreSSL 2.6.4
debug2: resolving "elktest.fritz.box" port 22
debug2: ssh_connect_direct: needpriv 0
debug1: Connecting to elktest.fritz.box [192.168.188.54] port 22.
debug1: Connection established.
debug1: key_load_public: No such file or directory
debug1: identity file C:\\Users\\andre/.ssh/id_rsa type -1
debug1: key_load_public: No such file or directory
debug1: identity file C:\\Users\\andre/.ssh/id_rsa-cert type -1
debug1: key_load_public: No such file or directory
debug1: identity file C:\\Users\\andre/.ssh/id_dsa type -1
debug1: key_load_public: No such file or directory
debug1: identity file C:\\Users\\andre/.ssh/id_dsa-cert type -1
debug1: key_load_public: No such file or directory
debug1: identity file C:\\Users\\andre/.ssh/id_ecdsa type -1
debug1: key_load_public: No such file or directory
debug1: identity file C:\\Users\\andre/.ssh/id_ecdsa-cert type -1
debug1: key_load_public: No such file or directory
debug1: identity file C:\\Users\\andre/.ssh/id_ed25519 type -1
debug1: key_load_public: No such file or directory
debug1: identity file C:\\Users\\andre/.ssh/id_ed25519-cert type -1
debug1: Local version string SSH-2.0-OpenSSH_for_Windows_7.6
debug1: Remote protocol version 2.0, remote software version OpenSSH_7.4
debug1: match: OpenSSH_7.4 pat OpenSSH* compat 0x04000000
debug2: fd 3 setting O_NONBLOCK
debug1: Authenticating to elktest.fritz.box:22 as 'root'
debug1: SSH2_MSG_KEXINIT sent
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
debug2: ciphers stoc: chacha20-poly1305@openssh.com,aes128-ctr,aes192-ctr,aes256-ctr
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
debug2: compression stoc: none
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-group-exchange-sha1,diffie-hellman-group14-sha256,diffie-hellman-group14-sha1,diffie-hellman-group1-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,aes128-cbc,aes192-cbc,aes256-cbc,blowfish-cbc,cast128-cbc,3des-cbc
debug2: ciphers stoc: chacha20-poly1305@openssh.com,aes128-ctr,aes192-ctr,aes256-ctr,aes128-gcm@openssh.com,aes256-gcm@openssh.com,aes128-cbc,aes192-cbc,aes256-cbc,blowfish-cbc,cast128-cbc,3des-cbc
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
debug1: expecting SSH2_MSG_KEX_ECDH_REPLY
debug1: Server host key: ecdsa-sha2-nistp256 SHA256:Er7+N/iVsTZRgjPs4EL0UgBNDXDQFFMxpTBI1tXfORE
debug1: Host 'elktest.fritz.box' is known and matches the ECDSA host key.
debug1: Found key in C:\\Users\\andre/.ssh/known_hosts:3
debug2: set_newkeys: mode 1
debug1: rekey after 134217728 blocks
debug1: SSH2_MSG_NEWKEYS sent
debug1: expecting SSH2_MSG_NEWKEYS
debug1: SSH2_MSG_NEWKEYS received
debug2: set_newkeys: mode 0
debug1: rekey after 134217728 blocks
debug1: pubkey_prepare: ssh_get_authentication_socket: No such file or directory
debug2: key: C:\\Users\\andre/.ssh/id_rsa (0000000000000000)
debug2: key: C:\\Users\\andre/.ssh/id_dsa (0000000000000000)
debug2: key: C:\\Users\\andre/.ssh/id_ecdsa (0000000000000000)
debug2: key: C:\\Users\\andre/.ssh/id_ed25519 (0000000000000000)
debug1: SSH2_MSG_EXT_INFO received
debug1: kex_input_ext_info: server-sig-algs=<rsa-sha2-256,rsa-sha2-512>
debug2: service_accept: ssh-userauth
debug1: SSH2_MSG_SERVICE_ACCEPT received
debug1: Authentications that can continue: publickey,gssapi-keyex,gssapi-with-mic,password
debug1: Next authentication method: publickey
debug1: Trying private key: C:\\Users\\andre/.ssh/id_rsa
debug1: Trying private key: C:\\Users\\andre/.ssh/id_dsa
debug1: Trying private key: C:\\Users\\andre/.ssh/id_ecdsa
debug1: Trying private key: C:\\Users\\andre/.ssh/id_ed25519
debug2: we did not send a packet, disable method
debug1: Next authentication method: password
debug1: read_passphrase: can't open /dev/tty: No such file or directory
root@elktest.fritz.box's password:
debug2: we sent a password packet, wait for reply
debug1: Authentication succeeded (password).
Authenticated to elktest.fritz.box ([192.168.188.54]:22).
debug1: channel 0: new [client-session]
debug2: channel 0: send open
debug1: Requesting no-more-sessions@openssh.com
debug1: Entering interactive session.
debug1: pledge: network
debug1: console supports the ansi parsing
debug1: client_input_global_request: rtype hostkeys-00@openssh.com want_reply 0
debug2: channel_input_open_confirmation: channel 0: callback start
debug2: fd 3 setting TCP_NODELAY
debug2: client_session2_setup: id 0
debug2: channel 0: request pty-req confirm 1
debug2: channel 0: request shell confirm 1
debug2: channel_input_open_confirmation: channel 0: callback done
debug2: channel 0: open confirm rwindow 0 rmax 32768
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
Last login: Sat Mar 23 01:36:02 2019 from desktop-79p7akv.fritz.box
debug2: client_check_window_change: changed
debug2: channel 0: request window-change confirm 0
[root@elktest ~]#
[root@elktest ~]#
[root@elktest ~]#
[root@elktest ~]#
[root@elktest ~]# debug2: client_check_window_change: changed
debug2: channel 0: request window-change confirm 0

Jemand eine Idee, was ich noch machen könnte?

Viele Grüße
 
Ich nehme mal an das jede interaktion mit der Shell auf dem PC lange dauert..
Ich vermute mal das du die Ports auf dem Windows-PC geforwarded hast?
Meine Vermutung ist das die VM und dein Lan das gleiche Subnetz haben weswegen die Pakete erstmal ins Lan geroutet werden.
Wenn du den Port auf deinen Host weiterleitest hat dein Handy das Problem nicht.
LG

Fluffy
 
Hi Fluffy,

erstmal vielen Dank für deine Antwort. Ich stecke nicht so tief in der Materie. Nur zum Verständnis: Mit Port Forwarding meinst du NAT ? Ich hatte die VM auf Bridged stehen, so dass ich eigentlich davon ausgehe, dass sowohl mein PC, auf dem die VM läuft, als auch das Handy auf die gleiche Weise ins LAN mit der VM kommunizieren. Sprich kein Port Forwarding. Kannst du das noch einmal ausführen? :)

Deine Annahme, dass jede Interaktion mit der Shell lange dauert, ist allerdings nicht korrekt. Es ist tatsächlich nur die Passworteingabe. Danach läuft alles ganz normal. Sowohl die Commands und die Antwort, als auch das hochladen von Dateien ...

Da der PC noch recht neu war, musste ich ihn eh neu aufsetzen. Mir scheint so als hätte VirtualBox bei AMD CPUs noch ein paar Probleme. Möglicherweise lag es aber auch an der OpenSSH Implementierung von MobaXTerm, die irgendwas zerschossen hat. Jedenfalls habe ich jetzt neue Test VMs unter VMware Workstation Pro laufen und sowohl mit Putty als auch mit der nativen OpenSSH Implementierung von Microsoft funktioniert nun wieder alles wie gehabt.

Danke bis hier hin.

Viele Grüße
 
Hallo,
Freut mich zu hören das deine Probleme sich in wohlgefallen aufgelöst haben.
Nun Bridging erzeugt ein virtuelles Netzwerkinterface aus 2 separaten Netzten, du hast dann also nur einen Netzwerkstack.
Port forwarding ist routing(Layer3 wenn ich mich nicht irre).
d.h. du sagst deinem Host das alle anfragen an Port X nach Port Y auf einer anderen Machine die i.w. ist weiterleitet werden sollen.

Bsp.:
Wenn deine VM compromitiert ist, ist der Netzwerkstack deines Hostes noch lange nicht.
 
Da der PC noch recht neu war, musste ich ihn eh neu aufsetzen. Mir scheint so als hätte VirtualBox bei AMD CPUs noch ein paar Probleme. Möglicherweise lag es aber auch an der OpenSSH Implementierung von MobaXTerm, die irgendwas zerschossen hat. Jedenfalls habe ich jetzt neue Test VMs unter VMware Workstation Pro laufen und sowohl mit Putty als auch mit der nativen OpenSSH Implementierung von Microsoft funktioniert nun wieder alles wie gehabt.
Zum Vergrößern anklicken....

Das Phaenomen kenne ich von Kisten wo WLAN und LAN gleichzeitig - oder auch ein VPN - aktiv ist (welches dann auch gerne default GW ist).
 
Zuletzt bearbeitet:
Necropost für künftige Besucher.
30s Wartezeit beim Login sind typisch für DNS-Probleme. Der SSH-Server versucht eine Reverse-Auflösung der Client-IP, um das zu loggen. Wenn er keinen DNS-Server erreichen kann, oder der nicht antwortet (z.B. die passende private Zone für die PTRs nicht angelegt wurde), dauert das eben. Ob es daran liegt, kann man einfach feststellen, indem man nach erfolgtem Login mal versucht, auf dem SSH-Server die IP rückwärts aufzulösen, von der aus der SSH-Server den Login erhalten hat.
 
Das, was carwe schreibt, lässt sich in der Config des sshd deaktivieren:
serverfault.com

SSH reverse DNS lookup

I was wondering why I'm connection to a server with SSH, it does a reverse DNS lookup on the IP of the remote server. I have found comments telling that it was for security reason, lots of tutorial
serverfault.com serverfault.com
 
Um antworten zu können musst du eingeloggt sein.
Zurück
Oben