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.

Wenn man sich die Konfiguration seiner Systeme (managed systems) von einem Automaten (Konfigurationsmanagement-System, KMS) abnehmen lassen möchte, muss man ihm dazu die notwendigen Rechte geben. Da beißt die Maus keinen Faden ab.

Aber was sind die notwendigen Rechte, wie gibt man sie dem Automaten, und welche Implikationen für die Systemsicherheit (im Sinne von security) haben sie?

In diesem Artikel und seinen weiteren Teilen stelle ich ein paar Methoden vor, versuche ihre Vor- und Nachteile herauszuarbeiten und bitte euch um Kommentare und eure Meinung dazu. Dieser Teil 1 beschäftigt sich mit dem, dem ich eigentlich nur einen Absatz widmen wollte, und aus dem dann ein eigener Artikel geworden ist: Dem Pull-Prinzip mit einem Agenten.

Linux Weekly News hat vor ein paar Jahren eine Artikelreihe über Namespaces im Linux-Kernel veröffentlicht. Inzwischen gibt es da zwar eine gewisse Überdeckung zu den Manpages (z.B. man 7 namespaces), aber etwas ausführlicher ist LWN dennoch. Ich verblogge das hier, damit ich nicht immer wieder suchen muss.

Und ja, ich bin noch da. Im Moment leider wieder etwas seltener, da ich aufgrund familärer Verpflichtungen höchster Wichtigkeit tausende von Kilometern im ICE herunterreißen muss.

Über seinen Shellprompt hat wohl jeder Unix-Geek schon geschrieben. In diesem Artikel mache ich das auch mal.

Meiner sieht im Default so aus:

[1/4998]mh@swivel:~ $ 

Langweilig, nicht? Das habe ich absichtlich so gemacht, denn von Zeit zu Zeit muss ich mir einen Account mit anderen Leuten teilen, und da hat man sowieso nicht die Möglichkeit, zu individualisieren. Deswegen weiche ich hier wie auch in anderen Bereichen so wenig wie möglich vom Default ab. Das ist auch der Grund, warum ich die bash als Shell verwende und keine luxuriöseren Dinge wie z.B. die zsh: Die hat man im Zweifel dort, wo man unter Streß arbeiten muss, nicht zur Verfügung und hat genau dort dann einen ganzen Sack von Features, an deren Vorhandensein man sich selbstverständlich gewöhnt hat, nicht zur Verfügung.

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.

Alle Leute sagen, btrfs sei die Zukunft. Es gibt Leute, die einen schon mitleidig angucken, wenn man ihnen sagt, dass man immer noch ext4 einsetzt, wie ich das tue. Aber ich hatte neulich einen Grund, btrfs auszuprobieren. Mit btrfs kann man nämlich Snapshots innerhalb einer verschlüsselten LV einsetzen. Mit ext4 muss man vom Cryptodevice einen Snapshot machen und dann den Snapshot gesondert aufschließen. Damit ist schroot derzeit noch überfordert (#639105).

Also habe ich mal btrfs ausprobiert und musste feststellen, dass es mindestens beim Anlegen eines chroot massiv langsamer ist als ext4. Hier meine Messergebnisse für das Anlegen eines sid-chroot mit debootstrap mit und ohne eatmydata:

Ich muss sagen, ich bin entsetzt. Sowohl darüber, dass btrfs so viel langsamer ist, als auch darüber, dass eatmydata so gut wie nix bringt. Habe ich etwas falsch gemacht? Braucht btrfs beim Erstellen des Dateisystems bzw. beim Einhängen desselben irgend eine magische Option, um in die gleiche Performanceregion wie ext4 zu kommen?

Testumgebung war Debian GNU/Linux sid auf einer KVM VM.

Im Jahr 1999 habe ich im Rahmen meiner Diplomarbeit ein Framework entwickelt, das flexibel und leistungsfähig die Erstellung von - damals noch - ipfwadm-basierten Firewalls erlaubte. Irgendwann wurde es dann auf iptables aktualisiert und war insgesamt zwölf Jahre lang in zahlreichen Installationen im produktiven Betrieb.

Eben habe ich die letzten zwei Instanzen abgeschaltet. Und ich bin froh darüber.

Dear Lazyweb, for a long time I have been using iproute2's label feature to assign arbitrary labels to IP addresses configured on Interfaces:

40: int152@dotqa: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc noqueue state UP
link/ether 00:25:b3:01:e5:6c brd ff:ff:ff:ff:ff:ff
inet 10.1.152.254/24 brd 10.1.152.255 scope global int152:98fe8

Recently, this has shown to at least confuse both isc-dhcp-relay (#617258) and dhcp-helper (#617264).

As I have never seen interfaces labels used outside my firewalls (which happen to use ifupdown-scripts-zg2 (Debian PTS)) and ifupdown's rather twisted handling of multiple IP addresses per interface (using Alias Interfaces), I'd like to know whether my usage is a legitimate one and whether there are other uses for interface labels.

At the moment, I'm tempted to remove label support from ifupdown-scripts-zg2 in the next release, or to make it optional. Please comment if you have an opinion.

In the last few days, I found the time to spend some with KVM and libvirt. Unfortunately, there is a subject that I haven't yet found a satisfying solution: Naming of block devices in guest instances.

This is surely a common issue, but solutions are rare. Neither an article on Usenet (in German) nor the German version of this blog article has found solutions for the main question. I should have written this in English in the first place and am thus translating from German to english, hoping that there will be some answers and suggestions.

KVM is quite inflexible when it coms to configure block devices. It is possible to define on the host, which files or whole devices from the host should be visible in the guest. The documentation suggests that devices should be brought into the guest with the virtio model, which needs suppport in the guest kernel. Importing a device as emulated ATA or SCSI device brings a performance penalty.

The devices brought into the guest via virtio appear in the guest's dev as /dev/vd<x> and do also have their corresponding entries in /dev/disk/by-uuid and /dev/disk/by-path. The vd<x> node is simply numbered in consecutive order as hd<x> and sd<x>. /dev/disk/by-uuid is the correct UUID of the file system found on the device, at least if it's a block device partitioned inside the guest and formatted with ext3 (I didn't try anything else yet). The terminology of the /dev/disk/by-path node is not yet understood, and I am somewhat reluctant to assume the PCI paths of emulated hardware as stable.

Linux policy routing is still incredibly painful if one wants to have more sophisticated routing than just "take source and destination IP address for the routing decision". The mechanisms that have been in use seven years ago still work though, and I didn't find any possibility to do it any easier. In this article, I'll try to explain the "old" mechanisms and hope that somebody from lazyweb will comment and say "it can be done so much easier".

This is a translation of the Usenet article <gu48cs$rul$1@news1.tnib.de> in de.comp.os.unix.networking.misc in the hope that the english-speaking blogosphere can give additional insights.

I haven't been using ATM on Linux for some six years now. I neither have access to an ATM network any more nor do I have ATM hardware any more. Therefore, I plan to remove ATM support from ifupdown-scripts-zg2 in the next release which will be done in the next few weeks.

If anybody does still use ATM on Linux in conjunction with my scripts, you might want to offer help with the package if you want to have continued ATM support in ifdown-scripts-zg2. I cannot test the code any more and therefore cannot maintain it in the future.

In the last few weeks, I spent quite some time wondering about how to arrange the hard disk layout of my productive systems in the future. This article outlines my thoughts and would like to ask the lazyweb for comments.

I try to keep my Debian servers as identically as possible, making it possible to talk non-linux persons remotely through the system without having to worry about this particular box' configuration.