seeseekey.net - Invictus Deus Ex Machina

Wenn man das Back­up­t­ool Dup­li­city unter Ubuntu instal­liert, schei­nen nicht alle Abhän­gig­kei­ten mit­in­stal­liert zu wer­den. Das stellt man spä­tes­tens bei der ers­ten Benut­zung fest:

BackendException: Could not initialize backend: No module named paramiko

Bei „para­miko“ han­delt es sich um ein Python-Modul wel­ches der Unter­stüt­zung des SSH2 Pro­to­kolls dient. Nach­dem das ganze mittels:

apt-get install python-paramiko

nach­in­stal­liert wurde, funk­tio­niert auch Dup­li­city ohne wei­tere Probleme.

Wenn man einen Ser­ver betreibt ist ein Backup sehr prak­tisch. Viele Hos­ter bie­tet mitt­ler­weile Back­up­spei­cher an, auf wel­chen man seine Daten sichern kann. In die­sem Arti­kel wird dabei davon aus­ge­gan­gen das sich auf dem Ser­ver grö­ßere Image­da­teien befin­den, wel­che inkre­men­tell gesi­chert wer­den sol­len. Im ers­ten Schritt wird der Back­up­spei­cher ein­ge­bun­den. Viele Ser­ver las­sen sich dabei mit SFTP anspre­chen. Um die­ses ein­zu­bin­den muss das pas­sende Paket instal­liert werden:

apt-get install sshfs

Danach erstel­len wir einen Mountpunkt:

mkdir /mnt/backup

Anschlie­ßend kann das ent­fernte Datei­sys­tem ein­ge­bun­den werden:

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

Für das Backup wird „rdiff-backup“ genutzt, wel­ches über die Paket­ver­wal­tung instal­liert wer­den kann:

apt-get install rdiff-backup

Pro­ble­ma­tisch an „rdiff-backup“ ist die Tat­sa­che, das die­ses unter ande­rem mit Hard­links arbei­tet und diese bei SFTP unter Umstän­den nicht zur Ver­fü­gung ste­hen. Des­halb muss im ers­ten Schritt ein Image erzeugt wer­den und die­ses ein­ge­bun­den wer­den. Mittels:

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

kann dann anschlie­ßend das Backup ange­legt wer­den. Möchte man ermit­teln wel­che Back­up­ver­sio­nen sich im Ver­zeich­nis befin­den, so kann dies durch

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

bewerk­stel­ligt wer­den. Damit man das ganze nicht immer per Hand erle­di­gen muss (was bei Back­ups nicht rat­sam wäre), habe ich das ganze in ein Skript gegos­sen wel­ches auf Git­Hub zu fin­den ist.

Wei­tere Infor­ma­tio­nen 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üs­sel anmel­den, so kopiert man im ers­ten Schritt sei­nen Schlüs­sel auf den ent­fern­ten 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 Pass­wor­t­ein­gabe auf den Rech­ner ein­log­gen. Sollte dies nicht der Fall sein, gibt es ein Pro­blem. So kann es pas­sie­ren das man trotz SSH-Schlüssel ein Pass­wort ein­ge­ben soll. Um die Ursa­che zu dia­gnos­ti­zie­ren hilft es „ssh“ im Verbose-Modus zu benutzen:

ssh -v ssh-nutzername@example.org

Im die­sem Modus wer­den viele Debu­gin­for­ma­tio­nen aus­ge­ge­ben, wel­che hel­fen kön­nen das Pro­blem ein­zu­gren­zen. Das man Pass­wör­ter trotz eines SSH Schlüs­sels ein­ge­ben muss, liegt manch­mal an falsch kon­fi­gu­rier­ten Datei­rech­ten im „.ssh“ Ord­ner auf dem ent­fern­ten Rech­ner. Die ein­fachste Mög­lich­keit ist es hier den Ord­ner kom­plett zu ent­fer­nen, damit er vom Sys­tem noch­mal ange­legt wird. Dazu muss der Schlüs­sel natür­lich mit­tels „ssh-copy-id“ wie­der auf dem Rech­ner ange­bracht wer­den. Alter­na­tiv ist es auch mög­lich die Rechte für die­sen Ord­ner neu zu setzen:

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

Wenn der Verbose-Modus nicht die gewünsch­ten Ergeb­nisse bringt, so sollte sich die Log­da­tei /var/log/auth.log“ ange­schaut wer­den. Dort kann man dann z.B. sol­che Mel­dun­gen bewundern:

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

In die­sem Fall lag es nicht nur am „.ssh“ Ver­zeich­nis, son­dern auch an dem Home­ver­zeich­nis des Nut­zers. Ein:

chmod 700 /home/seeseekey/

wirkt in einem sol­chen Fall wahre Wun­der. Danach sollte auch die Authen­ti­fi­ka­tion per SSH-Schlüssel wie­der funktionieren.

Wenn man PuTTY nutzt, wird man sich sicher­lich das ein oder andere Mal über die selt­same Zei­chen gewun­dert haben. Ein schö­nes Bei­spiel dafür ist der Mid­night Com­man­der, der anstatt mit der gewohn­ten Lini­en­op­tik mit ganz ande­ren Zeich­nen arbei­tet. Das Pro­blem ist hier aller­dings nicht beim Ser­ver zu fin­den. Statt­des­sen muss bei PuTTY gesucht werden.

Die PuTTY Optionen

Um das Pro­blem zu behe­ben, sollte man in den Ein­stel­lun­gen unter „Win­dow“ -> „Trans­la­tion“ das „Remote cha­rac­ter set“ auf UTF-8 stel­len. Danach gehö­ren die feh­ler­haf­ten Zei­chen der Ver­gan­gen­heit an.

Manch­mal ändert sich die RSA Schlüs­sel für einen ent­fern­ten Ser­ver wel­chen man per SSH errei­chen möchte. Dann bekommt man vom Sys­tem 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 Pro­blem besteht darin, das ein alter Fin­ger­print in der „known_hosts“-Datei vor­han­den ist. Die bra­chiale Methode wäre es die Datei zu löschen. Damit wäre die Ver­bin­dung mit dem Ser­ver wie­der mög­lich. Natür­lich löscht man so auch alle ande­ren veri­fi­zier­ten Ser­ver (bzw. deren Fin­ger­prints). Sau­be­rer ist es den ver­al­te­ten Key mit­tels „ssh-keygen“ zu entfernen:

ssh-keygen -R 8.8.8.8

Anschlie­ßend wird man beim nächs­ten Ver­bin­dungs­ver­such wie­der gefragt ob man die Ver­bin­dung akzep­tie­ren möchte. Ist dies der Fall kann sich mit dem Ser­ver ver­bun­den werden.

Nach­dem ich ver­suchte Git per Web­DAV in Ver­bin­dung mit own­Cloud ein­zu­rich­ten, fiel mir ein, das die grö­ße­ren Pake­ten (ab Pre­mium) bei all-inkl.com auch einen SSH Zugang beinhal­ten. Mit die­sem ist es rela­tiv ein­fach das Web­hos­ting Paket als Ser­ver für Git Repo­si­to­ries zu benut­zen. Sollte auf dem loka­len Rech­ner noch kein SSH-Schlüssel erzeugt wor­den sein, so kann dies mittels:

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

nach­ge­holt wer­den. Nun kann der Schlüs­sel an den all-inkl Ser­ver über­tra­gen werden:

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

Anschlie­ßend ist es mög­lich sich mit dem all-inkl SSH Ser­ver ohne Authen­ti­fi­ka­tion über ein Pass­wort anzumelden:

ssh ssh-nutzername@example.org

Dort legen wir in dem Ord­ner in wel­chem unse­rer Git Repo­sitory lan­den soll ein lee­res Repo­sitory an:

git init --bare

Als nächs­ten Schritt trägt man einen Remote an ein loka­les Git Repo­sitory an:

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

Danach kann das lokale Repo­sitory mit dem Befehl:

git push origin master

auf den ent­fern­ten Ser­ver kopiert wer­den. Benö­tigt man es auf einem ande­ren Rech­ner so kann das ganze mittels:

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

bewerk­stel­ligt werden.

Manch­mal benö­tigt man unter Linux einen Nut­zer, möchte aber das die­ser keine Shell zuge­wie­sen bekommt und sich somit nicht anmel­den kann. Dies kann unter ande­rem mit dem Befehl „addu­ser“ bewerk­stel­ligt werden:

adduser seeseekey --no-create-home --shell /bin/false

Damit legt man einen Nut­zer an, wel­cher sich nicht anmel­den kann, aber durch­aus für die Authen­ti­fi­zie­rung über das Nut­zer­sys­tem z.B. bei bestimm­ten Netz­werk­diens­ten taugt. Dane­ben wird auch gleich ver­hin­dert, dass der Nut­zer einen „home“-Ordner bekommt.

Möchte man den pri­va­ten SSH Schlüs­sel wel­cher mit­tels des „PuTTY Key Gene­ra­tor“ erzeugt wurde auch in der „Git Bash“ nut­zen, so muss man den Schlüs­sel in das OpenSSH For­mat bringen.

Der PuTTY Key Generator

Dazu öff­net man den PuTTY Schlüs­sel mit­tels „File“ -> „Load pri­vate key“. Anschlie­ßend wird der Schlüs­sel über „Con­ver­si­ons“ -> „Export OpenSSH key“ in eine Datei mit dem Namen „id_rsa“ expor­tiert. Diese Datei wird dann in den Benut­zer­ord­ner (z.B. „c:\Users\seeseekey\.ssh\“ unter Win­dows 7) gelegt. Anschlie­ßend kann der Schlüs­sel auch unter der Git Bash benutzt werden.

Wie man Git auf einem Ubun­tu­ser­ver auf­setzt hatte ich vor eini­ger Zeit in einem Arti­kel beschrie­ben. Nach­teil der vor­ge­stell­ten Methode ist, das sie sich nur für einen Nut­zer eig­net. Natür­lich kann man mit die­ser Methode auch meh­rere Nut­zer zu dem Repo­si­to­ries ver­bin­den, hat damit aber keine Mög­lich­keit mehr Zugriffs­be­rech­ti­gun­gen für die Repo­si­to­ries zu setzen.

Als Lösung für das Pro­blem wird Gito­lite für die Nut­zer und Rech­te­ver­wal­tung genutzt. Im ers­ten Schritt wer­den auf dem Ser­ver die not­wen­di­gen Pakete installiert:

sudo apt-get install git openssh-server perl

Als nächs­ter Schritt wird der Nut­zer ange­legt, in wel­chem Gito­lite läuft und in die­sen gewechselt:

sudo useradd -m git
sudo su git

Danach geht es auch schon an die Instal­la­tion von Gitolite:

cd ~
git clone git://github.com/sitaramc/gitolite
mkdir bin
cd gitolite
./install -ln

Anschlie­ßend muss der öffent­li­che SSH Schlüs­sel von dem Rech­ner mit wel­chem auf das Sys­tem zugrif­fen wer­den soll in den Home Ord­ner des „git“ Nut­zers kopiert wer­den. Anschlie­ßend kann das Setup abge­schlos­sen werden:

cd ~/bin
./gitolite setup -pk $HOME/seeseekey.pub

Damit ist das Setup abge­schlos­sen und es kann an die Kon­fi­gu­ra­tion gehen. Dazu wird vom Rech­ner des­sen Public Key beim Setup benutzt wurde das ent­spre­chende admi­nis­tra­tive Repo­sitory geklont:

git clone git@192.168.1.128:gitolite-admin

Die Datei­struk­tur des Repo­si­to­ries sieht dabei wie folgt aus:

conf
  gitolite.conf
keydir
  seeseekey.pub

In dem Ver­zeich­nis „key­dir“ sind die SSH Schlüs­sel ent­hal­ten. Um einen Nut­zer hin­zu­zu­fü­gen reicht es ein­fach einen neuen öffent­li­chen Schlüs­sel in das Ver­zeich­nis zu legen und das ganze ins Git Repo­sitory ein­zu­brin­gen. Die eigent­li­che Kon­fi­gu­ra­tion der Repo­si­to­ries erfolgt in der „gitolite.conf“ Datei. Diese sieht nach der Erzeu­gung so aus:

repo gitolite-admin
    RW+     =   seeseekey

repo testing
    RW+     =        @all

Das bedeu­tet das es zwei Repo­si­to­res gibt, eines trägt den Namen „gitolite-admin“ und dient der Ver­wal­tung. Das zweite Repo­sitory ist „tes­ting“ auf das alle Nut­zer zugrei­fen dür­fen. Benö­tigt man nun ein neues Repo­sitory, so fügt man einen neuen „repo“ Abschnitt mit dem Namen und den ent­spre­chen­den Rech­ten hinzu. Sobald das ganze com­mi­tet und gepusht wurde, legt Gito­lite das neue Repo­sitory an. Wenn man bei den Schlüs­seln meh­rere SSH Schlüs­sel pro Nut­zer wünscht, so legt man dafür am bes­ten eine Ver­zeich­nis­struk­tur an:

keydir
  seeseekey
    rechner1
      seeseekey.pub
    rechner2
      seeseekey.pub

Möchte man ein Repo­sitory löschen so ent­fernt man es aus der „gitolite.conf“ und löscht es anschlie­ßend auch vom Ser­ver. Damit hat man eine Lösung für Git Ser­ver mit meh­ren Nut­zern und und ent­spre­chen­der Verwaltung.