If you’re a *unix admin you probably like SSH a lot. Even if you have to work on a Windows computer you can simply download a small tool like Putty and you’re ready to work on your server. However, there are situations where not even Putty works – if you’re behind a firewall that filters the outgoing traffic as well. It usually makes sense to block outgoing SSH traffic in a big company because you could easily create an encrypted tunnel to move secret data to any server you want.
But there’s another way to access your server using SSH like tools without having to worry about encrypted tunnels or any other threats SSH could cause. It’s called shellinabox and can be found on Google Code.
If you’re working with debian like I do, you can even download a prebuilt deb file.
wget http://shellinabox.googlecode.com/files/shellinabox_2.10-1_i386.deb
dpkg -i shellinabox_2.10-1_i386.deb
The installer creates an init script located in /etc/init.d/shellinabox. As soon as it has been started you can access your shell using any webbrowser using an address like this: https://localhost:4200. But the port 4200 is usually not accessible if you’re working behind a firewall that blocks SSH traffic. Let’s use apache to redirect traffic from HTTPS to 4200. We have to enable mod_proxy if it’s not already active:
/etc/apache2/mods-enabled
ln -s ../mods-available/proxy.conf
ln -s ../mods-available/proxy.load
ln -s ../mods-available/proxy_http.load
Edit the site file where you want to add your shell, I used /etc/apache2/sites-available/default-ssl and added these lines:
<Location /shell>
ProxyPass http://localhost:4200/
Order allow,deny
Allow from all
</Location>
Shellinabox uses https by default as well and is accessible by any ip address. We want to change that, let’s edit this file /etc/init.d/shellinabox and add SHELLINABOX_ARGS (the last line in the following 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"
If you now restart all the services “/etc/init.d/shellinabox restart” and /etc/init.d/apache2 restart”, you’re shell can be accessed by https://localhost/shell from anywhere you want!
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.
error.log kann man umgehen, einfach diese Zeilen einfügen (z.B in index.php), dann werden Fehler im Browser angezeigt.. Natürlich sollte man dies nur bei Entwicklungssystem tun.
ini_set(“display_errors”, 1);
error_reporting(E_ALL);
Danke für den Tipp. Das sind auch die Einstellungen die ich in der php.ini habe. Oder werden diese von concrete überschrieben?