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.
Gerd E. schrieb: > der letzte Commit vor 7 Jahren war Wieso, wieso um Gottes Willen sollen Programme immer ein aktuelles Commit haben? Wenn das Programm, der Code, seit 7 Jahren absolut fehlerfrei und sicher läuft - warum sollte man diesen dann ändern? WAS sagt dir das corksrew angreifbar für RCE ist? Würde es dich ernsthaft beruhigen das jemand einfach nur nen Kommentar ändert und ein commit macht - damit dann da steht das der letzte commit vor nem Monat war - aber der Code ansich der gleiche wie vor 10 Jahren ist? Corkskrew ist verbreitet, Corksrew wird aktiv eingesetzt - es sind keine Angriffspunkte bei Corksrew bekannt. Und um deine "Angst" noch ein bisschen Anzuheizen: Corksrew ist nicht von Bryan Chan sondern von Pat Padgett aka AgroMan aus dem Jahr 2001. Das Repo ist ein Backup weil die Distro Seite von AgroMan down ist, Bryan hat es getweakt und auf Git gesetzt.
Rene K. schrieb: > Wieso, wieso um Gottes Willen sollen Programme immer ein aktuelles > Commit haben? Das ist das CI/CD-Mantra, religionsgleich, daß Software nur funktionieren kann, wenn es ständig Updates und Patches dafür gibt. Daß das ein sehr bedenkliches Licht auf die Qualität der von diesen Leuten produzierte Software und damit auch auf ihre Arbeitsweise wirft, das blenden sie natürlich konsequent aus (richtige Religion funktioniert nur mit einer Prise Bigotterie) ... Und auch das hysterische "Oh Gott, das ist C, das ist ja unsicher, das kann ja /buffer overflows/" passt in die gleiche Kerbe. Solche Leute brauchen dann Programmiersprachen für betreutes Programmieren, und müssen dann aber trotzdem "unser täglich Update gib' uns heute" tanzen. Nun, wenn Software aus drölfundachtzig irgendwo im Internet zusammengestoppelter "Libs" besteht (und die Sprachen für betreutes Programmieren unterstützen das sogar aktiv durch zum Sprachstandard gehörende Paketmanager), dann weiß der geneigte betreute Programmierer letztlich gar nicht, was sein Programm da tut und kann sich immer damit herausreden, daß das ja "die Libs" sind, derentwegen die ganzen Patches/Updates etc. nötig wären, und "die Libs" hat er sich "gezogen", weil er zu faul und zu desinteressiert war, sich mit seinem Problem zu beschäftigen und drei Zeilen Code selbst zu schreiben. A = B + C? ja, da gibt es LibAdder ... X = 0? Da gibt es LibNull und LibZer0, die Maintainer bewerfen sich mit Wattebällchen und tanzen ihren CoC ...
Gerd E. schrieb: > 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. Stabile Software braucht keine Updates. > 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. Dann lies doch einfach mal die 295 Zeile Sourcecode! Ja, mehr ist das nicht, Libraries sind irrelevant, die werden dynamisch gelinkt und von anderer Stelle gepflegt, zählen also nicht für Risiken bzgl. dieses Programms. Du würdest dann sehen, dass da saubere Längenberechnungen des verfügbaren Platzes in den Buffern gemacht werden und längenbeschränkte Schreibfunktionen für die Strings genutzt werden. Also genau das, was Stand der Technik (seit Jahrzehnten) für die Vermeidung von Buffer Overflows ist. Da einfach nur blind FUD zu verbreiten ist total peinlich.
Ralf D. schrieb: > Libraries sind irrelevant, die werden dynamisch > gelinkt und von anderer Stelle gepflegt, zählen also nicht für Risiken > bzgl. dieses Programms. Mit der Meinung bist du aber sowas von daneben und hoffentlich auch alleine.
Klaus schrieb: > Ralf D. schrieb: >> Libraries sind irrelevant, die werden dynamisch >> gelinkt und von anderer Stelle gepflegt, zählen also nicht für Risiken >> bzgl. dieses Programms. > > Mit der Meinung bist du aber sowas von daneben und hoffentlich auch > alleine. Nö, zum Glück nicht. Risiken aus Libraries betrachtet man eben bei den Libraries, nicht bei den Programmen, die sie verwenden, insbesondere bei dynamisch gelinkten Libs. Ja, natürlich verlässt sich crokscrew auf korrekte Implementierung von strncat in der benutzten C-Standard-Library, aber die gehört eben nicht zum Programm selbst sondern zur Systemumgebung und wird in dem Kontext geprüft und bewertet. Und da ist dann schon fast egal, ob man ein Programm in C oder einer anderen Sprache entwickelt, denn die Runtime der gewählten Sprache wird sich auch in den allermeisten Fällen auf der C-Library abstützen, weil kaum jemand unbedingt das Rad neu erfindet, wenn er es vermeiden kann.
Ralf D. schrieb: > Risiken aus Libraries betrachtet man eben bei den > Libraries, nicht bei den Programmen, die sie verwenden, insbesondere bei > dynamisch gelinkten Libs. Du meinst also, wenn eine kritische Sicherheitslücke auftaucht, prominentes Beispiel log4j, dann muss ich mir als Anwender einer Applikation, ja sogar als Entwickler einer Applikation keine Gedanken machen, weil es ist ja das Problem von log4j?
Klaus schrieb: > Du meinst also, wenn eine kritische Sicherheitslücke auftaucht, > prominentes Beispiel log4j, dann muss ich mir als Anwender einer > Applikation, ja sogar als Entwickler einer Applikation keine Gedanken > machen, weil es ist ja das Problem von log4j? Doch, Du musst Dir Gedanken machen, damit Du auf die Idee kommst, den ganzen Unterbau möglichst aktuell zu halten. Hat aber nichts mit dem Programm zu tun, das den Unterbau nur benutzt - das Programm selber ist ja deswegen nicht schlecht oder pauschal unsicher. Nach Deiner Logik müsste ja damit jedes Java-Programm automatisch schlecht und unsicher sein ...
:
Bearbeitet durch User
Hast Du denn mal Deinen Server abgescannt, ob da überhaupt irgendein Port für SSH empfänglich ist? nmap wäre so ein Tool
Jens G. schrieb: > Nach Deiner Logik müsste ja damit jedes Java-Programm automatisch > schlecht und unsicher sein ... Und nach deiner Logik sind Programme, die einen unsicheren Unterbau benutzen, trotzdem sicher, weil es liegt ja nicht am Programm.
Anmerkung: Was sich der eigenen Kontrolle entzieht, ist generell als unsicher zu betrachten. Und nein, ich bin nicht übermäßig Paranoid. Aber um eine Art von Beispiel zu Nennen, eine Nutzereingabe, egal wie sie erfolgt, ist immer erst als unsicher zu betrachten und zu prüfen, dann, nach ausreichender Prüfung, wobei während der Prüfung auch keine Art RCE/Escaping passieren darf, einer endgültigen Verarbeitung zu unterziehen. Das machen meine (früher Web.) Anwendungen, seit je her, daher wurde aber auch nie eine meiner Seiten geknackt! Das Prinzip ist gleich, egal wo, Usereingaben sind gegen schädliches verhalten durch geeignete Maßnahmen zu entschärfen so gut es geht, unter Berücksichtigung das man sich nicht selbst zu sehr einschränkt. Sicherheit ist ein Kompromiss.
Klaus schrieb: > Ralf D. schrieb: >> Risiken aus Libraries betrachtet man eben bei den >> Libraries, nicht bei den Programmen, die sie verwenden, insbesondere bei >> dynamisch gelinkten Libs. > > Du meinst also, wenn eine kritische Sicherheitslücke auftaucht, > prominentes Beispiel log4j, dann muss ich mir als Anwender einer > Applikation, ja sogar als Entwickler einer Applikation keine Gedanken > machen, weil es ist ja das Problem von log4j? Ich muss mir da nicht über das Programm Gedanken machen, sondern ich muss eben die Library up-to-date halten. Getrenntes Paket, getrennter Update-Weg. Ein Update der Anwendung bringt mir gar nichts, wenn ich kein Update für die Library bekomme. Heutzutage ist so etwas normalerweise dynamisch gelinkt und dadurch komplett unabhängig voneinander und somit bzgl Updates und Security getrennt zu betrachten.
Ralf D. schrieb: > Heutzutage ist so etwas normalerweise dynamisch gelinkt und dadurch > komplett unabhängig voneinander und somit bzgl Updates und Security > getrennt zu betrachten. Dann ist es für den unwissenden Anwender erst recht die Hölle - der weiß im Normalfall gar nichts von irgendwelchen Sicherheitslücken. Und bei statisch gelinkten (bzw. mit dem Installer mitgelieferten) Bibliotheken muss sich der Entwickler halt doch kümmern. Je mehr externe Abhängigkeiten, desto unübersichtlicher wird es.
Klaus schrieb: > Du meinst also, wenn eine kritische Sicherheitslücke auftaucht, > prominentes Beispiel log4j, dann muss ich mir als Anwender einer > Applikation, ja sogar als Entwickler einer Applikation keine Gedanken > machen, weil es ist ja das Problem von log4j? Muß ich dann die Applikation aktualisieren oder Log4j?
Klaus schrieb: > Dann ist es für den unwissenden Anwender erst recht die Hölle Ach wo. "apt-get update && apt-get dist-upgrade" und schon ist wieder alles aktuell.
Daniel A. schrieb: > Ach wo. "apt-get update && apt-get dist-upgrade" und schon ist wieder > alles aktuell. Böse Falle. Das ist abhängig davon was deine distribution her gibt. Nicht überall sind Patches gleich schnell eingepflegt.
:
Bearbeitet durch User
Daniel A. schrieb: > Und du glaubst, du kannst das besser und schneller? Besser und schneller, naja, nicht unbedingt immer, ab und an aber schneller als die offiziellen Pakete. Da muss ich aber auch echt "hinterher" sein, aktuell hab ich da nix. Aber es gibt Dinge da sollte man "from source" anstelle der Paketquellen wählen und für sein system selbst verantwortlich updaten, Abhängigkeiten überprüfen und eventuell auch mal Patches per Hand Einspielen. Ist ja nur mein persönlicher Anspruch, sehe ich aber bei "kritischen" Sachen wie hier einem "SSH Zugang" als angebracht an. Ach keiner hat Reverse tunneling erwähnt? Aus der Mode gekommen? So kam ich immer remote bei Leuten ohne Zugriff auf den Router zum helfen auf den PC...
L.S. schrieb: > Hast Du denn mal Deinen Server abgescannt, ob da überhaupt irgendein > Port für SSH empfänglich ist? nmap wäre so ein Tool Und was ist da raus gekommen? Ich schätze mal, dass der TE sich selbst ausgesperrt hat - SSH falsch konfiguriert - Firewall falsch konfiguriert Die IP 61.221.4.68 (sofern das die IP des VPS des TE ist) gehört einem VPS-Anbieter in Taiwan, da würde ich den vorhandenen VPS im GUI des Anbieters abschalten und einen neuen VPS anlegen. Da dauert normalerweise weniger als 5 Minuten. Und wenn da Daten drauf waren gilt der alte Spruch: kein Backup - kein Mitleid!
Stephan S. schrieb: > L.S. schrieb: >> Hast Du denn mal Deinen Server abgescannt, ob da überhaupt irgendein >> Port für SSH empfänglich ist? nmap wäre so ein Tool > > Und was ist da raus gekommen? > > Ich schätze mal, dass der TE sich selbst ausgesperrt hat > - SSH falsch konfiguriert > - Firewall falsch konfiguriert > > Die IP 61.221.4.68 (sofern das die IP des VPS des TE ist) gehört einem > VPS-Anbieter in Taiwan, da würde ich den vorhandenen VPS im GUI des > Anbieters abschalten und einen neuen VPS anlegen. Da dauert > normalerweise weniger als 5 Minuten. Und wenn da Daten drauf waren gilt > der alte Spruch: kein Backup - kein Mitleid! Nope, der Server steht in den US, die Taiwan IP ist wegen meinem VPN - von China Mainland aus sind nunmal VPN Server in Hongkong und Taiwan am schnellsten. SSH funktioniert und ich bin auch dank der ersten Antwort mittels Piping SSH via Web drauf. Zudem sehe ich im Log die ständigen Hackattempts per SSH. Ist definitiv eine neue Stufe der Blockade und wurde mir auch mittlerweile von anderen Leuten hier in China bestätigt. Ein Land, das sich selbst Remote Möglichkeiten nimmt, ganz stark...
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.