ssh-Tunnel ohne shell

[albern]

Verschiedene Benutzer sollen ssh-Tunnel über eine FreetzBox erstellen, aber möglichst nicht ohne weiteres Kommandos auf der shell ausführen können.
Mein Versuch, dafür unprivilegierte accounts einzusetzen, scheiterte aber immer am dropbear (trotz Löschung des 100-root-login-only.patch, so wie hier <http://www.ip-phone-forum.de/showpost.php?p=912566&postcount=5> beschrieben).

Eine von-hinten-durch-die-Brust-Lösung könnte das Anlegen weiterer accounts (adduser ...), deren ver-root-ung (in /etc/passwd : uid, gui = 0) und die Angabe eines eigenen Skriptes als auszuführende shell (in /etc/passwd : z.B. Verweis auf /tmp/flash/nologin) sein. Damit dropbear nicht mehr brummt, musste erst noch eine /etc/shells, die den entsprechenden Eintrag auch enthält, in die verwendete firmware gepackt und diese dann neu geladen werden (Ich war zu blöd, stattdessen dem dropbear diese Abfrage abzugewöhnen). Das Skript selber enthält bei mir im wesentlichen erst einmal nur den Befehl read.

Jeder so angelegte Benutzer kann sich mit seinem individuellen Passwort am ssh-Server der FreetzBox anmelden und die gewünschten ssh-Tunnels erstellen. Mit der erfolgreichen Anmeldung wird das Skript gestartet. Im Fall des nologin-Skriptes mit read führt das zu einer Konsole, die auf nichts anderes als ein ENTER reagiert, um danach die Verbindung sofort wieder abzubauen. Das scheint auch mit passwortlosen Verbindungen per public key zu funktionieren.

Gegebenenfalls könnte das Skript auch noch durch eine weniger asketische Version ersetzt werden; z.B. mit Verbindungstests im lokalen Netz per ping und einer fallweisen Erweckung einzelner Rechner per ether-wake.

Bisher konnte ich allerdings mangels eigenem DSL-Anschluss die FreetzBox ausschliesslich lokal testen.
Darum und weil ich nicht wirklich Ahnung von den Gefahren und Wagnissen der EDV habe, bitte ich hiermit das geneigte Publikum um Hinweise auf Schwachstellen und Unsinnigkeiten im beschriebenen Vorgehen.
Vor allem Anmerkungen bezüglich der Sicherheit interessieren mich; andere Probleme wie z.B. das port forwarding aus dem Internet auf die FreetzBox selber wurden ja an verschiedenen Stellen im Forums bereits besprochen.

Dankeschön!


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

 

[bofh]

Vorsicht! wenn das als script unter root rechten leuft (nix anders ist ja UID=0),
genuegt Irgenwo ein fehler (im dropbear, in der shell, im script oder sonst wo),
und die leute haben root rechte, so solte das NICHT passiren koennen!

deswegen macht man so was IMMER mit einer unpreviligirten UID.
(deswegen muss das IMOH im dropbear-patch auf jedenfall gefix werden, das man auch wenn man will auch mit anderen usern als root sich anmelden kann!)
@albern hast du deswegen schon nen Ticket im TACK aufgemacht?

gruss
bofh

 

[albern]

[...] deswegen muss das IMOH im dropbear-patch auf jedenfall gefix werden, das man [...] auch mit anderen usern als root sich anmelden kann [...]
@albern hast du deswegen schon nen Ticket im TACK aufgemacht?

Nein, ich habe kein Ticket aufgemacht. Ich überblicke einfach nicht, ob es sich bei dem Problem tatsächlich um eine Sache des ssh-Servers oder einfach um eine grundsätzliche Limitation der ihn beherbergenden FritzBox mit ihrem Mini-OS handelt. Ich glaube, an verschiedenen Stellen hier im Forum Hinweise auf Letzteres gelesen zu haben.

Wäre denn, unabhängig vom dropbear, ein Nicht-Root auf der FritzBox überhaupt wirklich in seinen Rechten ausreichend beschränkbar?

Deine Bedenken bezüglich der root-Rechte für lediglich durchtunnelnde Anwender teile ich leider ...

LG

 

[hermann72pb]

Kannst du bitte es etwas motivieren, wofür das ganze gut ist? Z.B.:
1. Du willst, dass diese durchtunnelte Verbindungen auf der Box landen und nicht hiter der Box im Heimnetz?
2. Was ist der Vorteil gegenüber stunnel und matrixtunnel? Schlanker? Hast du es verglichen? Ich glaube, zumindest stunnel ist auch nicht so groß.
3. Wenn du nur tunneln willst, kann man dem User denn die Shell nicht irgendwie ganz verbieten?

Wenn das Ganze funkzionieren sollte, könnte man so eine GUI mit Forwardregeln daraus bauen als einen kleinen Ersatz für OpenVPN. Denn, wenn ich es richtig überblicke, kann man bei dropbear die tunnels auch serverseitig definieren.

MfG

 

[albern]

1. Du willst, dass diese durchtunnelte Verbindungen auf der Box landen und nicht hiter der Box im Heimnetz?

Normaltags nutze ich ssh und dessen Tunneloptionen (als Nur-Anwender) zum Zugriff auf Linux-Rechner sowieso schon häufig. Das kennt der Bauer nun also.
Und weil ich den ssh-Zugang zur FreetzBox zum Fernwarten inzwischen sehr schätzen gelernt habe, wollte ich eben auch gleich die Möglichkeit für 'individuelle' Tunnel zu einzelnen Rechnern aus dem privaten Netz hinter der Box nutzen.

2. Was ist der Vorteil gegenüber stunnel und matrixtunnel? Schlanker? Hast du es verglichen? [...]

Wenn dropbear auf der Box sein soll (s.o.), nimmt jedes weitere noch so schlanke Paket mehr Platz weg als keines. Das spielt besonders bei der einen eingesetzten FritzBox7050 eine Rolle.
Ein weiterer Grund, weshalb ich den ssh-Zugang so mag, wäre auch die grundsätzliche Möglichkeit, dank porta-putty u.ä. den anderen Benutzern den Zugang mit kleinen unblutigen Skripten auf einer CD *ohne* Veränderung ihrer Rechner zu ermöglichen.
Außerdem - der Bauer frißt eben manches nicht so gern ...

3. Wenn du nur tunneln willst, kann man dem User denn die Shell nicht irgendwie ganz verbieten?

Das habe ich nicht hinbekommen. Wenn ich einem User in '/etc/passwd' nichts anstelle dem Standard '/bin/sh' zuordnete, konnte ich keine stabilen Tunnel aufbauen. Die entsprechenden Log-Einträge zeigten (in meiner Erinnerung) einen Verbindungsabbau sofort nach dem zunächst erfolgreichen Verbindungsaufbau.

Das im ersten Posting beschriebene Skript enthält jetzt vor dem 'read' noch ein

echo 'Zum Beenden der Verbindung die ENTER-Taste druecken!'

Eine derartige Anzeige auf dem Rechner des sich anmeldenden Benutzers hilft diesem nach meiner Erfahrung, die einzelnen Vorgänge (Tunnelbau sowie z.B. rdp-Sitzung) besser nachzuvollziehen und mich im Zweifelsfall auf Nachfrage auch mit hilfreicheren Details zum 'Geht-nicht' zu erfreuen.

Wenn das Ganze funkzionieren sollte, könnte man so eine GUI mit Forwardregeln daraus bauen als einen kleinen Ersatz für OpenVPN. Denn, wenn ich es richtig überblicke, kann man bei dropbear die tunnels auch serverseitig definieren.

Du meinst, eine erfolgreich angemeldeter User bekommt gleich 'seinen' entsprechenden Tunnel von der Box übergeholfen? Das wäre aus Sicht der Nur-Tunnelbauer mit Sicherheit eine Erleichterung ...

Falls der ssh-Zugang für Unterprivilegierte mal richtig klappt, ist das schon eine feine Anregung für neue Spielereien!


Herzlichen Dank einstweilen an Euch!
LG

 

[hermann72pb]

Kannst du bitte grob erläutern, wie du die Verbindungen hinter die Box routest? Denn so wie ich es kenne, bekommst du erstmal die Verbindung auf die Box intern. Machst du dann die Weiterleitung von der Box auf einen weiteren Rechner über ar7.cfg, oder habe ich da was übersehen? Hast du in putty schon versucht was anderes anstelle von "localhost" einzutragen? Das wäre nämlich auch interessant, vor allem wenn man mehrere Putty-Sitzungen auf einmal hat. Wenn man bei allen "localhost" stehen hat, gilt immer die letzte.

MfG

 

[albern]

Kannst du bitte grob erläutern, wie du die Verbindungen hinter die Box routest?

linux:~> ssh -p 44444 -i /keys/key_with_passphrase -L 3389:192.168.1.10:3389 [email protected]

oder

C:\Dokumente und Einstellungen\Benutzer\> putty2.exe -P 44444 -i C:\Dokumente und Einstellungen\keys\key_with_passphrase -L 127.0.0.1:3390:192.168.1.10:3389 [email protected]

192.168.1.10 ist in den Beispielen die IP des Windows-Rechners im Netz hinter der Box, auf den der Benutzer zugreifen möchte.
Das Linux-Beispiel funktioniert ganz ähnlich auch auf der Konsole von MacOS X.
Der Aufruf von putty2.exe zeigt auf eine portable Version von putty, die nichts in die Windows-Registry schreibt.

Die Angabe von 127.0.0.1 zur Option -L im zweiten Beispiel ist meiner Meinung nach Standard und kann weggelassen werden. Man könnte da wohl aber auch 127.0.0.2 angeben und im zweiten Schritt unter Windows mstsc.exe (neuere Version) für eine zweite RDP-Verbindung über diese Adresse nutzen.
Unter Linux tunnele ich immer die rdp-Ports verschiedener Rechner an verschiedene lokale Ports und übergebe die lokalen Ports entsprechend an mehrere Instanzen des RDP-Clients.

LG

 

[hermann72pb]

...wieder was dazu gelernt. Jetzt brauche ich gar nicht mehr OpenVPN. Denn für die Zwecke, wo ich es bis jetzt eingesetzt hatte, würde es zu 95% reichen. und die restlichen 5% kann ich wohl verkraften.

MfG

 

[albern]

Im ersten Posting hatte ich darüber geklagt, dass der ssh-Server dropbear nicht mit unprivilegierten Benutzern zusammen arbeiten möchte. Nun habe ich wieder etwas gespielt und kann ein kleines bisschen genauer werden.

Ich habe
1. den '100-root-login-only.patch' für den dropbear gelöscht

2. auf der laufenden FreetzBox einen Benutzer erstellt (erst ohne Passwort mit adduser -D -H user, später ein Passwort mit passwd user als root hinzugefügt)

3. mich erfolglos mit Schlüssel angemeldet als user: Permission denied (publickey). [BoxLog: exit before auth (user 'user', 0 fails): Exited normally]

4. mich erfolglos mit Passwort angemeldet als user: Freez-Banner der Box gesehen und sofort Connection to fritzbox.dyndns.com closed. [BoxLog: password auth succeeded for 'user' from home.dyndns.com und exit after auth (user): Exited normally]

5. auf der Konsole der laufenden FreetzBox mit login user eine erfolgreiche lokale Anmeldung machen können


Der dropbear scheint also gar nicht unbedingt der Schuldige zu sein.
Die Anmeldung über private/öffentliche Schlüssel wäre zwar ziemlich wichtig, aber bevor ich mich mit Dateiberechtigungen und der Freetz'schen Verzeichnis-Struktur beschäftige, wollte ich erstmal eine Anmeldung eines unprivilegierten Benutzers mit Passwort meistern.

Was passiert also bei 4. nach der (scheinbar) erfolgreichen Anmeldung, das die sofortige Abmeldung nach sich zieht? Kann mir jemand auf die Sprünge helfen?

LG

 

[RalfFriedl]

Nimm mal strace mit in die Firmware auf und finde es heraus.

 

[albern]

Leider habe ich inzwischen keine Box mehr in den Händen und auf denen, die ich noch im Netz erreiche, werden auf jeden Fall die Telefonfunktionen dauernd gebraucht. Das Aufspielen neuer Firmware würde ich daher gerne vermeiden.

Ist der Versuch sinnvoll, Freetz in einem AR7-Emulator zu testen?

 

[hermann72pb]

Wenn du wieder eine Box zum Experimentieren hast, nimm erstmal

make/dropbear/patches/250-login-limits.patch

raus, bevor du Image baust und weiter forschst. Ich hatte da Einiges etwas konservativer gemacht, sodass es evtl. damit zusammen hängen können. Für deine Versuche würde es erstmal reichen ohne diesen DoS Schutz. Und wenn es wirklich damit zusammen hängen sollte, schrauben wir entsprechende Parameter wieder hoch.

Sonst schau dir options.h von dropbear (mein patch fummelt gerade mit den Parametern dort). Vielleicht findest du da auch noch was passendes für deine Belange.

Mit Emulator würde ich es nicht angehen. Zu kompliziert. Ersteigere dir doch eine 7050 zum Spielen bei Ebay. Geht deutlich einfacher.

MfG

 

[albern]

@hermann72pb
Dein Patch scheint nichts mit den geschilderten Problemen zu tun zu haben. Diese bestehen weiter, auch wenn die im Patch enthaltenen Begrenzungen von Anmeldeversuchen noch nicht ausgeschöpft sind.

Danke für's Mitgrübeln!

 

[hermann72pb]

es ist gut zu hören. Behalte es aber bitte im Auge. Als ich die Anmeldeversuche wegen DoS-Begrenzung reduziert hatte, wurden hier im Forum einige Bedenken diesbezüglich geäußert. Vor allem wenn man mit Zertifikaten oder Keys anstatt Passwörter arbeitet. Ich hatte bis jetzt nur Passwörter benutzt und konnte es daher nicht testen.

MfG

 

[olistudent]

Ich kann dein Problem so nicht nachvollziehen:

login as: ftpuser
Server refused our key
[email protected]'s password:
   __  _   __  __ ___ __
  |__ |_) |__ |__  |   /
  |   |\  |__ |__  |  /_
   The fun has just begun...
 
BusyBox v1.9.1 (2008-02-20 21:46:59 CET) built-in shell (ash)
Enter 'help' for a list of built-in commands.
-sh: /etc/init.d/rc.conf: line 4: cannot create /var/env: Permission denied
ermittle die aktuelle TTY
tty is "/dev/pts/0"
setconsole: TIOCCONS: Operation not permitted
Console Ausgaben auf dieses Terminal umgelenkt
~ $

MfG Oliver

 

[albern]

Der olistudent möge mir meine spontan-unflätigen Gedanken verzeihen, als ich sein Posting las. Immerhin bewog es mich aber dazu, noch einmal ganz von vorn zu beginnen.
Und siehe da:
Inzwischen kann man sich auch als Nicht-root per ssh auf 'meiner' Box anmelden und beliebige Tunnel aufbauen; sowohl mit Passwort als auch mit Schlüsselpaar.

Herzlichen Dank an alle für die Hilfestellungen!


(Fürs Protokoll noch einmal zu den angerissenen Fragen:
1. Der dropbear funktioniert wie er soll; der root-only-patch muss eben entsprechend weggelassen werden [#2].
2. Die ssh-Anmeldung mittels Schlüssel klappt bei mir auch mit dem patch zur Limitierung der Anmeldeversuche ohne Probleme [#12, #14].
3. Das ominöse sofortige Abmelden nach dem Anmelden [#9] lag höchstwahrscheinlich an einer fehlerhaften shell-Zuweisung. Dieses Verhalten trat beim nachträglichen Testen immer dann auf, wenn es, z.B. durch Schreibfehler, das Programm gar nicht gab, auf das die Einträge in /etc/passwd und /etc/shells verwiesen.
)

LG

 

[hermann72pb]

Und wie kamen diese Fehler zu Stande? Ich meine, es ist viel interessanter zu wissen nicht wo die Fehler liegen, sondern, wie man sie vermeiden kann. Sonst steht jemand in 2-3 Monaten wieder auf dem gleichen Schlauch.

Und eine Bitte an dich, albern: Verewige bitte #7 in WIKI! Du glaubst nicht, wievielen du damit OpenVPN ersparen kannst. Es geht übrigens auch mit PUTTY-GUI, nicht nur über Commando-Zeile.

MfG

 

[albern]

Und wie kamen diese Fehler zu Stande?

Welcher von den vielen Fehlern, die ich gemacht habe, meinst Du speziell?


Einen Wiki-Eintrag habe ich begonnen vorzubereiten.
Dessen eigentlicher Wert läge allerdings mehr in der Zusammenfassung der Einrichtung von unprivilegierten Benutzern auf der FreetzBox. Für die Anwendung eines ssh-Tunnels, gerade mit putty, existieren schon viele Anleitungen.

Ich wollte mit dem Veröffentlichen aber abwarten, ob zum einen eventuell doch noch jemand eine konstruktive Kritik am Verfahren an sich einbringt (z.B. "Selbst ein unprivilegierter Benutzer darf immer noch viel zu viel auf einer FritzBox, als das das jemals sicher genannt werden könnte - die Klimmzüge kannst du dir sparen ..." oder so).
Und zum anderen schien es zumindest beim Einsatz von ftp und samba, die ich allerdings beide nicht verwende, Probleme mit neu angelegten Benutzern zu geben (http://trac.freetz.org/ticket/61).

LG

 

[kriegaex]

Hermann hat Recht: VPN kann man mit Dropbear und irgendeinem SSH-Client wirklich vermeiden. Hübsch finde ich übrigens auch immer Reverse-Tunnels, sodaß man sich von einem per SSH erreichbaren Rechner aus auch zum Client zurück verbinden kann. Dazu muß lediglich der Tunnel offen gehalten bzw. automatisch neu aufgebaut werden, z.B. mit Tunnelier unter Windows oder mit autossh unter Linux bzw. Windows/Cygwin. Auf Windows-Seite, falls der Server eine Windows-Maschine ist, kann man mit Cygwin auch sehr schön und stabil einen sshd als Windows-Dienst einrichten.

Edit: Ach ja, noch was: Man kann häufig genutzte SSH-Verbindungen mitsamt allen Tunnels einfach in ~/.ssh/config abspeichern und dann über einen bequemen Alias aufrufen. Benutzer, Port, Tunnels etc. sind dann direkt gesetzt, wenn man einfach nur ssh mein_alias aufruft.

 

[newland]

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