ssh-Tunnel ohne shell

[albern]

Mann kann auch openssh für win32 nutzen ..........Wenn man eine Windows-Maschine hat.

???

Der Einsatz eines ssh-Servers auf dem Ziel-Rechner, egal mit welchem Betriebssystem, deckt nur einen Teil der Möglichkeiten von ssh-Tunneln über eine als Router/DSL-Modem genutzte FreetzBox ab:

• Die im Allgemeinen ständig arbeitende FreetzBox ist erreichbar, auch wenn der Ziel-Rechner gerade ausgeschalten ist. Mit den Meldungen der Box lassen sich die Gründe für nicht zustande kommende Verbindungen aus der Ferne deutlich besser analysieren. Und, wer weiß, vielleicht arbeitet ja sogar das Wake-on-LAN?
• Tunnel über die FreetzBox können grundsätzlich erst einmal beliebig viele pro beliebig verschiedener Rechner im privaten Netz errichtet werden; alles zusammen mit der Fernwartung der Box selber über einen einzigen nach außen lauschenden Port.
• Bei der Verwendung von ssh-Tunneln kann auf die Modifikation der Ziel-Rechner weitgehend verzichtet werden. Das hilft gelegentlich doch, Verantwortungen zu trennen.
• Der Fernzugriff auf die Rechner im privaten Netz hinter der Box kann auch vom nebenbei helfenden Freundschaftsadmin im Großen und Ganzen aus der Ferne "nachjustiert" werden: Hat ein kompromittierter Benutzer mangels shell oder Rechten keine Möglichkeit, die Freetzbox zu manipulieren, kann der Admin über seinen Zugang zunächst diesen einen Benutzer unabhängig von anderen sperren und z.B. einfach den verwendeten Schlüssel ändern. Wenn man gleich beim Präparieren der Freetzbox ein halbes Dutzend nummerierter Schlüssel mit verschiedenen Passphrasen hinterlegt und die Passphrasen in zugeklebten Briefumschlägen (unter Betonung der Wichtigkeit) übergibt, reicht später eine Email mit der Nummer der ab sofort zu verwendenden Schlüsselnummer und Passphrase.

Speziell unter Windows scheint mir ein zusätzlich installierter ssh-Server alleine auch nur eingeschränkten Zugriff auf das System (nur auf die Konsole?) zu geben. Über das mitgelieferte RDP kann man aber ganz gut sowohl administrieren (grafisch und per Kommandozeile) als auch grafische Anwender-Programme bedienen.


LG

 

[hermann72pb]

sag mal, albern, hast du es öfter mit rdp über ssh-tunnel ausprobiert? Gab es bei dir nicht Probleme mit großen Paketen. Ich meine das berühmte MTU-Problem durch Verschachtelung der Protokole? Bei OpenVPN kann man das Problem in dem lösen, wenn man an den MTU-Werten etwas rumspielt. Ich hatte nach deiner Methode eine VNC-Verbindung aufgebaut, die allerdings ständig abbrach. Nachdem ich die Farbtiefe runtergeschraubt hatte, konnte ich einigermassen arbeiten. Das gleiche Problem hatte ich übrigens auch mit OpenVPN mit Standardeinstellungen so wie sie bei Freetz sind.
Vor ein Paar Jahren hatte ich OpenVPN auf einem PC-Rechner in Betrieb genommen. Damals brachte mir meine Spielerei mit MTU-Werten genau das gewünschte Ergebnis: VNC und RDP konnten nun vernünftig funktionieren.
Warum gerade VNC und RDP, kann jemand fragen. Gerade wenn die grafische Information übertragen wird, kommt es oft dazu, dass übertragene Pakete zu groß werden. Deswegen eignen sie sich gut zum Testen von MTU-Problemen.

Wie gesagt, meine Frage ist nur, ob du praktisch damit schon oft genug zu tun hattest, ohne dass die Probleme auftauchten. Andererseits, wäre es nicht schlecht, wenn einer der Experten hier uns aufklären könnte, ob beim SSH-Tunnel ähnliche Sachen mit Paketen passieren wie bei einem VPN-Tunnel.

MfG

 

[albern]

@hermann72pb
Mit RDP über ssh-Tunnel zu einem Alt-PC mit Linux als Router fern-warte ich schon seit Jahren täglich zwei Rechner (Win2003, WinXP) von meinem Schreibtischrechner (Suse) aus. Über eine FreetzBox und einen ds-gemoddeten SP900 verbinde ich mich seit etwa 2 bzw. 6 Monaten gelegentlich über das Internet per rdp mit Windows-Rechnern. Mit dem SP900 tunnele ich manchmal auch X durch ssh; meistens dient der SP aber als Port-Weiterleiter zu lokalen NX-Servern (die ihrerseits aber auch ssh-Tunnel aufbauen).
Bisher kam mir noch kein Fehler unter, der (für mich) auf Probleme mit den Paketübertragungsgrößen wies.

Die Farbtiefe reduziere ich gelegentlich auch; allerdings war das bisher immer einer zeitweise unangenehm langsamen Verbindung geschuldet. Als eingeladener Schorr-Surfer hänge ich über einen als WLAN-Client konfigurierten Router am DSL des Nachbarn. Vielleicht hat aber gerade diese Funkstrecke auch Einfluß auf das Nichtauftreten von MTU-Problemen bei mir?


LG

 

[RalfFriedl]

Ich meine das berühmte MTU-Problem durch Verschachtelung der Protokole?

Bei einen SSH-Tunnel kann es keine Probleme mit MTU geben, jedenfalls nicht durch den SSH-Tunnel selbst. Es kann zwar sein, daß die SSH-Verbindung selbst auf ein MTU-Problem stößt, aber das ist dann unabhängig von SSH und SSH-Tunnel.

Ein SSH-Tunnel arbeitet nicht auf Netzwerk-Ebene, sondern als eine Art Proxy. Man kann also nur TCP-Verbindungen weiterleiten, nicht allgemeine IP-Pakete. Der Datenaustausch für die TCP-Verbindungen läuft über die SSH-Verbindung, die selbst auch TCP verwendet. Daher können beliebige Datenmengen über diese Verbindung ausgetauscht werden.

Es ist auch nicht sichergestellt, daß die Datenblöcke gleich bleiben. Wenn zum Beispiel eine Seite in kurzer Zeit zwei Pakete mit je 1 Byte Nutzdaten schickt, kann es sein, daß diese auf der anderen Seite als ein Paket mit 2 Bytes Nutzdaten herauskommt. Umgekehrt kann es sein, daß auf der einen Seite ein Paket mit 1500 Bytes Nutzdaten kommt und auf der anderen Seite diese in zwei Paketen zu 1400 Bytes und 100 Bytes versendet werden.

Da TCP aber als Datenstrom gilt und zur Anwendungsseite nicht paketorientiert ist, sollte dies für Anwendungen keinen Unterschied machen.

 

[albern]

Eine unschöne Sache habe ich inzwischen selber gefunden:
Die Datei /etc/shadow verweist auf /var/tmp/shadow und diese ist lesbar für alle.
Darüber wird wohl kaum ein unbedarfter Benutzer zufällig etwas fehlkonfigurieren. Mit einem gekaperten Account auch eines unprivilegierten Benutzers kann ein Angreifer so aber unter Umständen relativ leicht das root-Passwort erlangen.

Meine Frage, ob ich einfach die Dateirechte für /var/tmp/shadow ändern kann (z.B. auf 640 wie für /etc/shadow im Suse), möchte ich mir nicht durch Ausprobieren an der mir nur noch über das Internet zugänglichen Box beantworten.
Kann mir jemand bei der Beantwortung helfen?


LG

 

[kriegaex]

/var/tmp/shadow hat die Rechte 600 in Freetz, sofern kein anderer Prozeß das ändert. Davon abgesehen, ist die Fritz!Box ein Router und kein Multi-User-System. Zwar habe ich eine neue Benutzerverwaltung eingebaut, d.h. aber noch lange nicht, daß Du es mit einem Hochsicherheits-Linux zu tun hast.

 

[albern]

Bei mir hat /var/tmp/shadow die Dateirechte 755!?
Welche Prozesse würden denn normalerweise eine Änderung dieser Rechte vornehmen müssen?

Zum verwendeten System:
FRITZ!Box 7050
freetz-devel 1926 +busybox -assistant -help +enum +signed +avm-firewall-2.0.3c +dropbear-0.50 +haserl-0.9.21 +modcgi-0.2 +syslogd-cgi-0.2.3 +virtualip-cgi-0.4.2 +wol-cgi-0.6

 

[RalfFriedl]

775 ist erst recht seltsam. Warum sollte man Rechte zum Ausführen auf die Datei setzen?

 

[albern]

Ja, jetzt, wo Du darauf hinweist ... Seltsam sind auch manch andere Dateirechte auf dieser Box:

/var/mod/root # ls -la /var/tmp/
drwxr-xr-x    4 root     root            0 Mar 14 21:16 .
drwxr-xr-x    9 root     root            0 Jan  1  2000 ..
drwxr-xr-x    2 root     root            0 Jan  1  2000 csem
-rw-r--r--    1 root     root            0 Jan  1  2000 ethers
-rwxr-xr-x    1 root     root            0 Feb 27 10:33 exports
drwxr-xr-x    9 root     root            0 Jan  1  2000 flash
-rwxr-xr-x    1 root     root          131 Mar 14 00:47 group
-rwxr-xr-x    1 root     root           46 Mar 14 00:12 gshadow
-rw-r--r--    1 root     root           43 Jan  1  2000 hosts
srwxr-xr-x    1 root     root            0 Jan  1  2000 me_ctlmgr.ctl
srwxr-xr-x    1 root     root            0 Jan  1  2000 me_dsld.ctl
srwxr-xr-x    1 root     root            0 Jan  1  2000 me_logic.ctl
srwxr-xr-x    1 root     root            0 Jan  1  2000 me_multid.ctl
srwxr-xr-x    1 root     root            0 Jan  1  2000 me_voipd.ctl
-rwxr-xr-x    1 root     root            0 Feb 27 10:33 onlinechanged
-rwxr-xr-x    1 root     root          315 Mar 27 21:34 passwd
-rwxr-xr-x    1 root     root           50 Jan  1  2000 resolv.conf
-rwxr-xr-x    1 root     root          206 Mar 14 00:12 shadow

 

[RalfFriedl]

Es ist nicht weiter schlimm, es ist nur ungewöhnlich.