Necorespundere de protocol SSH (Unix, Ubuntu, Ssh, Duplicitate)

Christophe De Troyer a intrebat.
a intrebat.

Am o problemă foarte ciudată. Am două servere, și anume daytona, , care servește ca server de stocare cu o matrice raid. Îl WOL atunci când vreau să fac un backup pe acesta. Cel de-al doilea server este testarossa care îmi rulează serviciile. Acesta din urmă este cel pentru care vreau să fac zilnic copii de rezervă folosind duplicitatea. Ambele mașini rulează Ubuntu Server 14.04, complet actualizat.

Am scris un script pentru a face WOL pe mașină și apoi să execut backup-ul duplicity în fiecare zi la o oră fixă.

Partea de import a backupscriptului este prezentată mai jos. Backup-ul se execută ca utilizator root pe testarossa și face copii de rezervă prin SSH prin backupper pe daytona. Apoi se oprește prin ssh folosind utilizatorul christophe pe daytona.

Am configurat cheile ssh pe testarossa astfel încât să pot intra prin ssh în daytona folosind backupper și christophe. Pot executa comenzile din script foarte bine, și chiar pot executa scriptul și în shell (./script.sh).

Am adăugat scriptul în cronjobs folosind:

0 10  * * * /bin/bash /root/scripts/dailybackup >> /var/log/backup.daily.log 2>&1

De fiecare dată când se execută cronjob-ul, primesc următoarea eroare:

BackendException: ssh connection to [email protected]:22 failed: [Errno 111] Connection refused

Am, sugerat pe #ubuntu-server, , am încercat echo "" | nc 192.168.1.120 22 și care returnează următoarea eroare:

SSH-2.0-OpenSSH_6.6.1p1 Ubuntu-2ubuntu2.3
Protocol mismatch.

Acest lucru m-a făcut să cred că trebuie să actualizez daytona ceea ce am și făcut. A existat o actualizare pentru gnu-openssl pachet și apoi cronjob a funcționat bine. Dar acum nu mai merge.

Nu mai am idei despre cum să depanez acest lucru. Am prea puțină experiență pentru a o rezolva. Vreun indiciu?

Script

serverip=192.168.1.120
servermac=14:DA:E9:4C:6E:17
attempts=50
sourcedir="/"
targetdir="sftp://[email protected]//mnt/raidarr0/backups/testarossa/duplicity/daily"
encryptkey="AC7A8F8C"
keep="1M"
sudouser="christophe" 
fullbackup=""

## Load in the passphrase file env variable
. /root/.passphrase
export PASSPHRASE

## Do the snapshot backup
if [ "$fullbackup" == "full" ]; then
    $(which duplicity) full --encrypt-key "$encryptkey" --exclude /srv --exclude /usr --exclude /cdrom --exclude /lib64 --exclude /bin --exclude /sbin --exclude /boot   --exclude /dev --exclude /proc --exclude /sys --exclude /tmp --exclude /run --exclude /mnt --exclude /media --exclude /lost+found "$sourcedir" "$targetdir"
else
    $(which duplicity)      --encrypt-key "$encryptkey" --exclude /srv --exclude /usr --exclude /cdrom --exclude /lib64 --exclude /bin --exclude /sbin --exclude /boot   --exclude /dev --exclude /proc --exclude /sys --exclude /tmp --exclude /run --exclude /mnt --exclude /media --exclude /lost+found "$sourcedir" "$targetdir"
fi

echo "Backup to target completed."

## Remove older backups. We only want to backup 30 days. 
# (We have a full every month)
$(which duplicity) remove-older-than "$keep" --force "$targetdir"
echo "Removal of stale backups completed"
## Shut down the machine using a sudo account. Expects the user to have a key installed for this.
ssh "$sudouser"@"$serverip" "sudo shutdown -h now"
echo "Shutdown command issued to remote machine"

Urmează:

1) Scriptul are o funcție care așteaptă ca gazda să fie ping-abilă. Astfel, începe să facă backup doar atunci când gazda a pornit complet. (Acest script a funcționat bine timp de peste un an pe o altă mașină cu Debian).

2) Scriptul rulează bine în shell-ul de root, într-adevăr.

3) Și nu, nu am o comandă proxy în niciunul dintre fișierele de setare.

4) Am încercat să execut comanda folosind sudo /bin/bash /root/scripts/dailybackup și acum, nu știu din ce motiv, îmi cere să verific autenticitatea gazdei (cu yes/no). Deci, acum se pare că comanda de duplicitate nu utilizează comanda mea known_hosts fișier?

Comentarii

  • Nu, nepotrivirea de protocol este doar pentru că „echo” nu vorbește protocolul ssh (sshd este confuz de acel caracter LF pe care i-l trimite echo). Totuși, faptul că sshd emite un banner nu este în concordanță cu eroarea dvs. „Connection refused” (Conexiune refuzată). Aveți un ProxyCommand configurat în /etc/ssh_config sau ~/.ssh/config? –  > Por Stéphane Chazelas.
  • Am înțeles corect: /bin/bash /root/scripts/dailybackup funcționează bine atunci când este rulat manual, dar dă connection refused atunci când este rulat prin cron? –  > Por michas.
  • Este scriptul prea rapid? Cu alte cuvinte, backup-ul este efectuat înainte ca gazda să fie complet pornită și inițializată? A connection refused poate apărea un mesaj în cazul în care sshd serviciul nu este încă pornit/operațional pe gazda țintă. –  > Por Lambert.
  • Faptul că o mașină este „pingabilă” nu înseamnă că serviciile dependente de rețea sunt încă inițializate. Pentru a testa dacă sshd este în funcțiune, luați în considerare utilizarea nc -vz 192.168.1.120 22 –  > Por Lambert.
  • Eu îl voi testa temporar cu un sleep de 1 minut. –  > Por Christophe De Troyer.
1 răspunsuri
cristi

Eroarea „Protocol mismatch.” este foarte simplă: nc nu folosește protocolul ssh pentru a se conecta la adresa și portul de la distanță.

În ceea ce privește problema reală: utilizatorul backupper se conectează prin chei ssh? Dacă da, unde sunt păstrate cheile?

Ceea ce cred că se întâmplă este că vă testați scriptul cu un alt utilizator decât root.

Încercați să rulați scriptul dvs. ca root în acest fel și vedeți dacă dă și el greș:

sudo /bin/bash /root/scripts/dailybackup

Alții au avut aceeași eroare din cauza conflictului de IP

Comentarii

  • Vedeți urmarea. Mașina îmi cere acum să verific cheia. Ce ciudat. Acestea ar trebui să se afle în known_hosts fișier…  > Por Christophe De Troyer.
  • adăugați aceste opțiuni la comanda ssh și verificați din nou „-o UserKnownHostsFile=/dev/null -o StrictHostKeyChecking=no” -.  > Por cristi.
  • Cheile sunt păstrate în folderul respectiv al utilizatorului, așa cum era de așteptat. Astfel, root își are cheia publică în /home/(christophe|backupper)/.ssh/authorized_keys . Deci da, prin intermediul cheilor ssh. –  > Por Christophe De Troyer.
  • Ultima eroare nu este legată de cheile ssh, ci pentru că sistemul nu are încredere în gazda ssh. Fie executați o singură dată comanda și răspundeți cu „y” când vi se cere, fie folosiți parametrii de mai sus pentru ca ssh să aibă încredere în toate gazdele –  > Por cristi.