Zugschlusbeobachtungen

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.

Continue reading "Meine Best Practice für Shell-Accounts und ihre Absicherung (mit ssh)"

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"

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"

Admintipp des Tages: Willst Du /var umounten, sieh zu, dass Du eine root-Shell offen oder das wirkliche root-Passwort parat hast. sudo wird Dich ohne /var nicht wirklich mögen, und der verbleibende Lichtblick ist der, dass Dein MTA die "security warning" ohne /var auch nicht wird verschicken können.