OpenSSH sftp und ssh login auf Server

[novalix]

In der Standardkonfiguration auf einem aktuellen Debian-System kann man sich als user root nicht per Passwortauthentifizierung am sshd einloggen nur mit key.
Da Du weiter oben davon schrubst, dass eine Anmeldung als root nicht funktioniert hat, nachdem Du aus welchen Gründen auch immer das System neu aufgesetzt hast, könnte hier der Hase im Piment liegen.

Der Tipp sich mit hoher verbosity zu verbinden wurde ja schon gegeben. Also:

Code: Alles auswählen

ssh -vvv $user@$machine

[mgolbs]

Hallo,

vielen Dank!

Applicative protocol multiplexer

Das habe ich nun noch nicht verstanden.

sslh accepts connections in HTTP, HTTPS, SSH, OpenVPN, tinc, XMPP, or any other protocol that can be tested using a regular expression, on the same port. This makes it possible to connect to any of these servers on port 443 while still serving HTTPS on that port.

Eine Alternative zu Ajaxterm?

In der Standardkonfiguration auf einem aktuellen Debian-System kann man sich als user root nicht per Passwortauthentifizierung am sshd einloggen nur mit key.

Ist eine VM eines Serveranbieters. Nach deren Deb9 Installation ging root Anmeldung per ssh erst einmal problemlos, bis zum reboot. Bin da was entfernte VM Server angeht Neuling und habe diese zum Lernen, probieren gemietet.



Gruß und Dank Markus

[DeletedUserReAsG]

OT:

Bin da was entfernte VM Server angeht Neuling und habe diese zum Lernen, probieren gemietet.

Warum muss es ’ne entfernte Maschine sein? Lokal lernt man genausoviel, wenn nicht noch mehr. Und billiger ist’s auch noch.

[mgolbs]

Hallo lernen ist Stufe 1, Grund für Miete sind geplante Anwendungen. Habe zu Hause einige Debian Maschinen laufen. SSH Zugriff ist halt Kernkomponente und wenn Tests positiv dann ist man damit produktiv im Einsatz ohne alles noch mal konfigurieren zu müssen
Gruß Markus

[DeletedUserReAsG]

Naja … (nicht nur) ich bin immer recht skeptisch, wenn Grundlagenwissen fehlt, aber Server gefahren werden. Man kann Glück haben, dann geht’s gut, man kann aber auch Pech haben, dann macht man sich und/oder andere ziemlich unglücklich.

Sorry für OT.

[uname]

Hallo lernen ist Stufe 1, Grund für Miete sind geplante Anwendungen. Habe zu Hause einige Debian Maschinen laufen

Dann installiere auf einer deiner Maschinen zuhause einen SSL-Webserver, einen SSH-Server und versuche beides über Port 443 (sslh) zu erreichen. Vor Jahren habe ich das mal ausprobiert. Musst mal nach Anleitungen suchen.

Unterwegs hast du damit jedoch das Problem, dass du einen echten SSH-Client (Windows z. B. putty.exe) benötigst und evtl. aus einen Firmennetzwerk der Zugriff über einen Webproxy umgeleitet wird und somit trotzdem nicht funktioniert.
Falls du webbasiert auf den SSH-Server zugreifen willst oder musst, bleibt wohl nur Ajaxterm oder shellinabox. Ob man Shellinabox mit sslh nutzen kann, weiß ich nicht.

[dirk11]

Applicative protocol multiplexer

Das habe ich nun noch nicht verstanden.

sslh accepts connections in HTTP, HTTPS, SSH, OpenVPN, tinc, XMPP, or any other protocol that can be tested using a regular expression, on the same port. This makes it possible to connect to any of these servers on port 443 while still serving HTTPS on that port.

Eine Alternative zu Ajaxterm?

Nein. SSLH hängt sich auf Port 443 und lauscht dort auf eingehende Pakete. Anhand von Klartextdaten im Paket-Header entscheidet sslh, ob es sich um ssh, https oder was entsprechend anderes handelt und leitet die Pakete an den entsprechenden Dienst weiter. Du musst dafür also einen https-Server auf einem anderen Port als 443 laufen lassen, weil auf 443 ja jetzt sslh läuft. Ein hilfreiches tool, welches bei mir seit Jahren seinen Dienst tut, es gibt z.B. immer noch Hotel-WLANse, die idiotischerweise Port 22 sperren. Da kann man sich mit ssh over 443 gut behelfen.
So wurde es mir jedenfalls mal erklärt, falls jemand eine bessere Erklärung hat, immer her damit!

SSH Zugriff ist halt Kernkomponente und wenn Tests positiv dann ist man damit produktiv im Einsatz ohne alles noch mal konfigurieren zu müssen

Ja, und wenn man keine Ahnung hat, dann legt man sich auf die Fresse und weiss noch nichtmal, warum! Sorry, aber Deine Überlegung funktioniert nicht. Hättest Du das lokal ausprobiert, hätteste Dich an die Kiste, welche Du per ssh erreichen willst, aber nicht kannst, herangesetzt und hättest z.B. im Log sofort erkennen können, warum es hakt. So hast Du den Windoof-Weg gewählt und weißt nicht, was wirklich passiert ist. Was willst Du daraus lernen? Wie man neu installiert?

und evtl. aus einen Firmennetzwerk der Zugriff über einen Webproxy umgeleitet wird und somit trotzdem nicht funktioniert.

Ein Zwangsproxy für Port 443/https? Also quasi Firmen-Man-in-the-middle? Wer macht denn sowas? Das wäre dann mal eine Aufgabe für den Firmen-Datenschutzbeauftragten, denn wenn privates Surfen überhaupt in so einer Firma erlaubt ist, könnten auf die Weise z.B. Bankdaten ausgespäht werden. Geht mal gar nicht.
Ich habe sowas (Zwangsproxy auf 443 und somit MIM) noch nicht erlebt, aber das wäre dann ja der perfekte Indikator dafür, ob ein Netz vertrauenswürdig ist oder nicht.

[mgolbs]

Hallo,

vielen Dank für die Infos. Das mit dem Neuaufsetzen stört mich nicht, jedenfalls zum jetzigen Zeitpunkt auf dem reinen Testsystem. Erfahrung ist halt die Summe der Misserfolge. Werde beim nächsten Versuch nun einige anders machen können. Wenn es sofort geklappt hätte, wären mir Eure wichtigen Informationen und Hinweise alle entgangen. Das wäre sehr schade.

Vielen Dank und Gruß Markus

[dirk11]

Erfahrung ist halt die Summe der Misserfolge.

Nur dass Du hieraus nichts gelernt hast, weil Du nicht weißt, ob es wirklich so ist, wie hier vermutet wird.

[uname]

Ein Zwangsproxy für Port 443/https? Also quasi Firmen-Man-in-the-middle? Wer macht denn sowas?

Nennt sich z. B. squid. Und selbst wenn er nicht cacht oder die Daten analysiert kann er dafür nützlich sein die Benutzer zu verwalten und HTTP(S) über Port 80/443 einzufordern. Aber natürlich kann man z. B. mit connect-proxy darüber auch SSH tunneln.

[dirk11]

Squid ist mir durchaus bekannt. Im richtigen Leben ist mir noch kein LAN mit Proxy untergekommen, in welchem ich via 443 keine Verbindung nach Hause mit ssh aufbauen konnte. Connect-proxy muss ich mir wohl erstmal anschauen - was macht das?

[uname]

Connect-proxy muss ich mir wohl erstmal anschauen - was macht da

Es ermöglicht dem SSH-Client die SSH-Sitzung über HTTP(S) zu tunneln. Falls der Webproxy Port 22 blockiert sollte der SSH-Server auf Port 443 (evtl. unter Verwendung von sslh laufen)

putty.exe hat das im übrigen direkt eingebaut. Man muss nur HTTP auswählen und die Proxy-Zugangsdaten eingeben.
Bei Debian nutzt man z. B. connect-proxy und konfiguriert es in ~/.ssh/config .

[MSfree]

Bei Debian nutzt man z. B. connect-proxy

Oder corkscrew

[dirk11]

Connect-proxy muss ich mir wohl erstmal anschauen - was macht da

Es ermöglicht dem SSH-Client die SSH-Sitzung über HTTP(S) zu tunneln. Falls der Webproxy Port 22 blockiert sollte der SSH-Server auf Port 443 (evtl. unter Verwendung von sslh laufen)

putty.exe hat das im übrigen direkt eingebaut. Man muss nur HTTP auswählen und die Proxy-Zugangsdaten eingeben.
Bei Debian nutzt man z. B. connect-proxy und konfiguriert es in ~/.ssh/config .

Aha? Ich dachte immer, der ssh kann das von Haus aus? Ich habe das bisher jedenfalls immer ohne connect-Proxy geschafft, wenn ich mit -p443 "nach Hause telefoniert" habe.

[uname]

Aha? Ich dachte immer, der ssh kann das von Haus aus? Ich habe das bisher jedenfalls immer ohne connect-Proxy geschafft, wenn ich mit -p443 "nach Hause telefoniert" habe.

Das mit -p 443 funktioniert dann, wenn du auf der Strecke zwischen Client und Server direkt (Client -> SSH-Server) kommunizierst. Bei den connect-Proxy brauchst du dann, wenn du mit einen HTTP-Proxy sprichst (Client -> Proxy -> SSH-Server). Daher hast du dort als zusätzliche Parameter einen weiteren Socket (Proxy-Server:Port) sowie unter Umständen sogar weitere Zugangsdaten (Anmeldung zum Proxy).

[dirk11]

Ok, verstehe. Wie ist das denn mit diesem connect-proxy? Das installiere ich, und dann ist das "transparent", sprich ob ein Proxy dazwischen ist oder nicht, ist egal? connect-proxy wird automatisch genutzt? Oder muss ich dann dahingehend jedesmal eingreifen, daß ich das extra aufrufen muss, wenn ich feststelle, dass es ohne nicht geht?

[uname]

connect-proxy wird automatisch genutzt?

In ~/.ssh/config konfigurierst du den Eintrag für spezielle oder alle Hosts. Wenn du dann deinen /usr/bin/ssh verwendest wird die config-Datei gelesen und connect-proxy angewendet oder eben nicht.

Ein paar Beispiele, die aber netcat mit dern Optionen -X und -x verwenden. netcat oder auch corkscrew habe ich noch nicht verwendet.
https://stackoverflow.com/questions/191 ... gh-a-proxy

Ich habe das ganze seit mehr als 10 Jahren nicht genutzt. Ich weiß nicht wie gut oder schlecht es mit aktuellen Proxy-Systemen klar kommt.

[dirk11]

Ok. Viel zu umständlich. Für die 1x alle zwei Jahre, die ich das vielleicht brauchen könnte oder würde, kann ich dann genausogut eine Verbindung per Mobilfunk machen.
Zumal ich zumindest das nur in Hotels o.ä. benötigen würde, wenn die cachen würden. Dann käme ich aber nicht dran, um das zu konfigurieren. Henne-Ei-Problem, dysfunktionale Idee für "Datennomaden". Nur tauglich, wenn man regelmäßig immer die gleichen Verbindungen nutzt. Aber gut zu wissen, dass es sowas gibt.

[uname]

Zumal ich zumindest das nur in Hotels o.ä. benötigen würde, wenn die cachen würden.

Ich denke Webproxys lohnen sich nicht mehr bzgl. Caching. Bei TLS/SSL kann man nicht cachen und das Internet ist sowieso schnell genug.

Wenn ich ein Hotel hätte und wollte irgendwie Bandbreite sparen, würde ich

a.) die Bandbreite gerechter verteilen
b.) evtl. Zielports auf die gängigen Ports wie 80, 443 usw. einschränken
... dann kommt lange nichts bzw. gar nichts mehr ...
c.) HTTPS über 443 erzwingen

Solange maximal b.) umgesetzt wird kannst du z. B. mit sslh deinen SSH-Server auf Port 443 betreiben.
Damit kannst du dann deinen Server administrieren oder dir ein VPN (HTTP-Proxy, SOCKS-Proxy, echtes VPN, ...) bis ins Hotelzimmer durchtunneln.

[dirk11]

Ich weiß, das mache ich schon seit Jahren - schrieb ich ja weiter vorn.