Zugschlusbeobachtungen

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.

Continue reading "Login als technischer User mit ssh forced commands"

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.

Continue reading "insecssh"

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.

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"

I just wanted to make an USB stick bootable and wondered why mkdiskimage -4 /dev/sda 0 32 64 complained about the disk having too many cylinders. After a few moments, it ocurred to me that since libata, the system hard disk has become sda and that the stick was sdb or sdc. One ctrl-C later, fdisk confirmed both counts: That I accidentally started mkdiskimaging my main system hard disk and that the partition table was already gone.

A few hours later, the notebook is back in business without too much data loss. Lucky me.

Continue reading "partition table gone, data still present"

Beim magentafarbenen UMTS/GPRS-Internet lautet der korrekte String für den APN "internet.t-mobile" und nicht "internet.t-mobile.de".

Trägt man den falschen APN ein, landet man in einem Netz, aus dem man surfen kann, aber sonst nichts: Außer TCP/80 und TCP/443 habe ich nichts gesehen was funktioniert hätte. Ich war schon ziemlich stinkig, wie Vendor T es wagen kann, sowas kastriertes als Internetzugang zu verkaufen, aber nach Korrektur des APN tat es dann auch mit OpenVPN, ssh und nntp.

Kernel 2.6.24.4 wurde gebaut und die fertigen Packages auf die Distributionen verteilt. torres, die als "testetch"-System neue Kernels als erstes stable-System bekommt, will sich die Package nicht automatisch ziehen.

Als ob das nicht schon genug Alarmsignal ist, sich das mal genauer anzugucken, prügle ich die Kernel-Package manuell rein und wunder mich, warum ein Haufen anderer Packages mitkommt und das System danach beginnt, eine initrd zu bauen.

Als ob das nicht schon genug Alarmsignal ist, boote ich die Kiste durch und wundere mich, warum sie nicht ins Netz kommt. Glücklicherweise ist torres nicht ohne Grund Testsystem der ersten Schicht: Sie hat eine serielle Konsole. Dort zeigt's mir, dass die Kiste sehr wohl läuft, aber kein Netz hat.

Da torres einen E100 hat, kann ich mir das nicht so wirklich vorstellen. Aber nein, da ist wirklich kein Interface in der Ausgabe von "ip addr". Aber in der Ausgabe von lspci ist es sehr wohl sichtbar.

Dann gucke ich mir zum ersten Mal /boot etwas genauer an.

Und sehe, dass ich einen Kernel, der eigentlich für mein notebook gedacht war, auf torres installiert habe. **tischkante beiss**

Als ob eins der oben genannten Alarmzeichen nicht gereicht hätte. An manchen Tagen sollte man mich echt nicht an Computer lassen.

Manchmal führt kein Weg an einem Flash vorbei. So zum Beispiel der Projektmanagement-Kurs, an dem ich derzeit teilnehmen darf. Nur, leider, bleibt die E-Learning-Vorbereitung unter Linux stumm.

Beim Versuch, die Flashpräsentation unter Windows in meiner VMware zum Laufen zu bringen, ist mir aufgefallen, dass VMware und das Flash-Plugin für den Firefox unter Linux beide dasselbe Problem haben: Sie verwenden OSS, während auf meinem Notebook schon seit längerer Zeit ALSA zum Einsatz kommt.

Abhilfe für Flash: aoss firefox schiebt zwischen das Flashplugin und den Soundtreiber einen Indirektionslayer, der das Flashplugin unter Linux plötzlich Geräusche machen lässt. Sehr fein.

Leider funktioniert das für VMware nicht: aoss basiert auf LD_PRELOAD, und LD_PRELOAD wird für suid-root-Binaries, wie der VMware Player eins ist, wohl ignoriert. Die Dokumente, die ich im Web finde, erwähnen die Problematik entweder gar nicht (das sind wohl die Leute, die ständig als root arbeiten) oder empfehlen, die libaoss.so auch suid root zu setzen. Das treibt mir allerdings den Angstschweiß auf die Stirn. Geht das noch anders? Oder finde ich mich damit ab, dass mein Windows bis auf weiteres stumm bleibt?

Wenn man

$ sudo rsync --archive --hard-links --exclude /dev --exclude /proc --exclude /sys --rsh=ssh / root@hostname.example:/mnt/hda1

tippt, gibt man - da man ja gerade vorher schonmal sudo gemacht hat - nur das ssh-Passwort der Gegenseite ein.

Da die Gegenseite komplett leer ist, dauert das dann eine Weile. Und weil man nach dem Ablauf des rsync sicherheitshalber den Befehl gleich nochmal absetzt, gibt man das Passwort er Gegenseite nochmal ein.

Um sich dann zu wundern, warum es nicht funktioniert.

Bis es einem dämmert, dass der Password:-Prompt gar nicht vom sshd kommt.

Sondern vom sudo.

Und man das Benutzerpasswort des lokalen Rechners braucht.

Continue reading "2006-10-14 - Admintipp des Tages"

Der VLAN-Beauftragte rät: Ja, hp ProCurve Switches 2650 haben für die Dual-Personality-Ports zwei Registersätze. Und nein, es ist deswegen nicht zielführend, zuerst den Port zu konfigurieren, dann den GBIC reinzustecken und das Ding so dann zum Kunden zu shippen. Weil, mit einem Port, der untagged im Default-VLAN ist, kann der Kunde nicht so viel anfangen.

Wenn man mit rsync ein Backup auf ein anderes System macht, das zwar ähnliche Accountnamen, aber keine identische Zuordnung zwischen Accountnamen und uid/gid hat, möchte man bei beiden rsync-Aufrufen (backup und restore) die Option --numeric-ids verwenden.

Das erspart einem böse Überraschungen beim Reboot nach dem Restore.

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.

Es ist generell ratsam, wenn man schon am packen ist, und den USB-Hub schon aus dem Notebook gezogen hat, das noch fällige Ende-Kommando an ein im Netz stehendes System nicht auf der soeben abgetrennten USB-Tastatur eintippen zu wollen.

Außerdem ist es empfehlenswert, bei Nichtreaktion der ssh-Session nicht gleich Zeter und Mordio auf den Billighoster zu schreien, sondern erstmal zu gucken, ob das Problem nicht viel lokaler liegt.

"Plötzlich einen anderen Hostnamen vorfinden, am besten noch einen, den es nicht auflösen kann". Dann sollte man besser eine rootshell offen haben oder das korrekte Root-Passwort parat haben, sonst war's das mit der Uptime.

Teil 1 und Teil 2 sind übrigens "/var umounten", respektive "/usr umounten".

Wenn Du /home umounten willst, achte darauf, dass Du beim "sudo -s" nicht in Deinem User-$HOME bist. Sonst hält die User-Shell das Dateisystem fest.

Ausserdem denke daran, dass Du bei einem glatten "sudo -s" deinen user-$PATH behältst, also auch der umount-Wrapper aktiv bleibt, den Du Dir gestrickt hast, um /media/usb oder /media/scy oder /media/pcmcia auch ohne Root-Rechte mounten zu können. Wenn dieser Wrapper dann auch noch in $HOME liegt, wirst Du /home nicht umounten können, und fuser und lsof werden Dir ständig sagen, das Filesystem sei busy.

Und Du wirst Dir einen Wolf suchen, weil zu dem Zeitpunkt, zu dem Du suchst, natürlich der umount-Wrapper nicht mehr offen ist und Du Dir deswegen nicht wirst erklären können, warum /home busy ist.