Ich habe Registrierungsdateien gelöscht, PuTTY deinstalliert und neu installiert und meine IP mit einer Spambot-Datenbank abgeglichen. Ich weiß nicht, was im Hintergrund vor sich geht, aber bei der Fehlerbehebung habe ich gelesen, dass das Hinzufügen des -v
Tags mehr Debuginformationen liefert, also habe ich das getan und die Ausgabe hier eingefügt.
Es sollte beachtet werden, dass ich keinen Zugriff auf den physischen Linux-Server habe, auf dem das Git-Repository gehostet wird, also auf das modifizierte cPanel von GoDaddy (das aus irgendeinem Grund, wenn sich ein Teammitglied per SSH mit dem Server verbindet, weder Shutdown noch Sudo zulässt, obwohl dies meiner Recherche nach die beiden hilfreichsten Befehle wären).
C:\Users\Fish's Ocean>ssh -v [email protected]
OpenSSH_for_Windows_7.6p1, LibreSSL 2.6.4
debug1: Connecting to XXX.XXX.XXX.XXX [XXX.XXX.XXX.XXX] port 22.
debug1: Connection established.
debug1: key_load_public: No such file or directory
debug1: identity file C:\\Users\\Fish's Ocean/.ssh/id_rsa type -1
debug1: key_load_public: No such file or directory
debug1: identity file C:\\Users\\Fish's Ocean/.ssh/id_rsa-cert type -1
debug1: key_load_public: No such file or directory
debug1: identity file C:\\Users\\Fish's Ocean/.ssh/id_dsa type -1
debug1: key_load_public: No such file or directory
debug1: identity file C:\\Users\\Fish's Ocean/.ssh/id_dsa-cert type -1
debug1: key_load_public: No such file or directory
debug1: identity file C:\\Users\\Fish's Ocean/.ssh/id_ecdsa type -1
debug1: key_load_public: No such file or directory
debug1: identity file C:\\Users\\Fish's Ocean/.ssh/id_ecdsa-cert type -1
debug1: key_load_public: No such file or directory
debug1: identity file C:\\Users\\Fish's Ocean/.ssh/id_ed25519 type -1
debug1: key_load_public: No such file or directory
debug1: identity file C:\\Users\\Fish's Ocean/.ssh/id_ed25519-cert type -1
debug1: Local version string SSH-2.0-OpenSSH_for_Windows_7.6
ssh_exchange_identification: read: Connection reset
Antwort1
1. Referenzen
Beachten Sie, dass die debug1: key_load_public
Zeilen zufällig sind. Es handelt sich nicht um Fehler, sondern nur um Warnungen, die die Verbindung selbst nicht beeinträchtigen sollten.
Der häufigste Grund für SSH-Probleme bei Webhosts ist meiner Erfahrung nach, dass man keine SSH/FTP-Identität eingerichtet hat. Der Benutzername und das Passwort, die Sie für die Verbindung verwenden, unterscheiden sich von allen anderen Godaddy-Kontoanmeldeinformationen und müssen oft explizit eingerichtet werden - ein Prozess, der in diesem Artikel beschrieben wird.Anleitung von Godaddy. Stellen Sie sicher, dass Sie Ihre FTP-Anmeldeinformationen kennen. In der Anleitung heißt es:
Suchen Sie Ihren FTP-Benutzernamen und Ihr Passwort
Melden Sie sich bei Ihrem GoDaddy-Konto an und öffnen Sie Ihr Produkt.
Klicken Sie in der oberen Menüleiste auf „Dateien und FTP“ und wählen Sie dann „FTP-Benutzer“ aus.
Um Ihren FTP-Benutzernamen oder Ihr Passwort zu ändern, klicken Sie auf das Dropdown-Menü „Aktionen“ und wählen Sie „Passwort ändern“ oder „Benutzernamen ändern“.
Füllen Sie im neuen Fenster die erforderlichen Felder aus und klicken Sie auf „OK“, um die Änderungen zu bestätigen.
- Verwenden Sie Ihren FTP-Benutzernamen und Ihr Passwort, um die SSH-Verbindung herzustellen …
Beachten Sie auch, dass Befehle wie sudo
oder shutdown
nur verfügbar sind, wenn Sie ein VPS oder dediziertes Hosting von Godaddy verwenden. Wenn Sie irgendeine Art von Shared Hosting verwenden, stehen Ihnen diese nicht zur Verfügung.
2. Schwarze Liste
Es ist auch nicht ungewöhnlich, dass Webhoster wie GodaddyIPs auf die schwarze Liste setzenbei denen mehrere Verbindungsversuche fehlgeschlagen sind. Unabhängig von Ihrem ursprünglichen Problem kann dies nun der Grund für das Zurücksetzen der Verbindung sein. Sie könnten erneut mit dem Support chatten und fragen, ob es möglich ist, eine solche schwarze Liste zu entfernen. Sie könnten auch versuchen, Ihren Computer an die Internetverbindung Ihres Mobilgeräts anzubinden (falls möglich) und es mit Putty noch einmal zu versuchen.