Ich versuche, von einem MacBook Air (MacOS 10.14.6) über SSH (ohne Passwort) eine Verbindung zu einem Ubuntu-Rechner (16.04.6) herzustellen, und zwar mit einem Befehl wie
ssh aaa.bbb.ccc.ddd
Es funktionierte immer reibungslos, ich bekam eine Eingabeaufforderung und konnte mit der Arbeit auf dem Remote-Computer beginnen.
Seit ungefähr einer Woche funktioniert dies jedoch nicht mehr, ohne dass ich bewusst Änderungen am Anmeldevorgang, neuen Benutzern, Kennwortänderungen, Schlüsseländerungen, Betriebssystem-Upgrades, Änderungen usw. vorgenommen habe. .profileIch .bashrchabe auch nachgesehen /etc/hosts.allow, /etc/hosts.denyaber nichts gefunden, und ich habe die Ubuntu-Maschine und den Mac neugestartet, aber keine Änderung.
Sobald ich mich erfolgreich anmelde, sehe ich eine Nachricht
Last login: ... from www.xxx.yyy.zzz
Connection to aaa.bbb.ccc.ddd closed
Wie kann ich das Problem beheben?
Nachtrag
Beim Überprüfen /var/log/auth.logsehe ich folgende Einträge:
Oct 16 07:02:38 mac353 systemd-logind[1173]: New session 11 of user alex.
Oct 16 07:02:38 mac353 sshd[11834]: Received disconnect from www.xxx.yyy.zzz port 61437:11: disconnected by user
Oct 16 07:02:38 mac353 sshd[11834]: Disconnected from www.xxx.yyy.zzz port 61437
Antwort1
Oct 16 07:02:38 mac353 sshd[11834]: Received disconnect from www.xxx.yyy.zzz port 61437:11: disconnected by user
Ist www.xxx.yyy.zzzdie IP-Adresse für Ihr MacBook Air aktuell richtig?
Es kann sein, dass ein anderes System im Netzwerk dieselbe IP-Adresse verwendet. Sie können eine Verbindung normal herstellen, aber alle Antworten werden zufällig an beide Systeme gesendet, die am IP-Adresskonflikt beteiligt sind. Der Server muss daher möglicherweise einige seiner ausgehenden Pakete erneut senden. Normalerweise antwortet das System, das tatsächlich aktiv versucht, eine Verbindung herzustellen, schneller. Für einige anfängliche Pakete scheint es also so, als ob es problemlos funktioniert.
Aber irgendwann denkt sich der TCP/IP-Treiber des Konfliktsystems: „Was ist das für ein Datenverkehr? Ich habe gerade keine solche aktive TCP-Verbindung.“ und sendet ein TCP-Reset-Paket zurück an die Quelle des verdächtig aussehenden Datenverkehrs, also an den Server. Da das Konfliktsystem dieselbe IP-Adresse wie Ihr MacBook hat, kann der Server nicht wissen, dass der TCP-Reset nicht wirklich zu Ihrer Verbindung gehört, und so wird der Server annehmen, dass der TCP-Reset bedeutet:Duwollte die Verbindung trennen. Dies geschieht nicht sofort, da das Senden von TCP-Reset-Paketen im TCP/IP-Treiber normalerweise ein Job mit niedriger Priorität ist.
Dies wäre ein sehr typisches Symptom eines IP-Adresskonflikts.
Um das in Konflikt stehende System zu finden, können Sie versuchen, die MAC-Adresstabellen des Netzwerk-Switches (sofern es sich um einen verwalteten Switch handelt) oder des WLAN-AP Ihres lokalen Netzwerksegments zu überprüfen. Wenn Ihre IP-Adresse mit einer MAC-Adresse verknüpft ist, die nicht zu Ihrem MacBook gehört, haben Sie die MAC-Adresse des in Konflikt stehenden Systems gefunden. In einem kabelgebundenen Netzwerk können Sie dann prüfen, welcher Switch-Port diese MAC-Adresse gesehen hat, und dann einfach nachsehen, was sich am anderen Ende des Kabels befindet.
Wenn Sie keine verwalteten Switches haben oder keinen Zugriff darauf haben, können Sie versuchen, Ihre eigene IP-Adresse anzupingen und zu sehen, ob Sie doppelte Antworten erhalten. Oder Sie können das arpingKommandozeilentool verwenden, um dasselbe mit ARP-Paketen zu tun: Damit werden sogar Systeme erfasst, die nicht auf Pings antworten.
Antwort2
Die Lösung für dieses Problem war eine set -eDatei, /etc/profile.ddie in einem völlig anderen Kontext installiert wurde. Nach dem Umbenennen dieser Datei sshfunktionierte die Anmeldung wieder.
`set -e`
stoppt die Ausführung eines Skripts, wenn ein Befehl einen Fehler aufweist (siehe hier) und wird von manchen als schlechte Praxis angesehen.