RDP-Verbindung mit mRemoteNG und PuTTY über SSH

mt5rdp

Newbie
Registriert
Mai 2024
Beiträge
4
Hallo.

Ich brauche Hilfe bei der Konfiguration mit der App mRemoteNG über SSH.

Bei einer passwortbasierten SSH-Verbindung funktionierte es problemlos.
Folgendes habe ich dafür gemacht:

In PuTTY unter Connection\SSH\Tunnels:

Source Port: 5000
Destination: Server-IP:3389
(X) Local
(X) Auto
[Add] Schaltknopf betätigt
Unter "Session" Verbindung gespeichert und die Verbindung gestartet.

In der App mRemoteNG habe ich eine neue Verbindung erstellt.
Als Hostname/IP habe ich 127.0.0.1 gewählt.
Als Protokoll RDP genommen.
Als Port 5000 genommen.

Jetzt möchte ich auf schlüsselbasierte SSH-Verbindung umstellen. Die schlüsselbasierte SSH-Verbindung funktioniert zwar über PuTTY, aber dafür die RDP-Verbindung über mRemoteNG nicht mehr.

Hat jemand eine Idee wie man mRemoteNG dafür konfigurieren muss?
Muss man vielleicht irgendwie das Tool Pageant in mRemoteNG hinzufügen?
 
mt5rdp schrieb:
Die schlüsselbasierte SSH-Verbindung funktioniert zwar über PuTTY, aber dafür die RDP-Verbindung über mRemoteNG nicht mehr.
Was heißt das genau? Was funktioniert nicht mehr? Hast du mehrere dieser SSH-Sitzungen mit dem Tunnel parallel offen? Da verhaspelt sich Putty gerne mal, es darf halt nur einen geben, der auf dem Port lauscht ;)

Anstatt den Schlüssel hart in Putty für die Sitzung zu hinterlegen, kannst du auch einen keyagent benutzen, klar. Das kann man auch gut mit einem Passwortmanager koppeln. Ich mache das mit keepassxc. Sobald ich bestimmte Passwortdatenbanken entsperre, werden einige Schlüssel automatisch in den keyagent geladen und wieder entfernt, wenn ich die Datenbank sperre.
 
Ich wüsste nicht, was es für einen Unterschied für die RDP-Verbindung machen soll, ob nun Passwort oder Schlüssel für den SSH-Tunnel genutzt wird.
Hast du schomal mit mstsc gegengetestet, ob es mit beiden Varianten funktioniert?
Und auch mal im Resource Manager (oder mit netstat) schauen, ob Port 5000 offen ist.
KillerCow schrieb:
Hast du mehrere dieser SSH-Sitzungen mit dem Tunnel parallel offen?
Das wäre auch meine einzige Erklärung...
 
KillerCow schrieb:
Was heißt das genau? Was funktioniert nicht mehr?
Eine Passwortbasierte SSH-Verbindung mit mRemoteNG und PuTTY über Port funktioniert bei mir problemlos.
Nur eine schlüsselbasierte SSH-Verbindung nicht.

KillerCow schrieb:
Hast du mehrere dieser SSH-Sitzungen mit dem Tunnel parallel offen?

Nein. Ich habe nur eine schlüsselbasierte SSH-Verbindung mit PuTTY parallel zu mRemoteNG offen.
Die Frage ist nur, wie man jetzt mRemoteNG konfigurieren muss.

Client ist Windows 10.
Host ist Windows Server 2022.
Ergänzung ()

kartoffelpü schrieb:
Ich wüsste nicht, was es für einen Unterschied für die RDP-Verbindung machen soll, ob nun Passwort oder Schlüssel für den SSH-Tunnel genutzt wird.
Macht eine Verbindung mit Schlüssel eine Brute-Force-Attacke nicht sinnlos?
Ergänzung ()

Ich hoffe ich habe netstat richtig benutzt:

C:\Windows\system32>netstat -ano | find "5000"
TCP 127.0.0.1:5000 0.0.0.0:0 ABHÖREN 16200
TCP [::1]:5000 [::]:0 ABHÖREN 16200
UDP 0.0.0.0:50001 : 5500
Ergänzung ()

Von mRemoteNG bekomme ich die Fehlermeldung: RDP-Verbindung getrennt! 4 Ein interner Fehler ist aufgetreten.
 
Zuletzt bearbeitet:
mt5rdp schrieb:
Macht eine Verbindung mit Schlüssel eine Brute-Force-Attacke nicht sinnlos?
Gegenfrage: Was hat das mit dem Traffic, der durch den Tunnel geht, zu tun?
 
Ich bin kein Experte. Deshalb frage ich hier im Forum. Ich bin bestimmt nicht der einzige, der solch eine Verbindung nutzt.
 
Funktioniert es denn, wenn du manuell mit Putty die SSH-Sitzung mit Schlüssel und Portweiterleitung startest und dann eine RDP Sitzung startest? Also ohne mRemoteNG.
So wie ich das verstehe, nutzt mRemoteNG auch nur eine fertig konfiguriertes Puttysitzung. Sofern das auf dem Weg klappt, muss es auch mit mRemoteNG klappen, ansonsten macht das Tool irgendwas komisches.

Denn wie @kartoffelpü schreibt, ist es der RDP-Verbindung sowas von egal, ob die SSH-Sitzung dich an deinen getragenen Socken oder an Hand deiner Astralrückstände erkannt hat. Kann höchstens sein, dass die Gegenseite SSH-Features anhand der Authentifizierungsart ein-/ausschaltet... wenn das denn überhaupt funktioniert. Und dann wäre es sinnvoller, Portweiterleitungen zu verbieten, wenn man sich nicht mit Schlüssel ausgewiesen hat.

Also, mit Putty die Verbindung aufmachen und den Tunnel konfigurieren, falls nicht schon getan. Dann mit netstat schauen, ob lokal auf dem Port gelauscht wird. Falls ja, RDP testen. Falls nein, klemmt es da bereits.
 
KillerCow schrieb:
Funktioniert es denn, wenn du manuell mit Putty die SSH-Sitzung mit Schlüssel und Portweiterleitung startest und dann eine RDP Sitzung startest? Also ohne mRemoteNG
Ja das funktioniert.

Soviel ich weiß, verwendet die Windows RDP App eine Verschlüsselung von maximal 128bit.

Bei mRemoteNG wären das 256bit, wenn ich mich nicht täusche.

Der Hauptgrund, warum ich mRemoteNG verwenden möchte, ist, dass man die Auflösung ändern kann, ohne die RDP-Sitzung zu beenden.
Wenn man dann noch ein Schlüsselpaar mit einer stärkeren Verschlüsselung verwenden könnte, wäre es noch besser.
Ergänzung ()

Edit: Entschuldigung, ich habe das missverstanden.

Mit Passwort ja, aber mit Schlüssel muss ich noch testen.
Ergänzung ()

Edit: Wenn ich bei der Windows RDP App im Feld Computer 127.0.0.1:5000 eintrage und versuche zu verbinden, dann erscheint die Fehlermeldung: Ein interner Fehler ist aufgetreten.
 
Zuletzt bearbeitet:
Es ist echt schwierig, dir zu helfen, weil du leider nie vollständige Informationen lieferst und zumindest ich mir nicht sicher bin, was du jetzt genau wie ausprobiert hast.

Szenario A: mit putty und via Passwort eine Verbindung aufbauen, inklusive Tunnel via lokalem Port 5000, dann mit RDP App die Verbindung testen. Das klappt, soweit ich verstanden habe, aber bitte nochmal konkret bestätigen.

Szenario B: mit putty und via Schlüssel eine Verbindung aufbauen, inklusive Tunnel via lokalem Port 5000 (die andere Puttysitzung ist vorher beendet und das Puttyfenster ist geschlossen! Im Zweifel auch erst prüfen, dass niemand mehr auf Port 5000 lauscht), dann mit RDP App die Verbindung testen. Hier kommt es zu einem Problem?

Bei beiden Szenarien, falls es nicht klappt, via netstat schauen, ob Putty auch wirklich auf Port 5000 lauscht.

Benutzt du für die beiden Szenarion diesselbe Puttysession und änderst nur die Einstellung für mit Schlüssel oder nicht? Oder hast du zwei Sessions? Falls letzteres, wirklich nochmal alle sonstigen Einstellungen abgleichen!
 
  • Gefällt mir
Reaktionen: Der Lord und kartoffelpü
Zurück
Oben