ssh von meinem Mac hängt nach der Authentifizierung an einem beliebigen Ort, unabhängig von der App. Es ist definitiv der Mac. Ideen?

Ich habe ein MacBook Pro mit Mojave 10.14.1. Wenn ich nach der Eingabe meines Passworts versuche, irgendwo zu ssh, bleibt die ssh-Sitzung sofort nach der Authentifizierung hängen. Unabhängig von SSH App! Und ich bin ratlos.

Die Fakten:

• Dies ist nur ssh direkt von der Kommandozeile aus - keine X-Weiterleitung oder irgendetwas.
• Alle anderen Netzwerke auf dem Mac sind in Ordnung (Safari, Outlook, Bildschirmfreigabe usw.)
• ssh macht das unabhängig vom Ziel. Ich habe eine Menge Diagnosen durchgeführt, aber nur um die Serverseite vollständig zu eliminieren, habe ich Folgendes getan: (1) einen neuen SSH-Schlüssel erstellt, (2) eine neue Deb 9-VM bei Digital Ocean mit diesem Schlüssel hochgefahren, ( 3) versuchte ssh mit diesem Schlüssel. Hing an genau derselben Stelle mit genau demselben Fehler. Habe den Schlüssel auf einem anderen System verwendet und es hat wie erwartet funktioniert.
• Dies geschieht unabhängig von der Anwendung. Damit meine ich, ich sehe das gleiche Verhalten in MacOS native Terminal, iTerm2 und RoyalTS. Seltsam! Ich nehme an, sie benutzen alle eine gemeinsame Bibliothek darunter, aber ... was?
• FileZilla mit SFTP und den gleichen Anmeldeinformationen (und Port) funktioniert einwandfrei.
• Wenn ich sudo auf dem Macbook roote und das gleiche ssh versuche, erhalte ich das gleiche Ergebnis.
• Auf dem Mac (oder den Servern) läuft kein VPN.
• Unten sehen Sie ein Sitzungsbeispiel von einem Server in meinem LAN. Ich weiß, dass ich am Montagmorgen auf diesen Server ssh konnte. Funktioniert immer noch von anderen Systemen. In diesem Fall gehe ich über WLAN zu einem Server, der sich in demselben Subnetz in Ethernet befindet.
• Dies ist keine DNS-Zeitüberschreitung (dh durch UseDNS behoben).
• Genau gleiches Verhalten, egal ob Passwort oder Schlüssel. Endet am selben "open confirm rwindow" Punkt mit dem selben Fehler.

Nur um die Geschichte aufzupeppen:

• Ich habe dieses System am Montag über die Genius-Leiste an Apple gesendet, um den Bildschirm auszutauschen (Rückruf des Delaminierungsproblems). Habe es heute Morgen von ihrer Reparaturwerkstatt in Houston, TX zurückbekommen (Hin- und Rückfahrt: ca. 88 Stunden).
• Dieselbe Seriennummer, aber der Deckel wurde komplett ausgetauscht (ohne Kratzer), was in Ordnung ist. Ich besitze keinen Alufolienhut, aber ssh hat perfekt funktioniert, bevor ich es an Apple geschickt habe ... hmmm ... ;-)

Hier ist die Client-Seite ... Die einzigen Änderungen, die ich am Protokoll unten vorgenommen habe, sind ein globales Suchen / Ersetzen nach meinem Namen (an MYUSER):

$ ssh -vv MYUSER@192.168.1.5
OpenSSH_7.8p1, LibreSSL 2.7.3
debug1: Reading configuration data /etc/ssh/ssh_config
debug1: /etc/ssh/ssh_config line 48: Applying options for *
debug2: resolve_canonicalize: hostname 192.168.1.5 is address
debug2: ssh_connect_direct
debug1: Connecting to 192.168.1.5 [192.168.1.5] port 22.
debug1: Connection established.
debug1: identity file /Users/MYUSER/.ssh/id_rsa type 0
debug1: identity file /Users/MYUSER/.ssh/id_rsa-cert type -1
debug1: identity file /Users/MYUSER/.ssh/id_dsa type -1
debug1: identity file /Users/MYUSER/.ssh/id_dsa-cert type -1
debug1: identity file /Users/MYUSER/.ssh/id_ecdsa type -1
debug1: identity file /Users/MYUSER/.ssh/id_ecdsa-cert type -1
debug1: identity file /Users/MYUSER/.ssh/id_ed25519 type -1
debug1: identity file /Users/MYUSER/.ssh/id_ed25519-cert type -1
debug1: identity file /Users/MYUSER/.ssh/id_xmss type -1
debug1: identity file /Users/MYUSER/.ssh/id_xmss-cert type -1
debug1: Local version string SSH-2.0-OpenSSH_7.8
debug1: Remote protocol version 2.0, remote software version OpenSSH_7.4p1 Debian-10+deb9u4
debug1: match: OpenSSH_7.4p1 Debian-10+deb9u4 pat OpenSSH_7.0*,OpenSSH_7.1*,OpenSSH_7.2*,OpenSSH_7.3*,OpenSSH_7.4*,OpenSSH_7.5*,OpenSSH_7.6*,OpenSSH_7.7* compat 0x04000002
debug2: fd 3 setting O_NONBLOCK
debug1: Authenticating to 192.168.1.5:22 as 'MYUSER'
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-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,rsa-sha2-512-cert-v01@openssh.com,rsa-sha2-256-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
debug1: expecting SSH2_MSG_KEX_ECDH_REPLY
debug1: Server host key: ecdsa-sha2-nistp256 SHA256:oQ+J1YFF5ptE7oSYzQ6YXYGAOpwvzlfNAMsVlZsJIPI
debug1: Host '192.168.1.5' is known and matches the ECDSA host key.
debug1: Found key in /Users/MYUSER/.ssh/known_hosts:116
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
debug2: key: /Users/MYUSER/.ssh/id_rsa (0x7f9e11513e00)
debug2: key: /Users/MYUSER/.ssh/id_dsa (0x0)
debug2: key: /Users/MYUSER/.ssh/id_ecdsa (0x0)
debug2: key: /Users/MYUSER/.ssh/id_ed25519 (0x0)
debug2: key: /Users/MYUSER/.ssh/id_xmss (0x0)
debug1: SSH2_MSG_EXT_INFO received
debug1: kex_input_ext_info: server-sig-algs=<ssh-ed25519,ssh-rsa,ssh-dss,ecdsa-sha2-nistp256,ecdsa-sha2-nistp384,ecdsa-sha2-nistp521>
debug2: service_accept: ssh-userauth
debug1: SSH2_MSG_SERVICE_ACCEPT received
debug1: Authentications that can continue: publickey,password
debug1: Next authentication method: publickey
debug1: Offering public key: RSA SHA256:Jg8d5Nwt0kNN1geeAJpoNsyj6q7X1pJJ0JCXguxCEew /Users/MYUSER/.ssh/id_rsa
debug2: we sent a publickey packet, wait for reply
debug1: Authentications that can continue: publickey,password
debug1: Trying private key: /Users/MYUSER/.ssh/id_dsa
debug1: Trying private key: /Users/MYUSER/.ssh/id_ecdsa
debug1: Trying private key: /Users/MYUSER/.ssh/id_ed25519
debug1: Trying private key: /Users/MYUSER/.ssh/id_xmss
debug2: we did not send a packet, disable method
debug1: Next authentication method: password
MYUSER@192.168.1.5's password: 
debug2: we sent a password packet, wait for reply
debug1: Authentication succeeded (password).
Authenticated to 192.168.1.5 ([192.168.1.5]:22).
debug1: channel 0: new [client-session]
debug2: channel 0: send open
debug1: Requesting [email protected]
debug1: Entering interactive session.
debug1: pledge: network
debug1: client_input_global_request: rtype [email protected] 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
debug1: Sending environment.
debug1: Sending env LANG = en_US.UTF-8
debug2: channel 0: request env confirm 0
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

Lange hier warten, und dann ...

packet_write_wait: Connection to 192.168.1.5 port 22: Broken pipe

Der einzige Nichtkommentar in der / etc / ssh / ssh_config des Macbooks ist

Host *
    SendEnv LANG LC_*

... das ist das gleiche wie bei einem anderen iMac, den ich überprüft habe.

https://superuser.com/questions/1373697/ssh-fails-on-macos-mojave-10-14-1 hat die Lösung.

In / etc / ssh / ssh_config:

Host *
     IPQoS lowdelay throughput

IIRC, der Genius Bar-Techniker, hat vor dem Versenden ein Mojave-Update durchgeführt (da ich eine Frage zu Hardware-Problemen hatte), in dem das vor und nach der Reparatur durchgeführte Szenario erläutert wird.