Ubuntu via Handy mit OpenSSH fernsteuern

Hin und wieder kommt es vor, dass der Rechner einfach seine Zeit braucht, um etwas fertig zu stellen. Sei es ein Download, ein System-Update oder gar -Upgrade oder das Kompilieren einer aufwändigeren Anwendung. Nicht immer hat man Zeit und Lust am Rechner zu sitzen und darauf zu warten, bis er mit seiner Aufgabe fertig geworden ist. Den Rechner möchte man aber vielleicht trotzdem nicht unnötig lange laufen lassen.

Ein anderes Szenario ist – wie in meinem Falle – der Rechner der Eltern, auf dem man wunderbar Ubuntu installiert hat und es nun hin und wieder via Internet aktualisieren möchte. Wenn man nicht immer vor Ort sein kann, dann wäre es sehr praktisch, wenn man dies aus der Ferne erledigen könnte. Eben schnell ein kurzer Anruf: „Mutter! Schmeiß’ die Kiste an!“ Und schon kann es losgehen.

Geht nicht? Geht doch! Es geht sogar sehr einfach. Es gibt fünf grobe Schritte, welche zu befolgen sind um zu diesem Ziel zu gelangen:

1. Installation und Konfiguration des OpenSSH-Dämons
2. DynDNS einrichten
3. Installation und Konfiguration der SSH-Client-Software auf dem Handy
4. Konfiguration des Routers/der Firewall
5. Sicherheitstipps

Wer allerdings eine grafische Steuerung erwartet wird enttäuscht. Hier läuft alles über die Shell ab. Dies mag vielleicht schade sein, aber es spart Transfervolumen, was je nach Datentarif am Mobiltelefon günstiger und je nach verfügbarem Datenzugang außerdem viel schneller ist, steht mal kein UMTS/HSDPA zur Verfügung. Außerdem macht es an einem „normalen Mobiltelefon“ auch wenig Sinn auf einen Briefmarken-Bildschirm irgendwelche GUIs zu übertragen.

Packen wir es also an!

Schritt 1: OpenSSH-Dämon installieren und konfigurieren

Die Installation des Open-SSH-Dämonen (Daemons) bzw. -Servers ist so simpel wie sonst was:

sudo apt-get install openssh-server

Fertig! Jetzt wird zunächst die Konfigurationsdatei editiert:

sudo gedit /etc/ssh/sshd_config

Folgendes ist der Datei hinzu zu fügen bzw. abzuändern… .

Zunächst sollten wir die Option abschalten, sich direkt als root anzumelden. Dies ist unter Ubuntu ohnehin nicht möglich, aber sicher ist sicher. Die administrativen Rechte holen wir uns dann wie gewohnt mit sudo:

1. ÄNDERN VON:

PermitRootLogin yes

IN:

PermitRootLogin no

Anschließend möchten wir uns via Passwort anmelden, was im Zusammenhang mit MidpSSH (dem SSH-Client für Java-fähige Mobiltelefone), meines Wissens nach bislang die einzige Authentifizierungsmöglichkeit ist:

2. EINFÜGEN VON:

Password Authentication yes

… am besten direkt unter die Zeile UsePAM yes.

Und dann noch dies hier… . Dazu gleich mehr!

3. EINFÜGEN VON:

# Allow/Deny Users and Groups
AllowGroups admin

… an das Ende der Datei.

Man kann natürlich noch mehr konfigurieren, dies sind aber die einfachsten Schritte, welche die grundlegenden Bedürfnisse abdecken sollten.

Dann sei noch zu AllowUsers bzw. DenyUsers und AllowGroups bzw. DenyGroups folgendes gesagt: Mit AllowUsers kann man Benutzernamen auf dem Server angeben, welche Benutzer sich via SSH am System anmelden dürfen bzw. unter DenyUsers, welche dies nicht dürfen. Ähnlich verhält es sich mit AllowGroups: Hier im Beispiel ist admin als Gruppe eingetragen, was allen Benutzern mit Administrationsrechten den Zugriff auf das System via SSH gestattet. Genauso kann man mit DenyGroups bestimmte Benutzergruppen vom Zugriff ausschließen.

Nun nur noch ein Neustart des Servers:

sudo /etc/init.d/ssh restart

Und damit wäre der Dämon einsatzbereit. Ob er funktioniert, können wir zunächst an einem anderen Rechner im lokalen Netz testen, sofern ein Zweitrechner vorhanden ist:

ssh benutzername@IP_DES_SSH_SERVERS

Beispiel:

ssh klaus@192.168.2.10

Klappt es nicht, so prüft bitte zunächst eure Konfiguration und schaut unter Schritt 4 rein!

Schritt 2: DynDNS einrichten

Das Problem ist nun, dass wir außerhalb des lokalen Netzwerks nicht die IP-Adresse des Rechners mit dem SSH-Server kennen. Kaum jemand wird eine statische IP-Adresse besitzen. Daher brauchen wir einen Dienst, der einer von uns festgelegten Domain automatisch die aktuelle IP-Adresse des Systems zuweist und dieser nennt sich beispielsweise DynDNS. Es gibt auch noch andere Dienste dieser Art, aber ich beschränke mich hier zunmächst nur auf DynDNS, zumal dies der wohl bekannteste Dienst seiner Art sein dürfte.

Geht zunächst zu DynDNS.com, registriert euch dort kostenlos und erstellt euch eine Domain. Zum Beispiel: DOMAINNAME.dyndns.org

Wer nun das Glück hat einen Router zu besitzen, der DynDNS und ähnliche Dienste unterstützt, der kann in der entsprechenden Konfigurationsmaske des Routers seine DynDNS-Daten eintragen. Bei mir (Speedport W 701V „gefritzt“) sieht das wie folgt aus:

Fritz!Box  DynDNS Konfiguration

Wer einen Router ohne entsprechende DynDNS-Unterstützung seinen eigenen nennt oder gar keinen Router, sondern ein Modem besitzt, der muss auf eine Software-Lösung zurückgreifen. Dafür bietet sich der ddclient aus dem Ubuntu-Repository an, der bei einer Verbindung mit dem Internet die dynamische Domain mit der aktuellen IP-Adresse abgleicht. Installiert wird er wie folgt:

sudo apt-get install ddclient

Nach der Installation erfolgt auch sogleich die Konfiguration, die ihr schon mal vornehmen solltet.

Schritt 3: SSH-Client-Software installieren und konfigurieren

Es gibt sicherlich noch andere SSH-Clients für das Handy. Ich habe mich jedoch für MidpSSH entschieden, weil es meiner Ansicht nach ein sehr guter SSH-Client für mein Sony Ericsson K800i und K510i ist. Wer mag, kann natürlich auch andere Software testen. Genauso gibt es für Smartphones (Black Berry, iPhone, etc.) und andere Mobiltelefone, auch die passende Software. Die Vorstellung der zahlreichen Programme würde hier jetzt allerdings den Rahmen sprengen, weshalb ich mich nur auf MipdSSH beschränke.

Nach der Installation und Ausführung der Anwendung auf dem Handy, sollte man sich zunächst ein Profil anlegen, um sich in Zukunft die ganze Tipperei zu ersparen. Anschließend kann man sich auch schon einloggen… .

Sehr praktisch ist die Funktion sich so genannte Macro sets anzulegen. Ich kann es wirklich nur empfehlen! Das sind einfach Vorlagen dafür, was man im Client sonst mühsam eingibt. Wer an seinem Mobiltelefon keine vollwertige Tastatur hat, wird wenig Freude beim Updaten des Systems haben, das er anschließend herunterfahren möchte:

sudo apt-get update && sudo apt-get upgrade
sudo shutdown -h now

Kurz paar Vorlagen/Macros angelegt, kann man sich hinterher das nervige getippe mit T9 ersparen.

Auch das „Abschießen“ einer Anwendung kann man sich erleichtern. Statt zum Beispiel:

sudo ps -fe | grep firefox
sudo kill -9 2641

… immer wieder einzugeben, können wir zwei Macros erstellen:

sudo ps -fe | grep

… und …

sudo kill -9

WICHTIG: Am Ende der Zeile sollte in beiden Macros ein Leerzeichen eingefügt werden! Außerdem sollte, bei der Erstellung der Macros, die Option Mode auf Type gestellt sein!

Der Grund für diese beiden „Besonderheiten“ ist ganz einfach: Was am Ende der Zeile steht, variert, je nachdem, welche Anwendung bzw. welche Prozess-ID man abschießen möchte. Somit hat man nach Auswahl des jeweiligen Macros noch immer die Möglichkeit, mit Input, die fehlenden Angaben am Ende der Zeile zu ergänzen, bevor man die endgültige Befehlszeile abschickt.

Schritt 4: Router (NAT) und Firewall konfigurieren

Wer sich im lokalen Netzwerk nicht auf dem SSH-Server einloggen kann, hat vermutlich entweder etwas falsch konfiguriert oder eine Software-Firewall laufen. Ich persönlich bin der Meinung, dass Software-Firewalls nur eine Ressourcenverschwendung sind, aber es sei jedem selbst überlassen darüber zu entscheiden, was nötig und unnötig ist. Standardmäßig sollte die Firewall auf dem Server – sofern vorhanden – eingehende und ausgehende Verbindungen auf dem TCP-Port 22 zulassen. Wer einen anderen Port für seinen SSH-Dämon benutzt, muss in der Firewall den entsprechenden TCP-Port statt TCP-Port 22 freigeben.

Sollte dies nun klappen, aber eine Verbindung vom Handy oder von einem externen Rechner aus – also außerhalb des lokalen Netzwerkes – scheitern, so kann es daran liegen, dass man hinter einem Router sitzt, der eingehende Verbindungen aus Sicherheitsgründen blockiert. Normalerweise biete der Router – in meinem Falle ein „gefritzter“ Speedport W 701V – unter den Konfigurationsoptionen die Möglichkeit die NAT (eine Art Firewall) zu konfigurieren. Schlagen wir also ein Löchlein in die Wand für die IP des Rechners, auf dem der SSH-Dämon läuft, für TCP-Port 22 oder welchen Port man bei sich auch immer gewählt hat. Danach sollte alles soweit funktionieren. Bei mir sieht das so aus:

Fritz!Box  NAT Konfiguration

Schritt 5: Sicherheitstipps

Zu beachten ist, dass die Authentifizierung auf dem Server nun über das Passwort eines lokalen Benutzers durchgeführt wird. Daher ist es sehr wichtig, dass alle Benutzernamen, über die man sich via SSH am System einloggen kann, über ein möglichst starkes und sicheres Kennwort verfügen. Einfache Kennwörter sind unter Umständen leicht zu erraten und stellen somit ein Sicherheitsrisiko dar – vor allem, wenn es sich um Benutzer mit Administrationsrechten handelt!

Sofern der SSH-Client dies unterstützt – MidpSSH tut es bislang meines Wissens nach nicht – empfiehlt es sich statt der Passwort-Authentifizierung die Public-Key-Authentifizierung zu benutzen. Nähere Informationen dazu ergoogelt bitte selbst.

Außerdem ist es ein Trugschluss, dass die Abweichung beim SSH-Server vom Standard TCP-Port 22 auf einen anderen Port – z.B. 27409 – für mehr Sicherheit sorgt. Es mag sicherlich einige Möchtegern-Cracker und -Hacker täuschen oder eventuell die Sichtbarkeit eines offenen Ports etwas hinauszögern, allerdings zeigt ein Portscan relativ schnell, welche Ports am System geöffnet sind und welche nicht.

Daher gilt: Wer einen SSH-Server nicht wirklich braucht, sollte auf ihn verzichten. Nur weil es „witzig“ ist sein System via Mobiltelefon zu steuern, muss es noch lange nicht sinnvoll sein! Für gewöhnlich sollte das System zwar grundsätzlich sicher sein, aber offene Ports stellen immer ein Sicherheitsrisiko dar, welches nichts ausgenutzt werden muss, aber kann, wenn z.B. die entsprechende Software eine Sicherheitslücke oder etwaige Bugs aufweist oder Kennwörter zu leicht zu erraten sind.

So, und nun hoffe ich, dass ich nichts vergessen habe und wünsche euch viel Spaß damit!

  1. helene-crawford reblogged this from ubuntujunkie
  2. ubuntujunkie posted this