SSH authentication with GnuPG and smart cards

Most system administrators know how to use key-based authentication with SSH. Some of the more obvious benefits include agent forwarding (i.e. being able to use your SSH key on a remote system) and not having to remember passwords. There are, however, a few issues with having your SSH key on a general-purpose computer: Malware can obtain an unencrypted copy of your private SSH key fairly easily. Also, while migrating your key to another system is fairly easy it’s virtually impossible to securely use your SSH key on another untrusted system (e.g. at a customer).
This is where smart cards come in. A smart card stores certificates (such as your SSH key) and provides functionality for operating on those certificates (e.g. using their private key to sign or decrypt data). Smart cards come in various form factors: credit cards, SIM cards, etc. – which commonly require a separate card reader in order to be usable. However, there are also USB devices which implement all the usual smart card features in addition to other security features (e.g. requiring the user to press a key on the device before an authentication request is signed).
One such device is the Yubikey 4 which I’m personally using for SSH authentication.
The first step towards using a new Yubikey for SSH authentication is enabling the OpenPGP applet on it:

$ ykpersonalize -m82

I already had a PGP key, however in order to use it for authentication I had to create an additional subkey for the key usage type “authentication”. Here’s how that can be done:

$ gpg --edit-key --expert info@example.org
gpg (GnuPG) 2.1.23; Copyright (C) 2017 Free Software Foundation, Inc.
This is free software: you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law.
Secret key is available.
sec rsa2048/42330DF1CA650A40
created: 2017-08-24 expires: never usage: SC
trust: ultimate validity: ultimate
ssb rsa2048/56D8D1BBE7E720DB
created: 2017-08-24 expires: never usage: E
[ultimate] (1). NETWAYS Blog <info@example.org>
gpg> addkey
Please select what kind of key you want:
(3) DSA (sign only)
(4) RSA (sign only)
(5) Elgamal (encrypt only)
(6) RSA (encrypt only)
(7) DSA (set your own capabilities)
(8) RSA (set your own capabilities)
(10) ECC (sign only)
(11) ECC (set your own capabilities)
(12) ECC (encrypt only)
(13) Existing key
Your selection? 8
Possible actions for a RSA key: Sign Encrypt Authenticate
Current allowed actions: Sign Encrypt
(S) Toggle the sign capability
(E) Toggle the encrypt capability
(A) Toggle the authenticate capability
(Q) Finished
Your selection? s
Possible actions for a RSA key: Sign Encrypt Authenticate
Current allowed actions: Encrypt
(S) Toggle the sign capability
(E) Toggle the encrypt capability
(A) Toggle the authenticate capability
(Q) Finished
Your selection? e
Possible actions for a RSA key: Sign Encrypt Authenticate
Current allowed actions:
(S) Toggle the sign capability
(E) Toggle the encrypt capability
(A) Toggle the authenticate capability
(Q) Finished
Your selection? a
Possible actions for a RSA key: Sign Encrypt Authenticate
Current allowed actions: Authenticate
(S) Toggle the sign capability
(E) Toggle the encrypt capability
(A) Toggle the authenticate capability
(Q) Finished
Your selection? q
RSA keys may be between 1024 and 4096 bits long.
What keysize do you want? (2048)
Requested keysize is 2048 bits
Please specify how long the key should be valid.
0 = key does not expire
= key expires in n days
w = key expires in n weeks
m = key expires in n months
y = key expires in n years
Key is valid for? (0)
Key does not expire at all
Is this correct? (y/N) y
Really create? (y/N) y
We need to generate a lot of random bytes. It is a good idea to perform
some other action (type on the keyboard, move the mouse, utilize the
disks) during the prime generation; this gives the random number
generator a better chance to gain enough entropy.
sec rsa2048/42330DF1CA650A40
created: 2017-08-24 expires: never usage: SC
trust: ultimate validity: ultimate
ssb rsa2048/56D8D1BBE7E720DB
created: 2017-08-24 expires: never usage: E
ssb rsa2048/5F43E49ED794BDEF
created: 2017-08-24 expires: never usage: A
[ultimate] (1). NETWAYS Blog <info@example.org>
gpg> save

Now that we’ve created a new subkey we can move its private key part to the smart card:

$ gpg --edit-key --expert info@example.org
gpg (GnuPG) 2.1.23; Copyright (C) 2017 Free Software Foundation, Inc.
This is free software: you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law.
Secret key is available.
sec rsa2048/42330DF1CA650A40
created: 2017-08-24 expires: never usage: SC
trust: ultimate validity: ultimate
ssb rsa2048/56D8D1BBE7E720DB
created: 2017-08-24 expires: never usage: E
ssb rsa2048/5F43E49ED794BDEF
created: 2017-08-24 expires: never usage: A
[ultimate] (1). NETWAYS Blog <info@example.org>
gpg> toggle
sec rsa2048/42330DF1CA650A40
created: 2017-08-24 expires: never usage: SC
trust: ultimate validity: ultimate
ssb rsa2048/56D8D1BBE7E720DB
created: 2017-08-24 expires: never usage: E
ssb rsa2048/5F43E49ED794BDEF
created: 2017-08-24 expires: never usage: A
[ultimate] (1). NETWAYS Blog <info@example.org>
gpg> key 2
sec rsa2048/42330DF1CA650A40
created: 2017-08-24 expires: never usage: SC
trust: ultimate validity: ultimate
ssb rsa2048/56D8D1BBE7E720DB
created: 2017-08-24 expires: never usage: E
ssb* rsa2048/5F43E49ED794BDEF
created: 2017-08-24 expires: never usage: A
[ultimate] (1). NETWAYS Blog <info@example.org>
gpg> keytocard
Please select where to store the key:
(3) Authentication key
Your selection? 3
gpg> quit
Save changes? (y/N) y

The Yubikey 4 has three key slots which can be used for storing RSA keys with up to 4096 bits each. This might be an excellent opportunity to also move your signing and encryption key to your smart card – assuming you have an encrypted backup somewhere in case you lose access to your Yubikey.
The last step involves replacing ssh-agent with gpg-agent. This allows your SSH client to use your PGP certificates (including the authentication subkey we just created). In addition to that gpg-agent also supports regular SSH keys which might be useful if you have more than one SSH key and only plan to migrate one of them to your Yubikey:
I had to add the following snippet to my .profile file to start gpg-agent instead of ssh-agent:

[ -f ~/.gpg-agent-info ] && source ~/.gpg-agent-info
if [ -S "${GPG_AGENT_INFO%%:*}" ]; then
  export GPG_AGENT_INFO
  export SSH_AUTH_SOCK
  export SSH_AGENT_PID
else
  eval $(gpg-agent --daemon --write-env-file ~/.gpg-agent-info)
fi

And here’s OpenSSH prompting me for my smart card and PIN:

And that’s how you can literally put your PGP key on your keychain. 🙂

Windows und Remote Verbindungen – die 2.

windows-mac-or-linuxVor langer, langer Zeit (zumindest im IT Wesen), hatte ich einmal über die Verwaltung verschiedener Remote Verbindungen unter Windows geschrieben und Achim hat im Gegenzug eine Erklärung für Linux zusammengetragen. Seit dem hat sich einiges geändert und es gibt auch immer was neues, aber im Bereich der Verbindungs-Verwaltung scheint der Trend zu stagnieren. Der Fork mRemoteNG oder Tools wie Terminals scheinen einen Punkt erreicht zu haben, wo alle Bedürfnisse erreicht sind. Letzte Aktivitäten/Updates sind zumindest länger her, aber sie laufen ohne Probleme. Alternativen unter Windows per SSH lassen sich z.B. via PowerShell derzeit realisieren, falls jemand nativ in der PS unterwegs ist.
Man muss und kann also gespannt in die Zukunft schauen und evtl. sogar hoffen, dass sich irgend wann einmal ein Protokoll auf allen Systemen durchsetzt. SSH z.B. kommt unter Windows auch immer stärker zum Einsatz und wäre ein Kandidat hierfür, lassen wir uns überraschen.

Weekly Snap: Screen & SSH, Foreman & Parameterized Classes

weekly snap28 April – 2 May hailed in a new month with sys admin tips galore and a Request Tracker webinar slipped in.
Ronny began the week by sharing his trick to get Screen to work with SSH agent forwarding properly.
Markus then explained parameterized classes in Foreman as Michael showed how simple it is to configure Icinga 2 using the recent 0.0.10 release.
Last but not least, Christian and Marius held a successful webinar on Request Tracker after a technical hiccup.

SSH-Agent Forward und Screen

Ich glaube, dass wir Screen und SSH Agent Forwarding nicht weiter im Detail selbst besprechen müssen, aber mit diesem Post möchten wir auf ein Problem hinweisen, welches beim Einsatz von beidem zusammen aufkommt. Hintergrund ist folgender: SSH legt beim Connect mehrere ENV-Variablen an, welche auch den AUTH_SOCK enthalten. Dies ist ein Socket, der für die Kommunikation mit dem lokalen Agent verantwortlich ist und somit die Weiterleitung der Keys ermöglicht.
Unglücklicherweise werden diese EVN Informationen nur beim Start der Screen Session eingelesen, d.h. wenn man sich detached und dann mit einer neuen Verbindung wieder einhängt, enthält die Variable immer noch den alten Pfad, welche dann nicht mehr aktuell ist ( z.B. /tmp/ssh-hYQhk6Nrhq/agent.32462 ). Somit würde eine Verbindung innerhalb vom Screen zu einem Server dann keine Key Authentifizierung mehr durchführen und ein Passwort verlangen, was im ersten Moment dann sehr verwirrend ist.
Man kann sich aber mit einem kleinen Tricken helfen, welcher diesen Socket auf einen generischen Pfad legt. Dazu erstellt man sich eine SSH-RC Datei, die bei jeder Verbindung ausgeführt wird. ( SSH1 ~/.ssh/.rc | SSH2 ~/.ssh/rc )

#!/bin/bash
if test "$SSH_AUTH_SOCK" ; then
    ln -sf $SSH_AUTH_SOCK ~/.ssh/ssh_auth_sock
fi

Somit wird ein Link zum jeweiligen Pfad des Socket erstellt, welcher bei jeder Anmeldung dann auch überschrieben wird. Schon haben wir einen festen Namen. Nun geht es nur noch darum, diesen Pfad auch im Screen mit anzuziehen. Dazu erstellt/ändert man nur die .screenrc im Home-Verzeichnis wie folgt:

setenv SSH_AUTH_SOCK $HOME/.ssh/ssh_auth_sock

Als letztes muss die Screen Sitzung nur noch einmal neu gestartet werden, damit die Einstellung greift. Und schon wird bei jeder Neueinwahl auf den Server und ins Screen die korrekte Verbindung zum lokalen SSH Agent hergestellt.

Terminal-Farben für SSH-Hosts vergeben

Wer öfter mit SSH arbeitet, läuft schnell Gefahr die Übersicht über die offenen Remote-Terminals zu verlieren. Damit man nicht versehentlich Befehle auf dem falschen Host ausführt, wäre es sinnvoll die Farben automatisch zu wechseln, sobald man sich mit SSH auf einem neuen Host einloggt. Wenn man ein bisschen sucht, findet man für das Problem gleich mehrere Lösungen, die aber alle einige Nachteile haben: Oft funktionieren diese Lösungen nur für einen bestimmten Terminal-Emulator oder die Farben verschwinden nach dem ersten clear gleich wieder.
Wer eine umfassende Lösung will, kann das Programm Colorize verwenden. Colorize führt ein beliebiges Programm in einem virtuellen Terminal aus und ändert dabei die verwendeten Farben, ohne dass ein neues Terminal-Fenster geöffnet werden muss.
Zuerst compilen wir das Programm und verschieben es nach /usr/local:

./make
sudo cp ./colorize /usr/local/bin/colorize

Um die Farben für die einzelnen Hosts zu konfigurieren, wird die neue Datei ~/.ssh/host_colors erstellt. Jedem Host auf jeder Zeile kann im ersten Eintrag eine Hintergrundfarbe und im zweiten Eintrag eine Textfarbe zugewiesen werden. Bei den Farben muss eventuell ein bisschen probiert werden, da die Terminals oft nicht alle Farben unterstützen.

my.production.host 0x990000 0xffffff

Als nächstes muss in der ~/.bash_aliases noch eine Alias gesetzt werden, in dem ssh über colorize aufgerufen wird. Dabei wird die Konfiguration für den Host aus der eben erstellen host_colors geladen:

function colorssh() {
   if [ $# -gt 2 ]
     then
       # colorize only for simple ssh commands
       ssh "#@"
       return;
   fi
   host=$1;
   array=(`cat ~/.ssh/host_colors | egrep "^\s*$host\s+" | sed -e "s/^\s*//" | sed -e "s/\s\s*/ /"`)
   backg=${array[1]}
   foreg=${array[2]}
   if [ -z $backg ]
     then
       backg="0x111111";
   fi
   if [ -z $foreg ]
    then
      foreg="0xffffff";
    fi
   colorize -b $backg -f $foreg ssh "$@"
}
alias ssh=colorssh

Wenn man jetzt mit ssh den Host my.production.host öffnet, wird sich die die Farbe beim Start automatisch ändern.

An der Farbe kann man schnell erkennen, auf welchem Host sich das Terminal momentan befindet.

An der Farbe kann man schnell erkennen, auf welchem Host sich das Terminal momentan befindet.

Weekly Snap: Git Flow & GeoIP, Rsync & SCP

weekly snap1 – 5 April kicked off the month with tips for flowing Git branches, SSH transmission speed, clean website code and request redirection.
Eva began by counting 16 days to the OSDC with Benedikt Stockebrand’s presentation “Like Rats on a Sinking Ship” on the end of IPv4.
Stefan then shared his trick to boost SSH transmission speed with SCP and Rsync parameters while Bernd gave us his to redirect requests from specific countries.
To end the week, Eric explained the right flow for Git branching, and Tobias reminded us that clean website code matters to Google page ranks.

SCP und Rsync Boost Parameter

speedy
Wer kennt es nicht: Es muss schnell etwas per scp oder rsync aus dem Backup oder einem LVM Snapshot auf einen anderen Server im internen Netz kopiert werden, weil gerade zur ungünstigsten Zeit z.B. eine Datenbank nicht korrigierbar ausgefallen ist.
Da die dabei anfallenden Datenvolumen heuzutage wohl eher beständig mehr als weniger werden, ist jedes bisschen Übertragungs-Speed, das man aus der Leitung kitzeln kann, sehr wichtig.
Was gerne übersehen wird: SSH bietet da zumindest einen Parameter an, mit dem man die Geschwindigkeit ordentlich nach oben schrauben kann durch die Wahl eines anderen Cypher Algorithmus, auch über rsync.
Das ganze bringt satte rund 30% mehr an Daten über die Leitung und spart dadurch natürlich auch entsprechend viel Zeit beim Kopieren.
Als Beispiel ein rsync Befehl, den ich in so einem Fall immer verwende:


rsync -aPHxz --delete -e 'ssh -c arcfour' root@:/foo/bar/* /foo/bar/

Wem das immer noch nicht reicht, der kann zusätzlich auch noch einen anderen ‘message authentication code’ angeben über den Parameter: ‘-m hmac-md5-96″

Stefan Gundel
Stefan Gundel
Senior Systems Engineer

Stefan ist ein Urgestein bei NETWAYS und arbeitet im Managed Services Team. Der internationale Durchbruch gelang Stefan als Fotomodel für den K+K Warenkorb. Nachdem er einige Jahre exklusiv für unseren Kunden StayFriends gearbeitet hat, darf er nun endlich auch wieder in anderen Projekten mitarbeiten.

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
Senior 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.