Zugschlusbeobachtungen

So, nachdem ich die letzte Woche mit "Voraussetzungen aufbauen" verbracht habe, und wegen Zeitmangel am Wochenende sogar einen vorbereiteten Füller-Artikel posten musste, kommen wir heute (endlich) zu dem, was ich eigentlich mit Euch diskutieren wollte. Zu diesem Artikel sind mir Eure Kommentare besonders wichtig; ich weiß aber, dass es nach dem Absenden eines Kommentars im Browser einen Timeout hagelt. Das ändert aber nichts dran, dass der Kommentar ordentlich gepostet wurde.

Heute soll es nun endlich darum gehen, wie man Konfigurationsarbeiten ermöglicht und unterstützt, bei denen sich derjenige, der die Arbeiten ausführt, aktiv auf den zu bearbeitenden Systemen einlogged. Dabei schließe ich ausdrücklich das manuelle Arbeiten mit ssh oder mehrfach-ssh wie mssh und cssh ein, meine aber auch semiautomatisierte Arbeiten wie xargs --max-procs oder parallel(1) bis hin zum vollautomatischen Prozess, z.B. mit Ansible.

Auf meinen Systemen bin ich im wesentlichen der einzige Shell-Benutzer. Die hier vorgeschlagenen Methoden können natürlich auch auf eine größere Menge von Accounts angewendet werden, wobei ab einer gewissen Grenze manche Verfahren nicht mehr skalieren.

lokaler Login

Lokaler Login auf der Konsole ist bei meiner Arbeitsweise die Ausnahme. Das passiert im Wesentlichen nur bei Störungen, wenn Netz und/oder ssh nicht mehr funktionieren. Die bei weitem häufigste Methode des Zugriffs auf die Shell erfolgt via ssh über das Netz. Da ich auf meinen Systemen natürlich sudo-berechtigt bin, benötige ich das zum Account gehörende Passwort (außer zum Konsolen-Login im Störungsfall) nur, um mich bei sudo zu authentifizieren um root werden zu können.

Es war vor einigen Jahren, auf einem Treffen der SAGE Karlsruhe, wo im Rahmen eines Lightning Talks ssh proxycommand vorgestellt wurde. Ich hatte mich bisher immer mit einzelnen ssh-Aufrufen von Host zu Host weitergehangelt, und ssh proxycommand war für mich damals der erste Weg, direkt mit einem "natürlich" erscheindenen ssh-Aufruf trotz Sprunghost-Zwang auf dem Zielsystemen zu landen.

Das Verfahren wurde in neueren OpenSSH-Versionen noch zweimal vereinfacht, und in diesem Artikel möchte ich die Unterschiede herausstellen.

Oftmals hat man die Aufgabe, einen maschinenübergreifenden Zugriff automatisiert stattfinden zu lassen, ohne dass man der einen Seite gleich "vollwertige" Credentials für einen interaktiven Login auf der anderen Seite geben möchte. Wenn der Zugriff automatisiert stattfinden soll, fällt auch noch die Sicherheitsstufe eines ssh passphrases weg, da niemand da ist um diesen einzugeben.

ssh forced commands bieten eine Möglichkeit, einen solchen Zugriff zu erlauben, ohne gleich die Büchse der Pandora zu öffnen. Selbst ein automatischer Zugriff mit root-Rechten ist auf diese Weise "reasonably secure" realisierbar.

Yes, You Should Not discard cached ssh host keys without looking. An unexpected change of an ssh host key is always a reason to step back from the keyboard and think. However, there are situations when you know that a systems' ssh host key has changed, for example when the system reachable under this host name has been redeployed, which happens increasingly often proportionally to the devopsness of your environment, or for example in test environments.

Later versions of ssh offer you the ssh-keygen -R command line to paste from the error message, so that you can abort the connection attempt, paste the command and reconnect again. This will still ask for confirmation of the new host key though.

Almost every sysadmin has an alias or wrapper to make handling of this situation easier. Solutions range from using "StrictHostKeyChecking no" and/or "UserKnownHostsFile /dev/null", turning off this layer of securit altogether either globally or usually too broadly, to more-or-less sophisticated solutions that involve turning off know-host file hashing, parsing client output and/or grep-sed-awk magic. grml even comes with an insecssh script that is rather neat and that I used until I developed my own.

Starting with OpenSSH 7.2, a new "restrict" option for authorized_keys lines has become available. It sets all available restrictions that the current OpenSSH version can do (like no-agent-forwarding, no-x11-forwarding etc). One can individually turn on those features again by corresponding new options.

This saves one from sorrows when a new capability of OpenSSH is introduced through an update which is enabled by default, since one has to remember that restricted authorized_keys lines are in unse and then to manually add the restrictions.

On the downside, Debian jessie and CentOS 7 don't have a recent enough OpenSSH. So we'll have to continue worrying about new features being inadvertendly enabled for a while.

P.S.: Yes, I haven't blogged about Linux and Debian in English in a while.

In HP ProCurve und ssh habe ich dokumentiert, wie man einem ProCurve-Switch beibringen kann, per ssh zum Management erreichbar zu sein. Leider wird "ssh manger@switch <command>" nicht unterstützt, so dass man Expect braucht, um den Switch zu bedienen.

Nun sind TCL und ich nicht gerade die allerbesten Freunde, und ich erinnere mich mit Schaudern daran, wie ich vor Jahren den Status eines Infortrend-RAIDs mit Expect aus der seriellen Schnittstelle herausgekitzelt habe, um über den Nagios Alarm zu schlagen, wenn eine Platte ausfällt. Also machen wir's diesmal in Perl.

Noch schwerer wird's, wenn man die Ausgabe des Switches weiterverarbeiten möchte: Denn das, was aus dem Expect herausfällt, ist voller Steuerzeichen. Hier hilft Term::VT102, ein Perl-Modul, das im Speicher ein VT102-Terminal simuliert, dessen Bildschirm man nach Abschluß der geplanten Aktion auslesen kann. Das habe ich mit einem Scroll-Hook gelöst, der die Daten, die aus dem virtuellen Terminal herausscrollen, in ein Array schreibt. Zum Schluß werden dann einfach genug CRs in das Terminal gekippt, dass auch die letzte Bildschirmseite in unserem Array gelandet ist.

Um die Eigenheiten des Switches zu Umschiffen und sicherzustellen, dass die Daten trotzdem lesbar sind, muss man dem VT102 noch Teile der Cursorbewegung abgewöhnen: Der Switch positioniert den Cursor oft hart, und das terminal kommt dabei durcheinander, wenn die im Switch eingestellte Terminalgröße nicht richtig ist.

Das hier muss man in einen ProCurve-Switch reinpasten, damit er danach per ssh konfigurierbar ist:

ip ssh key-size 1024
crypto key generate ssh rsa
ip ssh version 2
ip ssh
aaa authentication ssh login public-key none
aaa authentication ssh enable public-key none
copy tftp pub-key-file <server-address> <file-name.pub> manager

Falle Nummer Eins: Der Kommentar zum Public Key darf kein Leerzeichen enthalten

Falle Nummer Zwei: Auch per ssh nimmt der Switch keine Kommandos auf der Kommandozeile entgegen, "ssh manager@switch show running-config" kann man also leider knicken. Man muss sich dann doch mit expect einen abbrechen, muss aber immerhin keine Klartextpassworte hinterlegen. Aber der passphraselose Key gibt natürlich trotzdem die volle Kontrolle über den Switch.

Wer einen Server in einschlägig bekannten Netzwerksegmenten (sprich: Bei den großen Housing-Anbietern) betreibt und wenigstens von Zeit zu Zeit mal in dessen Logs guckt kennt es: Irgendwelche Rechner aus Fernost oder anderswo werfen dem ssh-Daemon wild zusammengewürfelte Kombinationen aus Username und Passwort zu und tun dies mit einer bemerkenswerten Persistenz. Und wenn man auf dem System "fremde" User hat, lebt man als Admin stets mit der Angst, dass einer der Versuche der Angreifer irgendwann mal Erfolg hat.

Gegen diesen Typ der Brute-Force-Angriffe sind einige Wässerchen gewachsen, und ich möchte eine kleine Auswahl davon in diesem Artikel vorstellen.

Steve Friedl hat mal wieder einen exzellenten Artikel geschrieben, diesmal darüber, wie man von einem Windows-Rechner per ssh auf einen unixoiden Server zugreifen kann. Das ganze ist auf Windows-Level geschrieben, mit vielen Screenshots etc.

Ein anderer Artikel von ihm zum Thema "SSH Agent Forwarding" findet sich ebenfalls.

Selbst ausprobiert hab ich die Anleitung nicht, da ich selbst einen openssh-Client im rxvt von cygwin verwende, wenn ich mit Geld dazu gezwungen werde, mit einem Windows-Arbeitsplatz zu arbeiten.