Schlagwort: alias

SSH Konfiguration: Privat, Arbeit, teilen mit Kollegen?!

prego Schreib einen Kommentar

Ich habe meine .ssh/config Datei mit den Einträgen die ich benötige. In dieser Datei habe ich Einträge für dienstliche Systeme aber auch private. Aus diesem Grund kann die Datei nicht einfach mit anderen Kollegen geteilt werden. Wie das dennoch erreicht werden kann, kurz und pragmatisch hier beschrieben:

Als allererstes muss ich die Konfigurationsdatei aufsplitten können in mehrere Teile. Also ein ~/.ssh/config.d/ Verzeichnis anstatt einer einzelnen Datei. SSH unterstützt das von Haus aus nicht, man kann sich aber an dieser Stelle eines Tricks bedienen: ein Alias für das Kommando „ssh“, das bei jedem Aufruf die .ssh/config einfach neu schreibt. Dafür die folgende Zeile in die .bash_aliases  eintragen:

alias ssh="cat ~/.ssh/config.d/* > ~/.ssh/config; ssh"

Als zweites gilt es nun die Dateien aufzuspalten. Ich persönlich pflege drei Dateien:

  1. general
  2. privat
  3. work

In der ersten Datei habe ich Optionen, die für alle Hosts gelten:

Host *
Compression             yes
CompressionLevel        9
ServerAliveInterval     30
#VisualHostKey          yes

In den anderen Dateien sind die Definitionen für die privaten und die Arbeitsrechner.

Der dritte Punkt ist der einfachste: Die Dateien einfach in ein Repository legen, symbolische Links aus dem Repository in das config.d Verzeichnis erzeugen und mit den Kollegen teilen.

Natürlich Backups zwischendrin etc. nicht vergessen ;-)

Puppet: Mailaliases erzeugen

prego Schreib einen Kommentar

Mir ist es immer wichtig, dass ich die Mails von meinen Servern bekomme. Dafuer habe ich logcheck installiert und einen Mailalias an den alles geschickt wird. Auch lasse ich mir die Mails an root immer an eine eigene Adresse weiterleiten.

Mit puppet kann man sicherstellen, dass Aliase existieren. Meine Klasse dafuer sieht wie folgt aus:

# make sure that the alias for root and logcheck is set correct
 
class aliases {
 
  file { '/etc/aliases' :
    mode  => '0644',
    owner => 'root',
    group => 'root',
  }
 
  mailalias { 'root' :
    name      => 'root',
    recipient => 'user@example.org',
    notify    => Exec['newaliases'],
  }
 
  mailalias { 'logcheck' :
    name      => 'logcheck',
    recipient => 'logcheckalias@example.org',
    notify    => Exec['newaliases'],
  }
 
 exec { 'newaliases':
    command     => '/usr/bin/newaliases',
    refreshonly => true,
    subscribe   => File['/etc/aliases'],
  }
}

Informationen zu dem „mailalias“ und dem „exec“ Type gibt es in der puppet Type Reference:

Mehr Sicherheit fuer die eigenen Daten – verschluesselter Container

prego Schreib einen Kommentar

Dieses ist der zweite Teil einer Serie von Blogeintraegen, die sich als Reaktion auf die NSA Affaere um den Kontext Sicherheit fuer die eigenen Daten und Verschluesselung drehen.

Der erste Teil war fuer mich das Aufraeumen, einen Ueberblick zu bekommen sowie Strukturen zu schaffen, auf denen ich aufbauen kann. Der zweite Teil, den ich hier beschreiben moechte, bestand darin einen Ort zu schaffen, in dem ich Keys und Passwoerter sicher aufbewahren und gleichzeitig alles in ein vernuenftiges Backup schieben kann.

Es gibt immer Dateien, die muss man sicherer aufbewahren als alle anderen. Das sind zum Beispiel die Keys fuer die Webserver Zertifikate, PGP oder vielleicht auch das ein oder andere Passwort was man sich notieren moechte. Ich habe mich dazu entschlossen das ganze in einer verschluesselten Containerdatei aufzubewahren. Diesen kann ich auch ruhigen Gewissens irgendwo in ein Backup schieben und die Daten liegen nicht frei lesbar herum.

Es war fuer mich wichtig das ganze moeglichst einfach zu halten und nicht so kompliziert in der taeglichen Bedienung. Aus diesem Grund habe ich noch zwei Skripte und Aliase drumherum gebaut, so das ich mit einem simplen Befehl und einem Passwort den Container einhaengen bzw. mit einem weiteren Befehl den Container auch wieder aushaengen kann. Der Reihe nach:

  1. Erzeugen einer 128MB grossen Containerdatei: 
    dd if=/dev/urandom of=mycrypt.file bs=1M count=128
  2. Die Datei an ein Loopback Device binden: 
    losetup -f
losetup /dev/loop0 mycrypt.file
  3. Initialisieren und Passwort festlegen: 
    cryptsetup -c aes-xts-plain -y -s 512 luksFormat /dev/loop0
  4. Oeffnen: 
    cryptsetup luksOpen /dev/loop0 mycryptcontainer
  5. Dateisystem erzeugen: 
    mkfs.ext4 /dev/mapper/mycryptcontainer

Jetzt kann man die Datei mounten und es als ganz normales Device nutzen:

mount -t ext4 /dev/mapper/mycryptcontainer /home/user/crypt

Wieder entfernt wird es mit den folgenden Befehlen:

umount /home/user/crypt
cryptsetup luksClose mycryptcontainer
losetup -d /dev/loop0

Das ganze soll ja aber einfach sein. Aus diesem Grund habe ich mir zwei Skripte angelegt:

  • /usr/local/sbin/mountContainer.sh
#!/bin/sh
 
SAFE=/home/user/Dokumente/mycrypt.file
CRYPTNAME=mycryptcontainer
MNT=/home/user/crypt
FS=ext4
LOOPDEV=$(losetup -f)
 
if [ "$(losetup -a | grep -c "$SAFE")" != "0" ]; then
        echo "bereits eingehängt"
        exit
fi
 
/sbin/losetup $LOOPDEV $SAFE
/sbin/cryptsetup luksOpen $LOOPDEV $CRYPTNAME
/bin/mount -t $FS /dev/mapper/$CRYPTNAME $MNT
  • /usr/local/sbin/umountContainer.sh
#!/bin/sh
 
SAFE=/home/user/Dokumente/mycrypt.file
CRYPTNAME=mycryptcontainer
MNT=/home/user/crypt
LOOPDEV=$(losetup -a | grep "$SAFE" | sed "s/: .*//")
 
if [ "$(losetup -a | grep -c "$SAFE")" != "1" ]; then 
	echo "nicht eingehängt"
	exit
fi
 
/bin/umount $MNT
/sbin/cryptsetup luksClose $CRYPTNAME
/sbin/losetup -d $LOOPDEV

Nicht vergessen sie ausfuehrbar zu machen:

chmod 750 /usr/local/sbin/*mountContainer.sh

Da die Skripte mit root rechten aufgerufen werden muessen habe ich mir weiter die folgende Datei erzeugt:

  • /etc/sudoers.d/90_mycryptcontainer
user     host = NOPASSWD: /usr/local/sbin/mountContainer.sh
user     host = NOPASSWD: /usr/local/sbin/umountContainer.sh

und noch die Rechte dafuer setzen:

chown root.root /etc/sudoers.d/90_mycryptcontainer
chmod 0440 /etc/sudoers.d/90_mycryptcontainer

Zu guter Letzt noch zwei Aliase in meiner ~/.bash_aliases angelegt und voilà:

alias mcrypt='/usr/bin/sudo /usr/local/sbin/mountContainer.sh'
alias umcrypt='/usr/bin/sudo /usr/local/sbin/umountContainer.sh'

Jetzt kann ich mit den Befehlen mcrypt und umcrypt den Container ein- und aushaengen und kann vor allem die verschluesselte Containerdatei ruhigen Gewissens ins Backup packen.

Die hier beschriebenen Schritte stammen groesstenteils aus dem Wikieintrag Containerdatei von ubuntuusers.de.

Howto: Backupmailbox – ein Kochrezept

prego Schreib einen Kommentar

Das Problem: ein Backup von wenigen aber wichtigen kleinen Dateien von einem Server machen, aber irgendwie keine Zeit den eigentlichen Backup-Client einzurichten. Sowieso ist in diesem Fall der Backup-Client auf dem Server eigentlich ein bisschen wie mit Kanonen auf Spatzen zu schiessen. Backup muss aber dennoch gemacht werden.

Die Loesung: die Backupmailbox. Auf dem Mailserver wird eine Backup-Aliasmailadresse eingerichtet. Backups gehen dann per Mail an diese Adresse, ein Skript extrahiert die Anhaenge und legt sie im Dateisystem in einer Ordnerstruktur ab. Diese Ordner werden dann ueber den Backupclient – der auf dem Mailserver sowieso laeuft – mit ins regulaere Backup geschoben. Die Anhaenge werden in Unterordner gespeichert, die dem Namen der EMailadresse entsprechen um sie besser auseinanderzuhalten. Dabei wird das @ gegen einen . ersetzt. Weiter werden nur Emails bearbeitet, die als Betreff ein definiertes Zufallspasswort haben.

Die Umsetzung: Man benoetigt einen Email-Alias, ein Skript, zwei Ordner im Dateisystem, ein Zufallspasswort und 15min Zeit eines Systemadministrators.

Zuerst lege man in der /etc/aliases einen neuen Backup-Alias an:

backupalias: "| /path/to/attatchExtract.sh"

und uebernehme diesen mit dem Kommando newaliases. Danach lege man unter dem definierten Pfad das folgende Skript ab:

#!/bin/bash
 
## base path where attachments and logfile should be stored without trailing slash
BASEPATH=/var/local/backup/
 
 
## The subject needs to match this string, otherwise the mail is dropped without action
SECRETSUBJECT="12345"
 
 
## uniq filename for temp file
FILENAME=$(date +%s)
echo "Filename = $FILENAME" >> $BASEPATH/logfile
 
 
## safe email to tmp file
/bin/cat > /tmp/$FILENAME
 
 
## extract sender from email
SENDER=$(grep "From:" /tmp/$FILENAME | sed 's/.*< *//;s/ *>.*//' | tr "@" ".")
echo "Sender = $SENDER" >> $BASEPATH/logfile
 
 
## extract subject from email
SUBJECT=$(grep "Subject:" /tmp/$FILENAME | sed '/^Subject: */!d; s///; q')
echo "Subject = $SUBJECT" >> $BASEPATH/logfile
 
 
## only do something if secret subject is matched
if [ "$SUBJECT" == "$SECRETSUBJECT" ]; then
 
 
  ## create folder for email address if doesn't exist
  if [ ! -d "$BASEPATH/$SENDER" ] ; then
    echo "Directory $BASEPATH/$SENDER does not exist, creating it" >> $BASEPATH/logfile
    mkdir -p $BASEPATH/$SENDER
  fi
 
 
  ## extract files from email and safe to correcet folder
  /usr/bin/uudeview -i -a -p $BASEPATH/$SENDER/ /tmp/$FILENAME >> $BASEPATH/logfile
  echo >> /$BASEPATH/logfile
 
 
## otherwise just do nothing
else
  echo "Subject didn't match secret Subject. Doing nothing..." >> $BASEPATH/logfile
fi
 
 
## delete tmp file
/bin/rm /tmp/$FILENAME

In dem Skript passe man nun das Zufallspasswort gegen ein eigenes an (makepasswd –chars 40) und aktualisiere den BASEPATH. Zuletzt noch das Skript mit chmod 755 ausfuehrbar machen und das Ergebnis aus dem Mailclient seiner Wahl testen.

Sollte es zu Problemen kommen, dass keine Logdatei und Anhaenge abgelegt werden liegt dieses meistens an fehlenden Rechten.