Seite wählen

NETWAYS Blog

Wunderwelt ssh

Jahrelalang habe ich ssh, wie wahrscheinlich die meisten von uns, nur zum administrieren und direkten Zugriff auf entfernte Server benutzt. Ab und zu vielleicht nochmal scp aber dann war’s das auch wirklich.
In den letzten Monaten habe ich aber so viele coole Funktionen von ssh kennengelernt, dass ich die hier jetzt nochmal sammeln möchte um nicht alles in der nächsten Woche wieder vergessen zu haben.

Authentifizierung

Ein Feature, das die tägliche Arbeit sehr erleichtert ist das authorized_keys file in ~/.ssh
Hier trägt man einfach den public key des users ein der sich auf diesen Host verbinden darf und alle Passworteingaben haben sich erstmal erledigt.

Portweiterleitung

Man kann ssh nicht nur für die direkte Kommunikation auf eine remote shell benutzen sondern alle Möglichen Dienste durch ssh tunneln und so Firewallgrenzen überspringen und sich die Arbeit erleichtern.
Ich benutze als Beispiel mal einen Webserver, der auf einem entfernten Host läuft und nur über einen weiteren Hop erreichbar ist. Die Firewall im Bild lässt bloß Port 22 auf HostA zu.

Aufbau ssh environment

ssh environment


Beispiel 1: Zugriff von HomeLaptop auf auf webserver.
Um dieses Szenarion zu realisieren kann man z.B. den Port 80 des webservers über HostA durch den ssh tunnel auf den lokalen Port 8080 des HomeLaptops weiterleiten.
Hierbei hat man zwei Möglichkeiten. Entweder man baut 2 Tunnel hintereinander, oder man sagt ssh wie es von LaptopHome zum webserver kommt.

# als erstes einen tunnel vom webserver zum HostA
user@LaptopHome:# ssh kalle@HostA
user@HostA:# ssh -L 8080:127.0.0.1:80 manfred@webserver
# als nöchstes in einem anderen terminal
user@LaptopHome:# ssh -L 8080:127.0.0.1:8080 user@HostA

Die Alternative finde ich persönlich viel schöner.
Man öffnet auf LaptopHome die ~/.ssh/config Datei und trägt folgenden Zeilen ein.

Host HostA
   User Kalle
   Hostname HostA
Host webserver
   User manfred
   # mit -a bewirkt dass der public key des gateway hosts auf dem Zielsystem sein muss
   ProxyCommand ssh -x -a -q HostA nc %h 22
   # kein -a bewirkt, dass der public key des initiierenden users auf dem Zielsystem sein muss
   ProxyCommand ssh -x -q HostA nc %h 22

Am Ende kann man mit einem kurzen Befehl den Tunnel aufbauen

user@LaptopHome:# ssh -L 8080:127.0.0.1:80 webserver

Einen Wunsch könnte man im Zweifelsfall noch haben. Eventuell möchte man vom HomePC auch auf den webserverzugreifen. Jetzt könnte man natürlich die .ssh/config Datei um ein weiteres ProxyCommand erweitern. Es gibt jedoch noch eine andere Möglichkeit. Mit Hilfe der ssh option -g kann man den lokalen Port allgemein Verfügbar machen.

user@LaptopHome:# ssh -L 8080:127.0.0.1:80 webserver -g

Und schon kann von HomePC auf http://LaptopHome:8080 zugegriffen werden.
Beispiel 2: Den Kollegen auf der Arbeit den Datenbankserver zur Verfügung stellen.
Der Datenbankserver HomeDB stellt im LAN eine mysql Datenbank auf Port 3306 bereit.

user@HomeDB:# ssh kalle@HostA -R 10000:HomeDB:3306

Das führt dazu, dass auf der man auf der Arbeit auf HostA, Port 10000 der mysql Dienst zur Verfügung steht.

magical bash

Das ProxyCommand Beispiel bedient sich, um die direkte Weiterleitung sicherzustellen, des Linux tools netcat alias nc. Es soll allerdings in der großen weiten Welt Systeme geben, auf denen kein netcat existiert. Im Beispiel müsste dieses auf HostA installiert sein. Sollte es sich bei diesem jedoch z.B. um ein älteres Solaris oder AIX System handelt so könnte es auch sein, dass dem nicht so ist.
Möchte man jetzt aber trotzdem das ProxyCommand nutzen gibt es noch eine Möglichkeit mit Hilfe der /dev/tcp Schnittstelle, die einem von BASH bereitgestellt wird, ein netcat nachzubilden.

Host HostA
   User Kalle
   Hostname HostA
Host HostA
   User Manfred
   ProxyCommand ssh webserver "/bin/bash -c 'exec 3<>/dev/tcp/HostA/22; cat <&3 & cat >&3;kill $!'"

Sollte ich noch weitere ssh magic herausfinden werde ich nicht zögern euch diese mitzuteilen.

Christoph Niemann
Christoph Niemann
Senior Consultant

Christoph hat bei uns im Bereich Managed Service begonnen und sich dort intensiv mit dem internen Monitoring auseinandergesetzt. Seit 2011 ist er nun im Consulting aktiv und unterstützt unsere Kunden vor Ort bei größeren Monitoring-Projekten und PERL-Developer-Hells.

Weekly Snap: Require.JS, Managing SSH Connections & Protocol Handlers in Firefox

2 – 6 July featured the OSMC, Birger’s sabbatical and tips for developers and systems administrators.
Achim gave us his tips for managing SSH connections manually and Jannis recommended Require.JS as an efficient solution for organising code in JavaScript.
Dirk then showed how to integrate protocol handlers into Firefox, while Birger shared his first thoughts on his sabbatical and how he found Bulletproof Networks, his employer Down Under.
Eva counted 107 days down to the OSMC with Thomas Gelf’s presentation on “Monitoring at Large – the World is not Enough” and reflected on the whirlwind of emails, ticket reservations and preparations for the upcoming Puppet Camp and OSMC. She also encouraged OSMC guests to bring a companion along.

Protokoll-Handler in Firefox oder wie komm ich schnell zu meinen Problemen

Eine der schnellsten und komfortabelsten Möglichkeiten auf ein problematisches System zuzugreifen ist für mich auf einen Link in der Überwachung zu klicken. Somit ist nur die Frage wie bekomme ich die Möglichkeit auf eine URL zu klicken und es öffnet sich meine SSH-Verbindung, mein VNC-Fenster oder die Remotedesktop-Sitzung?
Die Lösung hierfür heißt auf der einen Seite action_url (oder notes_url) in Nagios oder Icinga, auf der anderen Seite muss ich meinen Browser noch dazu bringen mit entsprechenden URLs umzugehen. Chrome reicht diese einfach an das System weiter, was gut funktioniert wie mir gesagt wurde. Der Internet Explorer und Firefox brauchen dagegen etwas Hilfe. Natürlich gibt es für beide Lösungen wie entsprechende Plugins, hier wäre für den IE der Putty-Fork Kitty oder für den Firefox das javascript-basierende Addon Firessh zu nennen.
Nun ja, ich arbeite am liebsten mit Firefox, einfach aus der Historie heraus, und ich nutze am liebsten meine gewohnten Werkzeuge, also ist alles vorherige schön und gut, aber nicht was ich will. Außerdem handelt es sich um keine allumfassende Möglichkeit, wenn ich noch weitere Protokolle einbinden will.
Daher möchte ich am Beispiel von ssh zeigen wie man entsprechende Protokoll-Handler in Firefox einbaut. Die Vorgehensweise funktioniert so ab Firefox 3.6:

  1. Erstellen eines Scripts zum Öffnen des Links
  2. Öffnen von about:config in Firefox und bestätigen der Sicherheitsabfrage
  3. Erstellen eines neuen Boolean network.protocol-handler.expose.ssh über Rechtsklick und zuweisen des Werts false
  4. Schließen von Firefox und erneutes öffnen (in aktuellen Versionen nicht mehr nötig)
  5. Öffnen eines SSH-Links wie ssh://user@host:port
  6. Auswählen des Skripts zum Öffnen der Links, Haken für Auswahl merken setzen!

Hiermit ist es möglich beliebige Protokolle einzubinden, nur die Verwendung von file:// und smb:// lässt Firefox aus Sicherheitsgründen nicht zu!
Und damit nun nicht jeder ein eigenes Skript basteln muss noch zwei Beispielskripte, die ich mir mal auf die schnelle gebastelt hatte.
Die URLs haben hierbei folgenden Aufbau:

  • ssh://user@host:port
  • telnet://user@host:port
  • rdesktop://user@host:port
  • vnc://host:display

Das erste Beispielskript ist für die Verwendung unter Linux mit Gnome gedacht und zerlegt die URL und baut daraus einen Connectionstring für ssh oder telnet, welches innerhalb eines neuen Gnome-Terminals ausgeführt wird, und startet auch rdesktop und vncviewer.

#!/bin/bash
protocol=$(echo $1 | cut -d : -f 1)
address=$(echo $1 | cut -d / -f 3)
user=$(echo $address | grep @ | cut -d @ -f 1)
port=$(echo $address | grep : | cut -d : -f 2)
host=$(echo $address | cut -d @ -f 2 | cut -d : -f 1)
case $protocol in
ssh)
connectstring=$(echo "$([ -z $user ] || echo "$user@")$host$([ -z $port ] || echo "-p $port")")
gnome-terminal --window -e "$protocol $connectstring"
;;
telnet)
connectstring=$(echo "$host $([ -z $port ] || echo "$port")$([ -z $user ] || echo "-l $user")")
gnome-terminal --window -e "$protocol $connectstring"
;;
rdesktop)
connectstring=$(echo "$([ -z $user ] || echo "-u $user ")$host$([ -z $port ] || echo ":$port")")
rdesktop -g 1280x960 $connectstring
;;
vnc)
connectstring=$(echo "$host$([ -z $port ] || echo":$port")")
vncviewer $connectstring
;;
esac

Mein Beispielskript für Windows ist weniger elegant und kann nicht mit Ports umgehen, dieses öffnet Putty für ssh und telnet bzw. Realvnc für vnc mit festem Pfad sowie mstsc für Remotedesktop.

@ECHO OFF
set parameter=%1%
echo %parameter% |findstr ssh:// >nul:
if not errorlevel 1 GOTO SSH
echo %parameter% |findstr telnet:// >nul:
if not errorlevel 1 GOTO TELNET
echo %parameter% |findstr rdesktop:// >nul:
if not errorlevel 1 GOTO RDESKTOP
echo %parameter% |findstr vnc:// >nul:
if not errorlevel 1 GOTO VNC
GOTO END
:SSH
set host=%parameter:ssh://=%
START C:\Programme\PuTTY\putty.exe -ssh %host%
GOTO END
:TELNET
set host=%parameter:telnet://=%
START C:\Programme\PuTTY\putty.exe -telnet %host%
GOTO END
:RDESKTOP
set host=%parameter:rdesktop://=%
START %SystemRoot%\system32\mstsc.exe -v:%host%
GOTO END
:VNC
set host=%parameter:vnc://=%
START C:\Programme\RealVNC\VNC4\vncviewer.exe %host%
GOTO END
:END

Die Anwendung ist natürlich nicht nur auf Nagios bzw. Icinga beschränkt, auch Check_interfacetable_v3t integriert standardmäßig einen Link für den ssh- oder telnet-Zugriff auf das überwachte System, Mediawiki lässt es zu entsprechende URLs einzubauen und natürlich alle Software, die es erlaubt beliebige URLs anzugeben.
Ich hoffe der ein oder andere hat Verwendung hierfür und wünsche dann viel Spaß mit den nun noch schneller erreichten Systemen.

Dirk Götz
Dirk Götz
Principal Consultant

Dirk ist Red Hat Spezialist und arbeitet bei NETWAYS im Bereich Consulting für Icinga, Puppet, Ansible, Foreman und andere Systems-Management-Lösungen. Früher war er bei einem Träger der gesetzlichen Rentenversicherung als Senior Administrator beschäftigt und auch für die Ausbildung der Azubis verantwortlich wie nun bei NETWAYS.

SSH-Verbindungen verwalten

Letzte Woche wurde hier im Blog mRemote vorgestellt, welches unter Windows sehr gute Dienste leistet um verschiedenste Remotezugänge zu verwalten. Für Administratoren, die unter Linux arbeiten, ist die Shell oftmals das Mittel der Wahl. SSH-Verbindungen können dort ohne großen Aufwand in der .ssh/config gepflegt werden. Hier muss man zwar alles manuell machen, aber man ist meistens trotzdem schneller, als wenn man seine SSH-Verbindungen zum Beispiel mit gnome-rdp verwaltet. Aber das zeige ich am besten an einem kurzen Beispiel.

Host local-debian
  HostName 192.168.0.98
  User user1

Mit dem Befehl ssh local-debian verbindet man sich als Benutzer user1 auf den Server mit der IP-Adresse, die bei HostName angegeben ist. Hier funktioniert auch die automatische Vervollständigung und das nicht nur für ssh, sondern auch für scp und rsync.

Host db-node1 db-node2 db-node3
  User dbuser1
  HostName %h.intern.example.com

Hat man mehrere Systeme, kann Host auch mehrere Namen enthalten. Unter Hostname kann man eine gemeinsame Domain angeben. An Stelle von %h wird der an ssh übergebene Name eingesetzt (hier z.B. db-node3). Wenn man 53 App-Server hat, will man diese natürlich nicht alle manuell eintragen. Auch an das wurde gedacht und man kann Wildcards verwenden kann. Die Autovervollständigung funktioniert dann natürlich nicht mehr.

Host db-app-*
  User appuser1
  HostName %h.intern.example.com
  ForwardAgent yes

Sehr praktisch ist auch die Option ForwardAgent. Dieses bewirkt, dass die Verbindung zu meinem authentication agent geforwardet wird. Wenn ich mich also auf db-app-23 mit Hilfe meines public key eingeloggt habe, kann ich mich direkt von dort aus per ssh auf db-node1 verbinden. Vorausgesetzt wird hier natürlich, dass ein Zugang zu beiden Rechner besteht besteht. Hier muss man natürlich aufpassen. Jeder, der Zugriff auf den Socket auf db-app-23 hat, hat die Möglichkeit, die Identitäten, die im authentication agent geladen sind, zu nutzen. Das Schlüsselmaterial ist aber sicher!
Mehr Infos zur dem Thema findet man unter natürlich unter man ssh_config.

Achim Ledermüller
Achim Ledermüller
Senior Manager Cloud

Der Exil Regensburger kam 2012 zu NETWAYS, nachdem er dort sein Wirtschaftsinformatik Studium beendet hatte. In der Managed Services Abteilung ist er für den Betrieb und die Weiterentwicklung unserer Cloud-Plattform verantwortlich.

Multitab Remoteverbindungs-Manager

mRemote
Als ich letztens temp. von Linux auf Windows umstellen musste, waren die ersten Tage als Administrator doch sehr mühsam. Immer wieder das Putty auf machen, RDP vorbereiten und Co. Dazu fehlte mir die gewohnte Tab-Umgebung einer einfachen Linux Shell und deren Struktur zur Ordnung der ganzen Verbindungen. Nach ein paar Tagen hat mich das ganze dann so gestört, dass ich mich nach Alternativen umgeschaut habe. Denn das muss doch auch unter Windows irgendwie einfach unter einen Hut zu bekommen sein – und am besten auch kostenlos.
Fündig wurde ich dann bei einem eigentlich sehr alten Tool, welches sich mRemote nennt. Es bietet Windows Usern auf einer Open-Source Basis die Möglichkeit, gleich eine ganze Fülle von Verbindungsarten zentral zu Verwalten und zu Steuern. In der letzten freien Version werden folgende Protokolle unterstützt : RDP, VNC, ICA, SSH, Telnet, HTTP/S, Rlogin und Raw. Zus. bietet es auch einen integrierten Dateitransfer über SCP/SFTP an – also an sich eine Verbindung vieler Aufgaben in einem Programm.
Sehr zu erwähnen ist die Art und Weise, mit der man die ganzen Verbindungen Ordnen kann. Es gibt z.B. die Möglichkeit Verbindungen zu einer bestimmten Gruppe zusammenzufassen und diese dann in einem eigenen Sub-Tab zu betreiben. Diese wiederum kann man sogar an verschiedene Bereiche eines Bildschirms docken oder auf mehrere Monitore auftrennen und jederzeit frei verschieben. Experimentell kann man sogar die ganzen Verbindungen in einer Datenbank speichern um so die Verwaltung noch zu vereinfachen.
Die Erwähnung als ‚letzte freie Version‘ bezieht sich auf eine Zusammenlegung von mRemote mit dem Remote Desktop von visionapp. Neuer Features und Funktionen werden dann seit 2009 in einer kommerziellen Lösung weiter betrieben. Für Administrator, welche fest unter Windows arbeiten sicher ein nicht ganz unnützliches Tool. Und die Lizenzkosten halten sich auch auf einem sehr niedrigen Niveau.