Heute ist mir etwas sehr Merkwürdiges aufgefallen:
Ich habe einen Server (auf dem Ubuntu Server 12.04.4 LTS läuft) in meinem lokalen Netzwerk, dessen SSH-Port über das Internet zugänglich ist (ich kann mich über verbinden ssh my.internet.ip.address).
Allerdings ist mir erst heute aufgefallen, dass ich keine Verbindung dazu im lokalen Netzwerk herstellen kann ( ssh its.local.ip.addressschlägt ohne Fehler fehl).
Ich habe nachgeschaut /etc/hosts.denyund meinen Computer explizit hinzugefügt /etc/hosts.allow, aber das hat nichts geändert. Natürlich habe ich auch versucht, SSH und den gesamten Server neu zu starten. Es sind keine neuen Updates verfügbar.
Lokale Verbindung schlägt fehl:
myself@my-desktop ~ $ ssh -v its.local.ip.address
OpenSSH_6.2p2 Ubuntu-6ubuntu0.4, OpenSSL 1.0.1e 11 Feb 2013
debug1: Reading configuration data /etc/ssh/ssh_config
debug1: /etc/ssh/ssh_config line 19: Applying options for *
debug1: Connecting to its.local.ip.address [its.local.ip.address] port 22.
debug1: Connection established.
debug1: identity file /home/myself/.ssh/id_rsa type -1
debug1: identity file /home/myself/.ssh/id_rsa-cert type -1
debug1: identity file /home/myself/.ssh/id_dsa type -1
debug1: identity file /home/myself/.ssh/id_dsa-cert type -1
debug1: identity file /home/myself/.ssh/id_ecdsa type -1
debug1: identity file /home/myself/.ssh/id_ecdsa-cert type -1
debug1: Enabling compatibility mode for protocol 2.0
debug1: Local version string SSH-2.0-OpenSSH_6.2p2 Ubuntu-6ubuntu0.4
debug1: Remote protocol version 2.0, remote software version OpenSSH_5.9p1 Debian-5ubuntu1.4
debug1: match: OpenSSH_5.9p1 Debian-5ubuntu1.4 pat OpenSSH_5*
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: sending SSH2_MSG_KEX_ECDH_INIT
debug1: expecting SSH2_MSG_KEX_ECDH_REPLY
Connection closed by its.local.ip.address
myself@my-desktop ~ $
Die Remoteverbindung funktioniert jedoch:
myself@my-desktop ~ $ ssh -v my.internet.ip.address
OpenSSH_6.2p2 Ubuntu-6ubuntu0.4, OpenSSL 1.0.1e 11 Feb 2013
debug1: Reading configuration data /etc/ssh/ssh_config
debug1: /etc/ssh/ssh_config line 19: Applying options for *
debug1: Connecting to my.internet.ip.address [my.internet.ip.address] port 22.
debug1: Connection established.
debug1: identity file /home/myself/.ssh/id_rsa type -1
debug1: identity file /home/myself/.ssh/id_rsa-cert type -1
debug1: identity file /home/myself/.ssh/id_dsa type -1
debug1: identity file /home/myself/.ssh/id_dsa-cert type -1
debug1: identity file /home/myself/.ssh/id_ecdsa type -1
debug1: identity file /home/myself/.ssh/id_ecdsa-cert type -1
debug1: Enabling compatibility mode for protocol 2.0
debug1: Local version string SSH-2.0-OpenSSH_6.2p2 Ubuntu-6ubuntu0.4
debug1: Remote protocol version 2.0, remote software version OpenSSH_5.9p1 Debian-5ubuntu1.4
debug1: match: OpenSSH_5.9p1 Debian-5ubuntu1.4 pat OpenSSH_5*
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: sending SSH2_MSG_KEX_ECDH_INIT
debug1: expecting SSH2_MSG_KEX_ECDH_REPLY
debug1: Server host key: ECDSA [... hidden here ...]
debug1: Host 'my.internet.ip.address' is known and matches the ECDSA host key.
debug1: Found key in /home/myself/.ssh/known_hosts:4
debug1: ssh_ecdsa_verify: signature correct
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: password
debug1: Next authentication method: password
[email protected]'s password:
[ ... everything works just fine ... ]
Was kann die Ursache dieses Problems sein und, noch wichtiger, wie kann ich es lösen?
Hinweis: Eine Erhöhung der Ausführlichkeit ( ssh -vvv) bewirkt an der Stelle, an der die beiden Ausgaben abweichen, nichts zusätzlich.
Antwort1
Der Server entscheidet, die Verbindung zu trennen, daher müssen Sie das Problem serverseitig debuggen. Wenn Sie Root-Zugriff auf den Server haben, können Sie Folgendes sshdinteraktiv ausführen:
/path/to/sshd -ddd -p 42
Dadurch wird eine Kopie des sshdAbhörens auf Port 42 (Sie können auch eine andere Nummer angeben) im Debugmodus gestartet. Es wird im Vordergrund ausgeführt, akzeptiert eine einzelne Verbindung und gibt Debuginformationen auf Ihrem Terminal aus.
Verbinden Sie sich jetzt mit Ihrem Kunden:
ssh -v -p 42 its.local.ip.address
Mit etwas Glück sollten die serverseitigen Debugmeldungen anzeigen, warum die Sitzung abgebrochen wird.
Antwort2
Ich gehe davon aus, dass der Client-Rechner in beiden Erfassungen derselbe ist (auch wenn die Eingabeaufforderungen unterschiedlich sind). Da er die TCP-Verbindung zulässt, hängt dies wahrscheinlich mit Reverse-DNS und/oder Ablehnungsrichtlinien in der SSHD-Konfiguration zusammen.
Versuchen Sie, DNS auf der Serverseite auszuschalten (UseDNS=no in sshd_config) und sshd neu zu starten (kill -1 sollte ausreichen).
Antwort3
Dieser Fehler soll mehrere Benutzer betroffen haben.
Versuchen Sie vor Ort ssh -X, um die X-Weiterleitung zu deaktivieren.
Außerdem muss die Maximum Transmission Unit [MTU] möglicherweise an die MTU des SSH-Servers angepasst werden.
** Wenn das lokal nicht funktioniert, versuchen Sie:
myself@my-desktop ~ $ ssh -v my.internet.ip.address
Wenn es Ihr Netzwerk verlassen und wieder hinein gelangen kann …
Es könnten Serverkonfigurationsfehler sein. Überprüfen Sie sshd_config auf „zugelassene Benutzer“ und auch, wo known_host gespeichert wäre. Fügen Sie eine local.ip.address-Version des Benutzers „myself“ hinzu.
eine Kopie von sshd könnte helfen