Hallo zusammen, vorab: Ich lebe in China, das Webseiten, Ports und andere Sachen geblockt sind gehört hier zum Alltag. Ich habe mir einen VPS bei einem bekannten Anbieter gemietet (Ich nenne hier mal vorab keine Namen um diverse Bashings zu vermeiden...). Frische Ubuntu 22.04 Installation, kein SSH Zugriff möglich. OK, eventuell ist Port 22 geblockt. Dazu muss ich sagen, vor ein paar Monaten hatte ich auch einen VPS gemietet, da war SSH (allerdings von einer anderen Location aus) kein Problem. systemctl status ssh zeigt mir diverse Loginversuche per SSH von Servern weltweit (Hackattempts), der Server scheint also generell erreichbar. Ich habe dann den Port in der sshd_config auf 2345 geändert, ufw auch entsprechend modifiziert. Alles scheint zu funktionieren, aber immer noch kein SSH Zugriff. Dann habe ich noch portquiz.net:2345 aufgerufen, wo mir bestätigt wird das mein ausgehender Port 2345 offen ist. Ich bin nun etwas ratlos. Support wurde kontaktiert, aber bisher nur die Standard Antworten netstat -tulpen probieren blabla. Irgendwelche Ideen wo man noch drehen kann? Und was könnte das Problem beim Provider selbst sein? Ich komme aktuell nur per VNC auf den Server was allerdings etwas suboptimal ist....
Vermutlich wird SSH vom GreatFirewall anhand seiner ssh-Signatur ausgefiltert und nicht auf Portebene. Probier mal sowas: https://github.com/nwtgck/piping-ssh-web
Du musst erstmal schauen, an welchem Punkt es überhaupt fehlschlägt. Gib beim ssh Aufruf mal "-v" als Argument mit, dann bekommt man Debug Meldungen angezeigt. Am Anfang sollte sowas stehen:
1 | debug1: Connecting to example.com [10.0.0.1] port 22. |
2 | debug1: Connection established. |
3 | ... |
4 | debug1: Local version string SSH-2.0-OpenSSH_9.2p1 Debian-2+deb12u3 |
5 | debug1: Remote protocol version 2.0, remote software version OpenSSH_9.6 |
6 | debug1: compat_banner: match: OpenSSH_9.6 pat OpenSSH* compat 0x04000000 |
Wenn "Connection established" kommt, ist die TCP Verbindung aufgebaut. Wenn "Remote protocol version" kommt, hat man den Versionsstring bekommen. Wenn nichts passiert, ist schon die Verbindung fehlgeschlagen. Das sieht man auch mit nc (netcat):
1 | $ nc example.com 22 |
2 | SSH-2.0-OpenSSH_9.6 |
3 | ^C |
Ab dem Punkt ist es die TCP Verbindung schonmal OK. Als nächstes sollte fragen ob der Fingerprint ok ist (sofern nicht schon in der .known_hosts vorhanden). Sicher stellen dass der übereinstimmt. Danach steht die Verschlüsselung. Danach kommt noch die Authentifizierung. Falls der schritt Fehlschlägt, stimmen entweder die Zugangsdaten nicht, die Authentifizierungsmethode ist nicht erlaubt, oder der Login ist deaktiviert. Das kann viele Ursachen haben. z.B. wenn man login per Root versucht, aber das in der Konfig nicht erlaubt hat. Oder der Account gelockt ist. Oder die Login Shell auf /bin/false oder /usr/sbin/nologin gesetzt ist. Oder man nur Logins per Key in der sshd Config erlaubt hat, aber keinen hinterlegt hat. etc.
wie lautet denn in der /etc/sshd_config des Hosts die Zeile PermitRootLogin, da ist prohibit-password die Vorgabe.
Benedikt L. schrieb: > Vermutlich wird SSH vom GreatFirewall anhand seiner ssh-Signatur > ausgefiltert und nicht auf Portebene. > > Probier mal sowas: > https://github.com/nwtgck/piping-ssh-web Das funktioniert - wow! Fun fact: die Piping Website selbst kann man ohne VPN von China aus aufrufen :D
Daniel A. schrieb: > Du musst erstmal schauen, an welchem Punkt es überhaupt fehlschlägt. > > Gib beim ssh Aufruf mal "-v" als Argument mit, dann bekommt man Debug > Meldungen angezeigt. > > Am Anfang sollte sowas stehen: >
1 | > debug1: Connecting to example.com [10.0.0.1] port 22. |
2 | > debug1: Connection established. |
3 | > ... |
4 | > debug1: Local version string SSH-2.0-OpenSSH_9.2p1 Debian-2+deb12u3 |
5 | > debug1: Remote protocol version 2.0, remote software version OpenSSH_9.6 |
6 | > debug1: compat_banner: match: OpenSSH_9.6 pat OpenSSH* compat 0x04000000 |
7 | > |
Es hakt schon an der Verbindung, "connecting to..." und danach bekomme ich einen Timeout Das in der anderen Antwort genannte SSH Web Piping funktioniert hingegen (klar). Scheint eine weitere Eskalationsstufe zu sein - vor einem Jahr war SSH problemlos möglich. Ich werde mal weitere Standorte probieren, evtl. ist hier wieder mal ein lokaler Aufpasser übervorsichtig durchgedreht...
Stephan S. schrieb: > wie lautet denn in der /etc/sshd_config des Hosts die Zeile > PermitRootLogin, da ist prohibit-password die Vorgabe. Ich bekomme gar nicht erst eine Serververbindung zustande, nur VNC funktioniert.
Thomas F. schrieb: > Ich bekomme gar nicht erst eine Serververbindung zustande, nur VNC > funktioniert. Und Du weisst nicht (mehr?), wie der Host konfiguriert ist? Gibt es andere User, über die Du Dich einloggen könntest? Manche Hoster (z.B. Hetzner) bieten auch eine Konsole. Normalerweise bieten Hoster entweder User/Password und alternativ PublicKey an und geben den SSH-Port vor, den man dann selbst ändern kann.
:
Bearbeitet durch User
Es gibt nur root als einzigen Benutzer, das System ist ein Standard Ubuntu 22.04 image. PermitRootLogin ist aktiviert. Aber wie weiter oben schon gesagt, ich bekomme schon ein Timeout bei der Verbindungserstellung. Ich werde das nochmal an verschiedenen Standorten probieren, eventuell ist es nur ein lokales Problem. Also wenn das (in der breiten Masse) ganz China betrifft, wäre das schon hart... VNC funktioniert übrigens.
:
Bearbeitet durch User
Thomas F. schrieb: > VNC funktioniert übrigens. Und warum reicht Dir das nicht? Etwa unverschlüsseltes VNC? Kannst Du per VNC den SSH-Port ändern und dann über diese Port-Nr. (590x?) Dein SSH machen? VNC müsste dann deaktiviert werden oder 590y nehmen.
:
Bearbeitet durch User
Thomas F. schrieb: > Scheint eine weitere Eskalationsstufe zu sein - vor einem Jahr war SSH > problemlos möglich. Wobei es umso wahrscheinlicher mit der Zeit dicht gemacht wird, je verbreiteter die Lösung ist. Es kann also sein, dass du mit den Jahren immer mal Arbeit bekommst.
Da der Verbindungsaufbau (connect) schon scheitert, sind ja noch keinerlei Daten über die Verbindung gegangen die als ssh-signatur dienen könnten. Ergo ist einfach nur der Port 2345 gesperrt. Da genau dieser Port auch von diverser Malware zur Kommunikation genutzt wird, ist halt so ne schone Nummer, ist der evtl. deswegen gesperrt. Ich würde erstmal ne weniger schöne Nummer als Port probieren.
Angehängte Dateien:
-
portquiz.png
45 KB
Matthias M. schrieb: > Da der Verbindungsaufbau (connect) schon scheitert, sind ja noch > keinerlei Daten über die Verbindung gegangen die als ssh-signatur dienen > könnten. > Ergo ist einfach nur der Port 2345 gesperrt. > > Da genau dieser Port auch von diverser Malware zur Kommunikation genutzt > wird, ist halt so ne schone Nummer, ist der evtl. deswegen gesperrt. > > Ich würde erstmal ne weniger schöne Nummer als Port probieren. Selbst der Standard SSH Port 22 ist gesperrt... Laut Verbindungsversuch mit dem Portquiz Projekt mittels portquiz.net:2345 ist mein Port 2345 offen.
:
Bearbeitet durch User
Dann nimm 49152
Ich würde nichts über 32768 verwenden, die Ports werden von Linux Systemen in der Regel als Ephemeral Ports verwendet - also wenn für eine Verbindung ein Beliebiger Port gewählt werden muss. Ich würde Ports wie 8000, 8080, 8443, 80, 443, 25, usw. versuchen. Also Ports, die für Sachen wie HTTP, Mail, und solche Sachen normalerweise verwendet werden. Die sind oft offen.
:
Bearbeitet durch User
Nimm mal nen neuen Port und verbinde dich direkt mit ssh -v. Kann ja sein, ob das ein SSH port ist, wissen die ja erst, wenn das erste mal der SSH header vom Server kommt. Das heißt die erste Verbindung zu nem neuen Port müsste wenigstens aufgebaut werden... Anderer Test. Mach auf dem Server nc -l 12345 (12345 ist ein beliebiger Port) und dann bei dir: nc SERVERIP 12345 Wenn die Verbindung steht, gibt auf dem Server den SSH Erkennungsstring ein: SSH-2.0-OpenSSH_9.6 und guck ob der ankommt oder die Verbindung gekappt wird.
Ein T. schrieb: > [1] https://github.com/bryanpkc/corkscrew Das mag ja funktionieren, aber das ist ein Netzwerkprogramm in C bei dem der letzte Commit vor 7 Jahren war. Ich hätte da ernste Zweifel bezüglich der Sicherheit das auf meinem Server laufen zu lassen. C ist durchaus empfindlich für Pufferüberläufe und ähnliches. Hier ist es direkt von außen ansprechbar und damit können diese Pufferüberläufe sofort zu Remote Code Execution führen. Wenn ein Projekt gut und aktiv gepflegt ist, werden solche Probleme erkannt und zeitnah gelöst. Dazu aktive Suche mit Codeanalyse, Fuzzing etc. Dann wäre es ok. Aber hier macht seit 7 Jahren niemand mehr was, daher freies Feld für Angreifer. Mein Vorschlag als Alternative: https://github.com/vi/websocat Das einfach per systemd socket laufen lassen.
Thread beobachten
Seitenaufteilung abschaltenBitte melde dich an um einen Beitrag zu schreiben. Anmeldung ist kostenlos und dauert nur eine Minute.
Bestehender Account
Schon ein Account bei Google/GoogleMail? Keine Anmeldung erforderlich!
Mit Google-Account einloggen
Mit Google-Account einloggen
Noch kein Account? Hier anmelden.