Zeit ist einzigartig


Einige haben erst am 12. Dezember 2012 gemerkt, dass die Zeit einzigartig ist. CAs hingegen wissen das schon seit Längerem und wissen dies auch effektiv zu nutzen. Bei meinem letzten Setup bin ich wieder über diese Falle gestolpert: Die Einrichtung der externen CA und des Puppetmasters ging wie immer ohne Probleme, nur jegliche Zertifikate wollten nicht akzeptiert werden. Wer Puppet einsetzt wird diese Fehlermeldung sofort erkennen:
err: Could not retrieve catalog from remote server: SSL_connect returned=1 errno=0 state=SSLv3 read server certificate B: certificate verify failed: [certificate signature failure for /CN=puppet ]
Wir können in diesem Fall zum einen prüfen, ob unsere CA die selbe ist.
Mit OpenSSL können Zertifikate lesbar dargestellt werden.
openssl x509 -text -noout -in /path/to/ssl/certs/ca.pem | grep Issuer
In dem Output sollte dann eine Zeile mit dem Issuer zu sehen sein und wenn dieser mit der Puppet CA nicht übereinstimmt, müssen deren Einstellungen überprüft werden. Dabei können diese Befehle hilfreich sein.
sudo puppet master --configprint certname
sudo puppet master --configprint ca
Sobald aber hier alles richtig konfiguriert wurde, ist es zum anderen gut ein Auge auf die Zeit zu werfen.
Wenn die Zeit nicht stimmt kann es dazu kommen, dass Zertifikate in der Zukunft ausgestellt werden und diese für die CA keine Gültigkeit besitzen.
Ein einheitlicher Zeitserver kommt diesem Problem entgegen, denn mit ihm vermeiden wir Zertifikate in der Zukunft auszustellen. Wenn dieser nicht vorhanden ist, reicht ein einfaches:
sudo apt-get install ntp
und eventuell ein kurzer Neustart. Danach muss der Puppet Agent neu signiert werden. Dazu müssen alle Zertifikate gelöscht werden.
Auf dem Puppetmaster:
sudo puppet cert clean yourserver.localdomain
Auf dem Client:
sudo rm -rf /path/to/puppet/ssl/*  #Default ist /var/lib/puppet/ssl/
Anschließend kann ein neuer Testlauf auf dem Agent ausgeführt werden, der dann ein neues Zertifikat generiert
sudo puppet agent --test
und durch den Puppetmaster validieren lässt.
sudo puppet cert sign yourserver.localdomain
P.S.: Achtet bei eurer Icinga2 HA Installation auch auf die Zeit, hier werden ebenfalls SSL Zertifikate benutzt und unterschiedliche Zeitserver können zu Zeitverschiebungen (im Projekt) führen. 😉

Thilo Wening
Thilo Wening
Senior Consultant

Thilo hat bei NETWAYS mit der Ausbildung zum Fachinformatiker, Schwerpunkt Systemadministration begonnen und unterstützt nun nach erfolgreich bestandener Prüfung tatkräftig die Kollegen im Consulting. In seiner Freizeit ist er athletisch in der Senkrechten unterwegs und stählt seine Muskeln beim Bouldern. Als richtiger Profi macht er das natürlich am liebsten in der Natur und geht nur noch in Ausnahmefällen in die Kletterhalle.

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.

Graphing mit Graphite: NETWAYS Webinar

Graphite ist eine Open Source Graphing Lösung, welche sich aufgrund der Flexibilität und Skalierbarkeit auf Augenhöhe mit vergleichbaren Enterprise Lösungen befindet.
Morgen, den 06. November 2013 um 14:00 Uhr, werden wir diese in unserem Webinar vorstellen.
Hier werden wir unter anderem auf das Webinterface, die Handhabung sowie die Architektur eingehen. Die Registrierung erfolgt wie immer über unser Webinar-Center.
Anschließend findet sich in unserem Webinar-Archiv sowie auf unserem YouTube-Channel das Webinar-Video sowie die Präsentationsfolien.
Übrigens: Bereits nächste Woche, am 13. November um 14:00 Uhr, findet unser erstes Webinar zu Icinga 2 statt. Also jetzt jetzt noch schnell registrieren!
Wir freuen uns auf eine rege Teilnahme!

Christian Stein
Christian Stein
Lead Senior Account Manager

Christian kommt ursprünglich aus der Personalberatungsbranche, wo er aber schon immer auf den IT Bereich spezialisiert war. Bei NETWAYS arbeitet er als Senior Sales Engineer und berät unsere Kunden in der vertrieblichen Phase rund um das Thema Monitoring. Gemeinsam mit Georg hat er sich Mitte 2012 auch an unserem Hardware-Shop "vergangen".