Linux Terminal im Web

Als *unix Administrator wird man SSH wohl kennen und lieben. Auch wenn man mit einem Windows Computer arbeiten muss, kann mit Tools wie Putty sehr einfach auf dem Linux Server gearbeitet werden. Es gibt allerdings Situationen wo auch das nicht funktioniert, weil das Netzwerk ausgehenden SSH Traffic nicht zulässt. Dies ist auch verständlich, könnte man mit SSH doch sehr einfach einen verschlüsselten Tunnel aufbauen und geheime Konten-Informationen klauen.

Es gibt jedoch einen Weg, mit dem man trotzdem auf den Linux Server zugreifen kann, ohne dabei die Möglichkeit zu haben, einen Tunnel zu erstellen. Das Tool das man dazu benötigt findet sich auf Google Code und nennt sich shellinabox.

Leute die wie ich mit Debian arbeiten, haben es besonders einfach:
wget http://shellinabox.googlecode.com/files/shellinabox_2.10-1_i386.deb
dpkg -i shellinabox_2.10-1_i386.deb

Damit wird automatisch eine Init Script erstellt welches man hier findet: /etc/init.d/shellinabox. Wurde dieses ausgeführt, lässt sich die Linux Shell via Browser hier erreichen: https://localhost:4200. Da allerdings auch der Port 4200 wohl meistens geblockt wird, wollen wir den Verkehr von HTTPS zu 4200 umleiten, indem wir mit Apache einen Reverse Proxy einrichten. Als erstes müssen wir sicherstellen, dass beim Apache die entsprechenden Module aktiv sind:

/etc/apache2/mods-enabled
ln -s ../mods-available/proxy.conf
ln -s ../mods-available/proxy.load
ln -s ../mods-available/proxy_http.load

Anschliessend die gewünschte Apache Seiten Konfiguration anpassen. In meinem Fall hab ich in /etc/apache2/sites-available/default-ssl die folgenden Zeilen eingefügt:
<Location /shell>
ProxyPass http://localhost:4200/
Order allow,deny
Allow from all
</Location>

Shellinabox arbeitet standardmässig mit HTTPS und kann von jeder IP Adresse angesprochen werden. Auch das ändern wir, indem wir in /etc/init.d/shellinabox SHELLINABOX_ARGS hinzufügen (nur die letzte Zeile in der folgenden Box):
# Set some default values
SHELLINABOX_DATADIR="${SHELLINABOX_DATADIR:-/var/lib/shellinabox}"
SHELLINABOX_PORT="${SHELLINABOX_PORT:-4200}"
SHELLINABOX_USER="${SHELLINABOX_USER:-shellinabox}"
SHELLINABOX_GROUP="${SHELLINABOX_GROUP:-shellinabox}"
SHELLINABOX_ARGS="--localhost-only --disable-ssl"

Nun alle Dienste neu starten: “/etc/init.d/shellinabox restart” und /etc/init.d/apache2 restart” – schon lässt sich die Shell via https://localhost/shell erreichen!




5 Comments

Eine Frage die mit dem obigen Thema nicht direkt etwas zu tun hat: wenn Sie für concrete entwickeln – wie z.B. in dem Tutorial in dem Sie den auto_nav Block mit einem eigenen ersetzen – welche Instrumente benutzen Sie? Welche IDE? Ich nutze z.B. eclipse – gibt es eine Möglichkeit wie ich meinen auto_nav Block (concrete5.3.3.1\blocks\autonav\templates\drop_down_menu\view.php) zur Laufzeit debuggen kann? Die php Welt ist relativ neu für mich und mir ist nicht ganz klar wie ich das alles am besten einrichte.
Danke im Voraus für Ihre Hilfe.

Ich verwende den oben erkärten Shellzugriff relativ oft, dann allerdings mit “vi” als Editor. Gewöhnungsbedürftig, aber sehr effizient wenn man sich damit auskennt…

Eclipse ist mir für reine PHP Entwicklung zu gross und träge. Sublime ist eher was ich mag, keine Buttons, viele Shortcuts, viele Makros usw.

Debuggen geht schon, mach ich mit http://xdebug.org/ Direkt aus der Sublime geht das aber soweit ich weiss nicht, die meisten PHP Fehler sind aber auch meistens sehr einfach zu beheben so dass ich eigentlich relativ selten den Debugger verwende. Zend wäre hier wohl besser da dort alles in der IDE zu finden ist – für mich aber auch wieder zu gross..

Fazit: Ist alles eine Ansichtssache, ich verwende schnelle, schlanke Tools und mache viel auf der Commandline, andere wollen eine grosse IDE die alles kann…

Eclipse ist bei uns im Hause eine Standard-IDE da wir viel GWT/JAVA entwickeln. Natürlich bietet sie auch Projekt/Source code Verwaltung und ich würde sie gerne auch für unser concrete-Projekt verwenden. Bist jetzt sieht mein Entwicklungsprozess folgendermaßen aus: code schreiben -> code im concrete-Ordner speichern -> im error.log nach den Fehlern schauen -> code schreiben… Man kann das bestimmt besser machen, oder?
Allerdings die “schlanken Tools” reizen mich auch 🙂 Mal schauen wofür ich mich am Ende entscheide.
Danke für die Tipps.

Hinterlasse eine Antwort

Deine E-Mail-Adresse wird nicht veröffentlicht. Erforderliche Felder sind markiert *