Cum pot efectua un transfer automat de fișiere securizat între două servere?

Aș dori să transfer zilnic niște fișiere de pe un server A pe un server B (în scopuri de backup). Cu toate acestea, nu pot găsi o cale care să nu creeze breșe de securitate. Scopul meu este ca cineva cu drepturi sudo pe serverul A să nu poată exploata acest transfer pentru a se conecta la serverul B.

Ideea mea de bază a fost să fac un cronjob cu a scp (sau similar) comandă în ea. Evident, utilizarea unei conexiuni SSH bazată pe parolă între A și B nu funcționează, iar utilizarea unei conexiuni SSH bazată pe cheie ar permite, din câte știu eu, unui utilizator al serverului A să se conecteze direct la B prin A.

Nu sunt un expert în securitate, s-ar putea să ratez ceea ce este evident aici. Există vreo modalitate de a realiza ceea ce îmi doresc?

Nu vreau ca utilizatorii serverului B să se poată conecta nici la serverul A.

Utilizare rsync într-un cronjob, ca de obicei.

Pe clientul rsync, utilizatorii cu privilegii „sudo” vor putea vedea numele de utilizator și parola necesare pentru a accesa folderele specifice partajate de serverul rsync.

Dar aceste acreditări sunt separate de acreditările utilizatorului și nu vor oferi acces SSH la server. Deci, dacă lucrurile sunt configurate corect, tot ce vor avea acces pe server sunt copiile de rezervă de pe propria lor mașină.

Pe serverul rsync, nu există nimic care să ofere acces la clientul rsync.

Doar trimiteți fișierul la serverA în loc să aibă un utilizator pe serverA copiați-l de pe serverB. Dacă doriți să copiați foo.txt din serverB la serverA, o puteți face în două moduri de bază:

1. Rulați o comandă serverA pentru a aduce dosarul de la serverB.
2. Rulați o comandă serverB pentru a trimite fișierul către serverA.

În al doilea caz, nimeni serverA are nevoie de acces la serverB. Deci, configurați un ssh bazat pe chei de la serverB la serverA și apoi adăugați linia cron utilizatorului relevant pe serverul B.

De exemplu, pentru a face acest lucru manual, ați face:

user1@serverB $ scp /path/to/foo.txt user1@serverA:/path/to/foo.txt

În acest fel, nimeni pe serverA are orice acces la serverB și trebuie doar să aveți un utilizator activat serverB cine se poate autentifica serverA.

O modalitate obișnuită de a face acest lucru este să utilizați sftp și chroot.

Pe serverul B, ați configura ssh pentru a root utilizatorul de pe serverul A și a restricționa la sftp. de exemplu. adaugă la /etc/ssh/sshd_config

Subsistemul sftp /usr/lib/openssh/sftp-server

Potriviți copiile de rezervă ale grupului
    ChrootDirectory /backups/%u
    AuthorizedKeysFile %h/.ssh/authorized_keys
    ForceCommand intern-sftp
    AllowTcpForwarding nr

Apoi creați un utilizator pentru serverul A pe serverul B, de ex. utilizatorA, cu un director /backups/userA (deținut de root). Atunci ai avea nevoie de un copii de rezervă grup, care utilizatorA se adaugă la. Regula din configurația ssh se aplică utilizatorilor din acest grup și acest lucru restricționează utilizatorul de la A doar la datele pe care le-au introdus în acest „dropbox” sftp și nu le permite să facă ssh.

Pentru copii de siguranță, aș recomanda această abordare, combinată cu un instrument precum duply pentru gestionarea efectivă a copiilor de rezervă, astfel încât să poată fi criptate, incrementale, ușor de restaurat etc.

Există o problemă cu ipotezele din spatele întrebării dvs. SSH este conceput pentru a oferi acces la un sistem, dar doriți să utilizați SSH și nu să acordați acces la sistem. Poate că SSH nu este instrumentul potrivit pentru aceste cerințe?

Opțiunea 1

Transferurile de fișiere au loc pe site-uri web tot timpul, fără ca persoana care încarcă accesul la sistemul de bază. Creați sau găsiți o aplicație web simplă care poate primi un fișier încărcat și scrieți-l într-un director dorit. Solicitați un secret al aplicației sau o parolă dacă este necesar. Orice utilizator root de pe Sistemul A va putea vedea un fișier care stochează un secret al aplicației, astfel încât să poată încărca fișiere în același mod. Dar atâta timp cât aplicația web care primește încărcarea nu oferă niciun fel de acces de citire, este îndeplinită cerința de a menține utilizatorul root în afara sistemului B.

Opțiunea 2

Puteți folosi în continuare SSH pentru a trimite fișierele. Limitați doar permisiunile. Pentru utilizatorul Sistemului B care este utilizat pentru transferul SCP, acordați doar acces de scriere la un anumit director și permisiunea de citire nicăieri în Sistemul B. Puteți trimite comenzi de transfer de fișiere din Sistemul A pentru a scrie în acel director, pur și simplu nu o veți face niciodată să le poată citi.Din nou, un utilizator root pe Sistemul A va avea capacitatea de a accesa cheile SSH și de a-și încărca propriile fișiere în același loc, dar dacă utilizatorul de Sistem B nu avea permisiuni de citire pe sistemul de fișiere, ceea ce poate face este limitat. Această tehnică poate fi mai ușor de spus decât de făcut. Utilizatorul rădăcină a sistemului A ar putea în continuare să obțină un shell pe Sistemul B, așa că dacă nu limitați permisiunile pe întregul sistem, inclusiv comenzile executabile ale sistemului, utilizatorul poate încă să ruleze o mulțime de comenzi fără a citi fișierele de date. Deci depinde de ce vrei să spui prin cineva care are acces la sistem. Din nou, neutilizarea SSH este probabil cea mai bună soluție aici.

ssh și rsync (și SFTP) vă vor oferi întotdeauna o autentificare pe serverul la care vă conectați, pe care ați putea sau nu să o puteți controla.

De ce nu folosiți HTTPS?

Poți fie

1. rulați un server pe A și aveți B OBȚINE datele
2. sau rulați-l pe B și aveți A POST aceasta.

Pentru a proteja datele de terțe părți neafiliate, va trebui să criptați conexiunea (utilizați HTTPS, nu HTTP simplu) și foloseste cel putin autentificare de bază.

Acest lucru nu va proteja datele de la utilizatorii root pe niciunul dintre cele două sisteme: ambele pot citit datele și modifica este de partea lor și literalmente nu poți face nimic în privința asta.

Un server HTTP simplu poate fi pornit în mai multe moduri, de exemplu:

python -m SimpleHTTPServer 8080

Criptarea conexiunii necesită crearea unui certificat SSL și a câteva linii de cod Python:

#!/usr/bin/python
importați BaseHTTPServer, SimpleHTTPServer
import ssl

httpd = BaseHTTPServer.HTTPServer(('0.0.0.0', 8443), SimpleHTTPServer.SimpleHTTPRequestHandler)
httpd.socket = ssl.wrap_socket(httpd.socket, certfile='./certs_and_key.pem', server_side=True)
httpd.serve_forever()

Autentificarea de bază necesită puțin mai mult cod, dar asta poate, de asemenea fi realizat.

În timp ce nu ssh, s-ar putea să găsiți asta sincronizare este de interes:

• este nevoie de securitate serios
• este open source
• are grozav documentație
• acceptă tunelul SSH
• suportă mai multe platforme

Este disponibil și prin apt, împreună cu pachetele aferente:

$ apt search -q sincronizare
Triere...
Căutare text integral...
golang-github-syncthing-notify-dev/focal,focal 0.0~git20180806.b76b458-1 toate
  Biblioteca de notificare a evenimentelor sistemului de fișiere pe steroizi

golang-github-syncthing-syncthing-dev/focal,focal 1.1.4~ds1-4ubuntu1 toate
  sincronizare descentralizată a fișierelor - pachet dev

sincronizare/focal 1.1.4~ds1-4ubuntu1 amd64
  sincronizare descentralizată a fișierelor

syncthing-discosrv/focal 1.1.4~ds1-4ubuntu1 amd64
  sincronizare descentralizată a fișierelor - server de descoperire

sincronizare-gtk/focal,focal 0.9.4.4-1 all
  GUI bazat pe GTK3 și pictograma zonei de notificare pentru sincronizare

syncthing-relaysrv/focal 1.1.4~ds1-4ubuntu1 amd64
  sincronizare descentralizată a fișierelor - server de releu

Pentru SSH, în funcție de frecvența intervalului și, ca atare, de factorul de enervare, puteți implementa Autentificare duo prin intermediul pam, ceea ce ar însemna că ar trebui să aibă loc aprobarea pentru conexiuni.