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.
Gestern hat Heise geschrieben, was die Communications Electronics Security Group (CESG), eine Abteilung des britischen Nachrichtendiensts GCHQ, empfiehlt, und was ich schon seit gefühlt 1847 predige: Der Zwang zur regelmäßigen Änderung von Passworten erweist der IT-Sicherheit nicht selten einen Bärendienst.
Nutzer, die einerseits zu immer komplexeren Passworten gezwungen werden, und diese andererseits dreimal in der Woche ändern müssen, neigen - für viele IT-Abteilungen völlig überrschend - dazu, diese Passworte aufzuschreiben, sie überall zu verwenden und sie bei erzwungenen Änderungen nur minimal zu ändern. So findet sich in meinen AD-Passwörtern diesen Monat die Zeichenkette 416, man darf raten woher sie kommt.
Ich bin ja ein großer Fan von Systemen, die den Benutzer für ein komplexes Passwort loben ("Dieses Passwort bekommt auf einer Skala von 1 bis 10 eine 8, wobei die Ähnlichkeit zum alten Passwort zur Abwertung geführt hat") und ihn vielleicht sogar dafür belohnen ("Dieses Passwort ist so herrlich komplex und unterscheidet sich so signifikant von Deinem alten Passwort, dass Du es jetzt 18 Monate behalten darfst"). Ich frage mich, warum sowas heutzutage so selten implementiert wird. Ich hab sowas zwar schonmal gesehen, aber das ist fünfzehn Jahre her, und seitdem nie wieder. Dabei ist diese Idee so nahe liegend.
Ach ja, das Blog gibt es noch. Ich plane seit Monaten, es auf einen neuen Server zu migrieren und dann auch wieder mit Inhalten zu bestücken. Nachdem wir jetzt auch schon bald zwei Jahre in unserem Haus leben, könnte ich langsam mal anfangen, die Baustellen-Highlights zu verbloggen.
I have just uploaded PowerDNS 3.3-1~exp1 to Debian experimental. This new upstream version has introduced its own include directive, so Debian was able to drop its patch. Hence, our conffiles had to grow a .conf extension, which most of them didn't have in previous version.
If anybody wants to test updates from PowerDNS 3.1 to the new 3.3-1~exp1 in Debian unstable, please go ahead and report bugs in the Debian BTS. The package is known to not offer seamless DNSSEC, I'll work on that before I upload to unstable.
While we're at it: I would appreciate help with the PostgreSQL backend. Myself, I use mainly MySQL and am not too proficient in PostgreSQL. I'll accept both patches and more formal co-maintenance.
Migrating a Debian installation between architectures has always been difficult. The recommended way to "crossgrade" an i386 Debian to amd64 Debian is to reinstall the system, move over data and configuration. For the more brave, in-place crossgrades usually involved chroots, rescue CDs, a lot of ar p | tar xf - data.tar.gz and luck.
I have never been brave when it comes to system administration, have done a lot of architecture migrations with reinstallation, and have always taken the opportunity to clear out the contamination that accumulates itself when a system is running for a long time. I would even recommend doing this to most people even now. However, I have a few very ugly systems in place that are still on i386 because I didn't dare going the reinstallation path.
Doing in-place crossgrades has become a lot easier since wheezy's release, since once now can have both i386 and amd64 libraries installed in parallel, which allows to replace foo:i386 with foo:amd64 without influencing the other parts of the system. The process is still full of pitfalls:
- In wheezy, many library packages are multiarch capable. This means that you can have those library packages installed for more than one architecture. This is a technical must for this way of crossgrade, so never use that for an older-than-wheezy system. It won't work, it needs at least Debian wheezy. Unfortunately, not all libraries in wheezy are multiarch capable. This makes the process harder and a lot less predictable, since a crosscrade including such packages is going to spew incomprehensible and misleading apt error messages. In my experience, for example the libaprutil-1-dbd-* packages and libonig2 are of this kind.
- apt removes a package before it reinstalls its new counterpart. This results in apt calling dpkg to remove dpkg, and then calling dpkg again to install dpkg. Guess which operation fails and the state of the system after this failure. Same applies to coreutils, which leaves the system without rm, which in turn dpkg of either architecture doesn't like. Using apt-get --download-only install to resolve dependencies and downloading the debs, followed by a traditional dpkg --install solves this issue since multiarch dpkg will replace a package with another one without deinstalling the first one first.
- At least for the process, you need a kernel that can run both 32bit and 64bit binaries for the i386 architecture. AFAIR, setting CONFIG_64BIT, CONFIG_X86_64 and CONFIG_IA32_EMULATION in the kernel configuration takes care of this.
- During the process, apt will temporary go into a badly broken state where it will refuse most operations. Be aware that you might need to manually download packages from the Internet. Be sure to have wget, curl, or a browser (maybe a text based one like elinks) available. dget is not going to help you here since it will only downloda packages for the native arch.
- During the process, apt wants to remove the better part of your system. It is important to not let it do this, as it wants to deinstall essential packages as well.
- Watch what your system does. During some steps, it might remove packages you might need. Keep track of the packages that were removed during the process and re-install them manually after finishing the crossgrade. Be sure not to purge packages that you might still need.
- It looks like the process is not always exactly reproducible. During the first tries, I found myself without an initrd at all, with an initrd that lacked the ext[234].ko kernel modules, without working e2fstools and in a number of other undesireable states of the system.
I have only tried this yet with a freshly installed minimal wheezy server system. Trying the process with "real life" systems has shown to be full of more surprises. I will document other pitfalls I have fallen into here at a later time. My minimal wheezy system was running in a KVM VM with its virtual disk as a LVM LV in the host system. I took a snapshot before beginning and used lvconvert --merge numerous time to return my LV to the original state. Be aware that lvconvert --merge removes the snapshot after merging it, so you'll need to re-create the snapshot before trying again.
The process is absolutely not for the faint of the heart, and intimate knowlegde of Debian mechanisms is required at many points in the process. Please seriously consider a reinstall+migrate approach instead of using this process, and be sure to practice it on a working copy of your system before touching the live system. And always have a backup.
During the process, I discussed things with Paul Tagliamonte, who has done this before, but on a live system and with a slightly more invasive approach. He has blogged about this. Thank you very much, your hints were very helpful.
Continue reading "How to amd64 an i386 Debian installation with multiarch"
Aufgabe: Transportiere Daten von einem Host auf den anderen über eine ssh-Verbindung. Dafür kann man scp oder sftp verwenden, wenn der eigene Account auf der anderen Seite die Daten lesen darf:
myuser@$TRGHOST$ scp $SRCHOST:$PATH/file .
Interessanter wird das dann, wenn die Daten auf der anderen Seite vom eigenen Account nicht gelesen werden können, man also erst einmal sudo bemühen muss, um die Daten lesen zu können. An dieser Stelle versagt scp bereits - es sei denn, man kann sich auf der anderen Seite als anderer User einloggen:
myuser@$TRGHOST$ scp $ANDERER_USER@$SRCHOST:$PATH/file .
Nur, das scheitert oft daran, dass man das Passwort von $ANDERER_USER nicht kennt, nicht neu setzen kann und/oder seinen ssh-Key nicht in $ANDERER_USER/.ssh/authorized_keys fallen lassen kann oder darf.
Continue reading "Daten mit Privilege Escalation abholen über eine named pipe"
Aus aktuellem Anlass hier ein aus den wegen dummer Software derzeit unerreichbaren "Zugschlus' manchmal nützlichen Antworten" schnell reingepasteter Artikel
Ungenaue Terminologie wird im Internet oft von Leuten verwendet, die
zwar ungefähr wissen, wie die Dinge funktionieren, sich aber nicht im
hinreichenden Maße mit den Hintergründen beschäftigt haben. Dies
erschwert die Kommunikation und ist oft dafür verantwortlich, dass ein
Auftragnehmer nicht das ausführt, was sein Auftraggeber eigentlich
möchte.
Ein besonders von diesem Problem geplagter Bereich der
Internet-Technik ist der Domain Name Service (DNS), da hier in
besonderem Maße die Kommunikation zwischen verschiedenen
Leistungsträgern in unterschiedlichen Unternehmen notwendig ist.
Mit diesem Text will ich versuchen, etwas Klarheit in die Terminologie
zu bringen.
Continue reading "Domain, Zone, Web- und Nameserver, Ägypten?"
