seeseekey.net - Invictus Deus Ex Machina

Von Zeit zu Zeit laufen Zertifikate ab. So auch in meinem Fall, als sich mein XMPP Client beschwerte, das dass Server-Zertifikat nicht mehr gültig ist. Um für ejabberd neue Zertifikate zu erzeugen, sollte man sich auf seinem Server einloggen und dort folgenden Zeilen eingeben:

openssl req -newkey rsa:2048 -keyout ejabberd.pem -nodes -x509 -days 365 -out ejabberd.cer
cat ejabberd.cer >> ejabberd.pem
cp ejabberd.pem /etc/ejabberd/ejabberd.pem

Anschließend kann der Dienst mittels:

service ejabberd restart

neugestartet werden. Das neue Zertifikat ist damit aktiv und der Dienst kann wieder genutzt werden.

Wenn man sich für seinen SSH Zugang nur noch mit einem entsprechenden Schlüsselpaar anmeldet, kann man die Authentifikation per Passwort deaktivieren. Dazu wird die „/etc/ssh/sshd_config“-Datei in einem Editor geöffnet:

nano /etc/ssh/sshd_config

Dort wird die Option:

# Change to no to disable tunnelled clear text passwords
#PasswordAuthentication yes

gesucht und in:

# Change to no to disable tunnelled clear text passwords
PasswordAuthentication no

geändert. Anschließend muss der SSH Server mittels:

service ssh restart

neugestartet werden. Damit ist die Anmeldung per Passwort nicht mehr möglich und der Server ein Stück sicherer.

Wenn man beim Zugriff mittels SSH unter Mac OS X folgende Meldung bekommt:

@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@
@         WARNING: UNPROTECTED PRIVATE KEY FILE!          @
@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@
Permissions 0644 for '/Users/seeseekey/.ssh/id_rsa' are too open.

weißt das auf ein Problem mit den Zugriffsrechten hin. In diesem Fall sind die Rechte für den privaten Schlüssel zu großzügig vergeben. Dies kann unter anderem dann passieren wenn man ein Backup einspielt. Um dieses Problem zu beheben, gibt man im Terminal folgendes ein:

sudo chmod 600 ~/.ssh/id_rsa
sudo chmod 600 ~/.ssh/id_rsa.pub

Damit sind die Zugriffsrechte für diese Dateien restriktiv gesetzt, so das SSH an dieser Stelle wieder problemlos funktioniert.

Wenn man das Backuptool Duplicity unter Ubuntu installiert, scheinen nicht alle Abhängigkeiten mitinstalliert zu werden. Das stellt man spätestens bei der ersten Benutzung fest:

BackendException: Could not initialize backend: No module named paramiko

Bei „paramiko“ handelt es sich um ein Python-Modul welches der Unterstützung des SSH2 Protokolls dient. Nachdem das ganze mittels:

apt-get install python-paramiko

nachinstalliert wurde, funktioniert auch Duplicity ohne weitere Probleme.

Wenn man einen Server betreibt ist ein Backup sehr praktisch. Viele Hoster bietet mittlerweile Backupspeicher an, auf welchen man seine Daten sichern kann. In diesem Artikel wird dabei davon ausgegangen das sich auf dem Server größere Imagedateien befinden, welche inkrementell gesichert werden sollen. Im ersten Schritt wird der Backupspeicher eingebunden. Viele Server lassen sich dabei mit SFTP ansprechen. Um dieses einzubinden muss das passende Paket installiert werden:

apt-get install sshfs

Danach erstellen wir einen Mountpunkt:

mkdir /mnt/backup

Anschließend kann das entfernte Dateisystem eingebunden werden:

sshfs nutzer@example.org:/ /mnt/backup

Für das Backup wird „rdiff-backup“ genutzt, welches über die Paketverwaltung installiert werden kann:

apt-get install rdiff-backup

Problematisch an „rdiff-backup“ ist die Tatsache, das dieses unter anderem mit Hardlinks arbeitet und diese bei SFTP unter Umständen nicht zur Verfügung stehen. Deshalb muss im ersten Schritt ein Image erzeugt werden und dieses eingebunden werden. Mittels:

rdiff-backup /etc/ /mnt/backup/etc/

kann dann anschließend das Backup angelegt werden. Möchte man ermitteln welche Backupversionen sich im Verzeichnis befinden, so kann dies durch

rdiff-backup -l /mnt/backup/etc/

bewerkstelligt werden. Damit man das ganze nicht immer per Hand erledigen muss (was bei Backups nicht ratsam wäre), habe ich das ganze in ein Skript gegossen welches auf GitHub zu finden ist.

Weitere Informationen gibt es unter:
http://wiki.ubuntuusers.de/FUSE/sshfs
http://www.nongnu.org/rdiff-backup/
http://www.thomas-krenn.com/de/wiki/Backup_unter_Linux_mit_rdiff-backup

Möchte man sich auf einem Linux-Server per SSH Schlüssel anmelden, so kopiert man im ersten Schritt seinen Schlüssel auf den entfernten Server:

ssh-copy-id -i ~/.ssh/id_rsa.pub ssh-nutzername@example.org

Anschließend kann man sich mittels:

ssh ssh-nutzername@example.org

ohne Passworteingabe auf den Rechner einloggen. Sollte dies nicht der Fall sein, gibt es ein Problem. So kann es passieren das man trotz SSH-Schlüssel ein Passwort eingeben soll. Um die Ursache zu diagnostizieren hilft es „ssh“ im Verbose-Modus zu benutzen:

ssh -v ssh-nutzername@example.org

Im diesem Modus werden viele Debuginformationen ausgegeben, welche helfen können das Problem einzugrenzen. Das man Passwörter trotz eines SSH Schlüssels eingeben muss, liegt manchmal an falsch konfigurierten Dateirechten im „.ssh“ Ordner auf dem entfernten Rechner. Die einfachste Möglichkeit ist es hier den Ordner komplett zu entfernen, damit er vom System nochmal angelegt wird. Dazu muss der Schlüssel natürlich mittels „ssh-copy-id“ wieder auf dem Rechner angebracht werden. Alternativ ist es auch möglich die Rechte für diesen Ordner neu zu setzen:

chmod 700 /home/seeseekey/.ssh/
chmod 600 /home/seeseekey/.ssh/authorized_keys

Wenn der Verbose-Modus nicht die gewünschten Ergebnisse bringt, so sollte sich die Logdatei /var/log/auth.log“ angeschaut werden. Dort kann man dann z.B. solche Meldungen bewundern:

Sep 21 01:47:35 service sshd[34221]: Authentication refused: bad ownership or modes for directory /home/seeseekey

In diesem Fall lag es nicht nur am „.ssh“ Verzeichnis, sondern auch an dem Homeverzeichnis des Nutzers. Ein:

chmod 700 /home/seeseekey/

wirkt in einem solchen Fall wahre Wunder. Danach sollte auch die Authentifikation per SSH-Schlüssel wieder funktionieren.

Wenn man PuTTY nutzt, wird man sich sicherlich das ein oder andere Mal über die seltsame Zeichen gewundert haben. Ein schönes Beispiel dafür ist der Midnight Commander, der anstatt mit der gewohnten Linienoptik mit ganz anderen Zeichnen arbeitet. Das Problem ist hier allerdings nicht beim Server zu finden. Stattdessen muss bei PuTTY gesucht werden.

Die PuTTY Optionen

Um das Problem zu beheben, sollte man in den Einstellungen unter „Window“ -> „Translation“ das „Remote character set“ auf UTF-8 stellen. Danach gehören die fehlerhaften Zeichen der Vergangenheit an.

Manchmal ändert sich die RSA Schlüssel für einen entfernten Server welchen man per SSH erreichen möchte. Dann bekommt man vom System eine schöne Meldung:

@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@
@    WARNING: REMOTE HOST IDENTIFICATION HAS CHANGED!     @
@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@
IT IS POSSIBLE THAT SOMEONE IS DOING SOMETHING NASTY!
Someone could be eavesdropping on you right now (man-in-the-middle attack)!
It is also possible that a host key has just been changed.

The fingerprint for the RSA key sent by the remote host is
3b:a3:48:fc:55:70:70:f8:43:33:50:73:d9:b8:1d:9e.

Please contact your system administrator.

Add correct host key in /Users/seeseekey/.ssh/known_hosts to get rid of this message.
Offending RSA key in /Users/seeseekey/.ssh/known_hosts:17
RSA host key for 8.8.8.8 has changed and you have requested strict checking.
Host key verification failed.

Das Problem besteht darin, das ein alter Fingerprint in der „known_hosts“-Datei vorhanden ist. Die brachiale Methode wäre es die Datei zu löschen. Damit wäre die Verbindung mit dem Server wieder möglich. Natürlich löscht man so auch alle anderen verifizierten Server (bzw. deren Fingerprints). Sauberer ist es den veralteten Key mittels „ssh-keygen“ zu entfernen:

ssh-keygen -R 8.8.8.8

Anschließend wird man beim nächsten Verbindungsversuch wieder gefragt ob man die Verbindung akzeptieren möchte. Ist dies der Fall kann sich mit dem Server verbunden werden.

Nachdem ich versuchte Git per WebDAV in Verbindung mit ownCloud einzurichten, fiel mir ein, das die größeren Paketen (ab Premium) bei all-inkl.com auch einen SSH Zugang beinhalten. Mit diesem ist es relativ einfach das Webhosting Paket als Server für Git Repositories zu benutzen. Sollte auf dem lokalen Rechner noch kein SSH-Schlüssel erzeugt worden sein, so kann dies mittels:

ssh-keygen -t rsa -C "seeseekey@example.org"

nachgeholt werden. Nun kann der Schlüssel an den all-inkl Server übertragen werden:

ssh-copy-id -i ~/.ssh/id_rsa.pub ssh-nutzername@example.org

Anschließend ist es möglich sich mit dem all-inkl SSH Server ohne Authentifikation über ein Passwort anzumelden:

ssh ssh-nutzername@example.org

Dort legen wir in dem Ordner in welchem unserer Git Repository landen soll ein leeres Repository an:

git init --bare

Als nächsten Schritt trägt man einen Remote an ein lokales Git Repository an:

git remote add origin ssh://ssh-nutzername@example.org/www/htdocs/nutzername/repos/Example.git

Danach kann das lokale Repository mit dem Befehl:

git push origin master

auf den entfernten Server kopiert werden. Benötigt man es auf einem anderen Rechner so kann das ganze mittels:

git clone ssh://ssh-nutzername@example.org/www/htdocs/nutzername/repos/Example.git

bewerkstelligt werden.