Jenkins, ssh und Probleme

Mein im vergangenes Post beschriebens Problem war dann doch nicht so einfach zu lösen. Nun ein neuer Ansatz: Den Dump einfach per Rsync ziehen. Also schön ssh-Keys für den Jenkins-User angelegt und gehofft:

jenkins@box:~$ ssh userfoo@hostname
Host key verification failed.

Ah ja. Makes sense. Irgendwie war der User nicht in der Lage das known_hosts-File anzulegen. Habe wirklich viel dran rumprobiert bis ich auf den Workaround kam:

Man loggt sich auf dem Jenkins-Server und auf der Bash ein mit

sudo su jenkins -s /bin/bash

Dann einfach mal ein

jenkins@box:~$ ssh userfoo@hostname

Und dann legt er auch known_hosts an und der Job läuft auf einmal im Jenkins. Was auch immer...

SSH nur mit git und rsync

Es ist mal wieder soweit: Sein ganzes Backup-Gedöns überdenken und versuchen es ein wenig anzupassen. Es gibt da einen kleinen vServer denn ich seit neustem administrieren soll. Keine Backups... war ja klar. Also was nimmt man da nun? Ich benutze seit Jahren ein zusammengefrickeltes Shell-Script mit dem Namen "DoTheBackup". Seit ein paar Monaten habe ich versucht es mit Python in was Besseres zu gießen. Rausgekommen ist dies hier. Bis jetzt setze ich da voll auf rsync und git. Und wenn man den Remote-Host auf den man die Backups schieben möchte ein wenig einschränken möchte, und zwar auf genau diese beiden Kommandos, war das für mich nicht so einfach. Es gibt da viele Möglichkeiten. Vor allem kann man seine /home/backupuser/.ssh/authorized_keys auf ein Kommando begrenzen. Man nutzt dafür commando="rsync foo bar" vor dem Publickey. Wie gesagt: Ein Kommando. Nun kann man sich ein Wrapper-Script bauen. Habe ich versucht und bin an git gescheitert. Viel und lange gegoogelt und kaum etwas gefunden. Bis auf diese Dokumentation von git selber. git-shell hatte ich erstmal aussenvor gelassen weil ich bis jetzt dachte es beschränkt sich ganz auf git. Falsch!

Den Shell des Backupusers auf git-shell setzen.

In [ ]:
%%bash
sudo chsh -s $(which git-shell) backupuser

Man legt das Verzeichnis git-shell-commands in das Homeverzeichnis des Backup-Users.

In [ ]:
%%bash 
mkdir /home/backupuser/git-shell-commands

Nun kann man Symlinks in dieses Verzeichnis legen mit den Kommandos die der Backup-User über SSH ausführen darf.

In [ ]:
%%bash
cd /home/backupuser/git-shell-commands
ln -s $(which rsync) rsync

Und zack feddich...

Zugriff retten mit Dropbear

Was macht man eigentlich wenn man den SSHD auf einem Root-Server konfigurieren möchte, man aber doch ein wenig Angst hat das es das letzte mal ist den Server von innen zu sehen? Ich hatte mal auf Twitter rumgefragt und kam eigentlich zu einer brauchbaren Lösung. Als erstes ist es wohl so, dass die SSH-Session erhalten bleibt solange ich den Dienst nur "reloade". Das war mir dann aber doch ein wenig zu gefährlich. Der andere Plan: Dropbear installieren und auf einem alternativen Port laufen lassen. Dropbear ist ein schlanker kleiner SSH-Server. Schnell installiert, den Port angepasst und gestartet. Ich glaube ich kann jetzt doch ein wenig ruhiger schlafen.