dump über ssh

P

pat

Member
Hi,

ich bin gerade dabei nach http://wiki.bsdforen.de/index.php/FreeBSD_-_Backup Backups zu erstellen.
Dabei möchte ich die erstellten Backups direkt per ssh auf meinen file-Server sichern.
Das ganze hab ich jetzt mit folgendem Befehl probiert:
dump -0 -Lauf - /var | gzip -2 | ssh bla@blub dd of=/path/to/save/l0_`date +%y%m%d`_var_ad0s1d.gz
Das Problem ist nun, dass der stderr von dump die Eingabe von der ssh-Passworteingabe vollschreibt.
Ich könnte natürlich auch 2> /dev/null benutzen. Das ist aber irgendwie unschön und verhindert afaik auch nicht, dass dump schon vor der Passwort eingabe beginnt.

pat
 
Du willst keine Passwoerter, sondern Public-Key-Authentifizierung mit ssh verwenden. Siehe hierzu ssh-keygen(1)
 
Ich benutz ja publickeys.
Die Eingabe sieht dann wie folgt aus:
Enter passphrase for key '/home/pat/.ssh/id_rsa':

pat
 
Nein, da kommt auch:
Enter passphrase for key '/home/pat/.ssh/id_rsa':
Das liegt wohl daran, dass ich beim Keygenerieren mal ein Passphrase eingegeben habe.

Geht es denn wirklich nur ohne Passphrase und kann ich auch ohne Bedenken ohne Passphrase arbeiten? Die Passphrase schützt doch nur davor, dass jemand mit einem geklautem Privatkey so gut wie nichts anfangen kann?

pat
 
Du könntest auch deinen privaten Schlüssel mit dem ssh-agent "laden",
womit dein privater Schlüssel mit einer Passphrase geschützt ist.
Siehe dazu:
http://sial.org/howto/openssh/publickey-auth/

Du kannst natürlich mit einem privaten Schlüssel ohne Passphrase arbeiten.
Wie riskant das ist, wirst du selbst für deinen Anwendungsbereich beurteilen müssen.
 
Zuletzt bearbeitet:
Also Passphras sollte schon sein, es gibt irgendwo ein Papier zum Thema "SSH-Schlüssel ohne Passphrase als Wurm". Es ist also möglich dies als Angriffvektor auszunutzen und so Schadprogramme zu verbreiten.

Wenn du wirklich ohne Passwort arbeiten willst und Rootzugriff auf den Zielrechner hast, solltest du ein paar Schutzmaßnahmen ergreifen.

Ich lasse nachts an der Uni ein paar Rechner per rsync über SSH auf einen NetBSD-Server sichern. Da die Benutzer Super-DAUs sind, habe ich entsprechend Schlüssel ohne Passwort verwendet. Weiterhin habe ich auch keinen Zugriff auf die Portfilterfunktion des Switches, was schlecht ist da alle Rechner offizielle IP-Adressen haben.

Damit das ganze nicht zu sehr offensteht habe ich einen eigenen sshd für die Sicherungsaktion gestartet auf einem port >60000. Auf diesem sshd darf sich *nur* der Sicherungsbenutzer einloggen, er geht dann in ein chroot und darf dort seine Daten reinkopieren. zusätzlich ist der sshd vom Paketfilter abgeschirmt, es können nur die eingerichteten Quellrechner zugreifen und das per cronjob auch nur zur nächtlichen Sicherungsorgie.
 
brauchst du die verschlüsselung des übertragungsweges oder gehts nur um absicherung des zugriffs? ich hab da mal was ganz simples gestrickt, was einfach in inetd als shell-script läuft, sich um alles kümemrt, inkl. rudimentäre authentifizierung und nem extrem simplen client. ich mach so seit jahren backup daheim von den kisten als normaluser im cronjob

client sieht so aus:

#!/usr/local/bin/bash

3<>/dev/tcp/$1/5001
echo "$2" >>/dev/fd/3
read </dev/fd/3 a
echo "`date +%H:%M:%S` $a"
echo "$a-mysecrethashkey" | /sbin/md5 >>/dev/fd/3
cat </dev/fd/3 >$a
3<&-

shell-hacks rocken fuer sowas. aber verschluesseln tut das so nicht. man koennte ja nochn openssl dazwischen stellen :)

wer die volle packung will, soll einfach hier den request reinposten, dann kommt der "server" auch
 
Das ganze ist eigentlich nur für zu Hause gedacht.
Von der wirklich benötigten Sicherheit her könnte ich das ganze auch mit nfs oder sonstigem machen.
Ich möchte aber trotzdem nur so aus Spaß und Wissensdurst ein einigermaßen sicheres System aufsetzen und benutzen.
Ich werde das nun erstmal mit dem ssh-agent testen, vielleicht klapt das damit ja ganz gut.
Sowas wie VAXpowers script verstehe ich noch nicht gut genug um es einsetzten zu können.

pat ( der für die vielen Antworten erfreut ist)
 
okay. um das verständnis zu erhöhen, weil ich die lösung für daheim als sehr geeignet empfinde, hier der server:

erstmal die "drumrums":
/etc/services:
backup 5001/tcp # UnixIron backup
/etc/inetd.conf:
backup stream tcp nowait root /usr/local/bin/backup backup

und der eigentlich "server", /usr/local/bin/backup:
Code: 
#!/bin/sh

CURRDATE=`date +%Y%m%d`
CURRMONTH=`date +%Y%m`
CURRWEEK=`date +%U`

LASTWEEK="never"
LASTMONTH="never"

BFS=""
read fs

logger "backup: request for $fs"

case "$fs" in
        root)
                BFS="/"
                ;;
        usr)
                BFS="/usr"
                ;;
        var)
                BFS="/var"
                ;;
        export)
                BFS="/export"
                ;;
        home)
                BFS="/export/home"
                ;;
        *)
                exit 1
                ;;
esac

[ -f /var/tmp/lastbackup-$fs ] && . /var/tmp/lastbackup-$fs
LEVEL=2
[ "x$CURRWEEK" != "x$LASTWEEK" ] && LEVEL=1
[ "x$CURRMONTH" != "x$LASTMONTH" ] && LEVEL=0
FILENAME="$fs-$LEVEL-$CURRDATE.dump"
echo "$FILENAME"
logger "backup: ready for a dump of $BFS with level $LEVEL"
read md5
[ "x`echo "$FILENAME-mysecrethashkey" | md5`" = "x$md5" ] && {
        logger "backup: dumping filesystem"
        dump -$LEVEL -a -f - -u $BFS 2>/dev/zero && {
                logger "backup: dump completed"
                rm -f /var/tmp/lastbackup-$fs
                echo "LASTWEEK=$CURRWEEK" >>/var/tmp/lastbackup-$fs
                echo "LASTMONTH=$CURRMONTH" >>/var/tmp/lastbackup-$fs
        }
        logger "backup: finished."
}

das server-script muss entsprechend angepasst werden, klar. vor allem ist in server und client das "mysecrethashkey" durch was "ultimativ streng geheimes" zu ersetzen :)
und: das ding ist insofern komplett ranzig, dass es halt "einfach tut". bloss nicht in unsichere netze raus stellen, das sollte wirklich nur in kontrollierten umgebungen laufen, also nur client mit server. viele fehlerprüfungen sind da nämlich nicht drin :) aber dafür machts sauberes generations-handling:

level 0 - monatlich
level 1 - wöchentlich
level 2 - täglich

aufgerufen wirds aus dem cron-script auf dem client dann z.b. so:

Code: 
cd /export/backups/calchas
/export/home/michael/bin/backup calchas root
/export/home/michael/bin/backup calchas usr
/export/home/michael/bin/backup calchas var

/export/home/michael/bin/cleanup.pl

und der vollständigkeit halber das cleanup.pl:

Code: 
#!/usr/bin/perl

use strict;
use POSIX;

for my $host (qw(calchas)) {
        my $path = '/export/backups/' . $host;
        my $deldate = strftime('%Y%m%d', localtime(time - (7 * 24 * 60 * 60)));
        opendir(DH, $path) or die "nope";
        my @files = readdir(DH);
        closedir(DH);
        my %backups = ();
        for my $file (@files) {
                if($file =~ /^([^-]*)-([0-9])-([0-9]{8,8})(\.dump.*)$/) {
                        my $fs = $1;
                        my $lev = $2;
                        my $date = $3;
                        my $suff = $4;
                        if(-f $path . '/' . $file) {
                                $backups{$fs}{$date}{level} = $lev;
                                $backups{$fs}{$date}{file} = $path . '/' . $file;
                        }
                }
        }
        for my $fs (sort keys %backups) {
                my $mylev = 999;
                for my $date (sort {$b cmp $a} keys %{$backups{$fs}}) {
                        my $level = $backups{$fs}{$date}{level};
                        if($level >= $mylev && $date le $deldate) {
                                print 'deleting old backup file ' . $backups{$fs}{$date}{file} . "\n";
                                unlink $backups{$fs}{$date}{file};
                        } else {
                                $mylev = $level;
                        }
                }
        }
}

und nochmal der client:

Code: 
#!/usr/local/bin/bash

3<>/dev/tcp/$1/5001
echo "$2" >>/dev/fd/3
read </dev/fd/3 a
echo "`date +%H:%M:%S` $a"
echo "$a-mysecrethashkey" | /sbin/md5 >>/dev/fd/3
cat </dev/fd/3 >$a
3<&-

so. "backup in a nutshell", use on your own risk, aber wir gesagt, hier läufts seit jahren, erfüllt seinen zweck, nie probleme gehabt (ausser wenn /export/backup mal voll war :)
 
Zuletzt bearbeitet:
@VAXPower
Deine Backuplösung ist gut und recht, aber in der Wiki-Backupanleitung wird eine automatische Backuplösung vorgestellt, die mit OpenSSH auch für unsichere Kommunikationskanäle geeignet ist!?
 
@AndreasMeyer:

darf ich pat zitieren? "Das ganze ist eigentlich nur für zu Hause gedacht"

Was im Wiki vorgestellt wird, muß ja nicht unbedingt hier nochmal wiedergespiegelt werden. Aber wer sich durch meinen Versuch, etwas positives beizutragen, gestört fühlt, möge dies verzeihen, kommt nicht wieder vor.
 
@VAXpower
Da stört sich keiner dran, es sollte mehr geben die mal Ihre Scripte hier reinstellen und so anderen helfen.
 
Du musst dich einloggen oder registrieren, um hier zu antworten.
Zurück
Oben