Paranoia, XenServer and libvirt: Full Disk Encryption unlocking from virtual serial TTY


Everybody wants encryption today; encryption of network traffic, mainly.
But what about the encryption of data-at-rest? I mean, what if someone got physical access to your storage?
Of course you can protect specific folders with your tools of choice, but there’s always a chance that some file got saved outside your security fence by a zealous program, or just forgotten by you on the desktop… here comes the Full Disk Encryption (shortly, FDE) to the rescue!

Maybe you are  already using it without being aware of that… if BitLocker on Windows and FileVault on Mac OS X sound familiar, you are on track.

The penguin within

But, what about our beloved Linux machines?
In the Linux world, FDE is mainly achieved through LUKS; this software is capable of encrypting your disks with AESXTS using both passphrases and key files, usually stored in an USB drive and plugged on-demand.

I won’t tell you how to setup LUKS in your machine because you should better refer to the installation manual of your distro.

If you plan to use it with a workstation, you’ll be set already manually inserting the password or the USB drive on every boot.

And my VMs?

But, what if you want to use LUKS in a virtual environment, in a hosted VM?

I won’t talk about acrobatic USB-passthrough, focusing instead on the passphrase method.

Of  course, you can manually type it in your preferred hypervisor VM-console; but because having a very long and random passphrase is of utmost importance, writing a 40 characters long on every server reboot can be extremely tedious and can easily bring to bad habits, like short passphrases, avoiding necessary update-reboot cycles or dumping the LUKS thing at all.

Meeting the serial (killer?)

The best way of input long keys would be having it stored in encrypted keyrings with the possibility to copy-and-paste them into the VM prompt as needed, but the graphical consoles AFAIK don’t support input methods like that, and of course we cannot use SSH&co. because there isn’t any service running in the VM before boot.

There’s another way to access the VM at “physical” level, at least with hypervisors like KVM and XEN: the glorious and vintage serial console!

Maybe you have already heard of it for router configuration; shortly, it was the leading way of talking to an operating system out-of-band before the video output we use today.

Any Linux distribution provide this capability; to enable it in a CentOS 7 guest, you just need to modify your /etc/default/grub to make it looks like this:

 

GRUB_TIMEOUT=5
GRUB_DISTRIBUTOR="$(sed 's, release .*$,,g' /etc/system-release)"
GRUB_DEFAULT=saved
GRUB_DISABLE_SUBMENU=true
GRUB_TERMINAL="console serial"
GRUB_SERIAL_COMMAND="serial --speed=115200 --unit=0 --word=8 --parity=no --stop=1"
GRUB_CMDLINE_LINUX_DEFAULT="console=tty1 console=ttyS0,115200"
GRUB_CMDLINE_LINUX="rd.lvm.lv=DONT_CHANGE_IT!/root rd.luks.uuid=DONT_CHANGE_IT! rd.lvm.lv=DONT_CHANGE_IT!/s
wap rhgb"
GRUB_DISABLE_RECOVERY="true"

and rebuild your initrd with grub2-mkconfig -o /boot/grub2/grub.cfg.
Take a snapshot before doing any modification to your grub.cfg, you have been warned!

Now reboot your system and everything should work as before, except for…

Practical unlocking

Yes, now there is an active serial interface that can be used to access your VM from the hypervisor, in a completely textually way.
Really, you can stop typing that super-long random string one-character-at-time right now!

The thing is, how to access it from the virtualization host?

  • If you are using libvirt-virsh framework, you are lucky: just type virsh console VMname and you are set! The exit-escape is CTRL-].
  • If you are on XenServer with XAPI, use the xl console VMname console (same escape). Dump that xe console command, it won’t help you if you are targeting an HVM guest; it is very likely that you are on HVM, you should now if you still are on PV-mode. The xl command solution is undocumented in the XenServer doc, and it’s the actual reason why I wrote this post. 

Oh, XL is also the new default toolstack for XEN management!

Now you should be set and smooth, go and enjoy your very-long and very-random LUKS passphrases!

XenServer 7 software RAID con mail alert

You can also read this article in english.
XenServer 7 si sta imponendo come l’implementazione di riferimento dell’Hypervisor open source Xen, fornendo funzionalità avanzate di storage, networking e gestione (oltre che HA) pacchettizzate in una soluzione totalmente self-contained e di livello enterprise; il tutto, risultando spesso superiore a VMware vSphere e ad HyperV e KVM, gli altri big player del settore.

Giusto per ricordarlo, Xen è l’Hypervisor che funge da motore per la maggior parte dei cloud pubblici (da AWS in giù), è totalmente open source e la sua declinazione XenServer è ora gestita direttamente dalla Linux Foundation (non più da CITRIX),  risultando de facto la soluzione standard per la virtualizzazione bare-metal FLOSS.

Potenti batterie incluse!

Nella versione 7, l’adozione di una CentOS 7 modificata come dom0 ha fatto fare passi da gigante allo stack software che circonda il microkernel Xen… difatti, l’installazione standard di XS7 include già tutti gli elementi del puzzle necessari per poter saltare a piè pari una soluzione RAID hardware e tuffarci nelle meraviglie del software RAID! MDADM, ad oggi, è una delle pochissime alternative per creare array fra dischi NVMe o gestire altre configurazioni di nicchia e/o con un forte stress sulle performance; grazie alle CPU moderne, il software RAID (specie su grossi array, e naturalmente con diverse peculiarità) gioca spesso alla pari con gli ASICS dei più rinomati controllers.

Il RAID software consente inoltre di creare array utilizzando dischi di qualsiasi brand (anche non certificati per il vostro server), cosa che da un vantaggio strategico a XS rispetto a prodotti come VMware, che invece permettono al più di creare RAIN  tramite add-on a pagamento come vSAN. Se avete mai comparato i costi dei dischi branded (HP, IBM, Dell, ecc.) VS gli stessi modelli off-the-shelf (in special modo SSD), capirete bene quale possa essere il vantaggio economico.

Dive into MDADM

Il workflow da seguire per realizzare una soluzione RAID software di livello enterprise su XS7 che ci avviserà in automatico di eventuali malfunzionamenti, è molto semplice:

  • creazione di un array con MDADM;
  • configurazione di SSMTP per l’invio di notifiche;
  • test dell’invio notifiche e fault-rebuild dell’array;
  • aggiunta dell’array come SR.

MDADM è un software veramente battle-tested; incluso nel kernel linux da moltissimi anni, si è guadagnato sul campo la sua fama di stack molto stabile e privo di bugs importanti, tant’è che viene da anni utilizzato in grossi sistemi di produzione (degni di nota sopratutto i “big irons x86” dell’ultimo quinquennio), nonché nella maggior parte dei NAS commerciali (Synology, QNAP, Buffalo, ecc).

Risultando già incluso nella installazione standard di XS7, creare un array RAID risulta semplicissimo nel tipico scenario in cui avete installato l’Hypervisor su un drive USB che non farà parte dell’array… come da best practice! E voi seguite le best practices, no? Ne faccio cenno anche qui.

Ad esempio, nel caso in cui volessimo creare un array RAID 10 con i primi quattro HDD del sistema, basterà eseguire

 mdadm --create /dev/md0 --run --level=10 --raid-devices=4 /dev/sd[a,b,c,d] 

e, per monitorare la costruzione dell’array,

 watch cat /proc/mdstat 

oppure il sempreverde

 mdadm --detail /dev/md0

che, inoltre, ci fornisce varie informazioni sullo status del nostro array.

Ti fidi di un sistema che non ti avvisa se c’è un guasto?

Settiamo io monitoraggio dell’array; intanto, copiamo la configurazione attiva nel file di configurazione di MDADM

 mdadm --verbose --detail --scan >> /etc/mdadm.conf 

questo attiva il monitoring dell’array con le caratteristiche specificate. Quindi, configuriamo SSMTP per l’invio della posta ad un nostro indirizzo e-mail.

A titolo di esempio, la seguente configurazione del file /etc/ssmtp/ssmtp.conf è utilizzabile per l’invio delle notifiche da un indirizzo gmail:

 
root=vostra_mail@gmail.com
mailhub=smtp.gmail.com:587
Hostname=vostro_hostname.vostrodominio.sth
UseTLS=YES
TLS_CA_File=/etc/pki/tls/certs/ca-bundle.crt
UseSTARTTLS=YES
AuthUser=vostra_mail@gmail.com
AuthPass=vostra_password
FromLineOverride=YES

È importante non dimenticare di configurare anche il file /etc/ssmtp/revaliases con una riga come la seguente:

 root:vostra_mail@gmail.com:smtp.gmail.com:587 

Infine, è necessario aggiungere i parametri MAILADDR e MAILFROM nelle ultime righe di /etc/mdadm.conf, in modo che il file risultante sia assimilabile a questo modello:

 
ARRAY /dev/md0 level=raid10 num-devices=4 metadata=1.2 name=vostro_hostname:0 UUID=UUID_ARRAY
    devices=/dev/sda,/dev/sdb,/dev/sdc,/dev/sdd
MAILADDR mail_di_destinazione@provider.sth
MAILFROM vostra_mail@gmail.com

Che setup sarebbe, senza nute… senza testing?

Ora che la configurazione è completata, possiamo testarla; MDADM può eseguire l’invio di una mail di test del sottosistema di notifiche con

 mdadm --monitor --scan --test --oneshot 

; in generale, il test è affidabile, ma se volete potete anche mettere in status “failed” uno dei dischi (attenzione ai tempi di rebuild) con

 mdadm --manage --set-faulty /dev/mdo /dev/sdb mdadm --manage /dev/md0 --add /dev/sdb 

Raccomando di attendere la notifica via mail per una decina di minuti, il demone è giustamente un po “lazy” nel riconoscere il fail, anche quando simulato.

Ora che l’array è testato e pronto all’uso, basta aggiungerlo agli SR utilizzabili da XenServer con un semplice

 xe sr-create content-type=user device-config:device=/dev/md0  name-label="Local RAID10" shared=false type=lvm 

In XS7 l’array viene riconosciuto al reboot senza dover forzare il caricamento di moduli o altre configurazioni particolari, tutto è semplicemente pronto all’uso.

 

IPMI, questo sconosciuto; o anche, “Butta dalla finestra il tuo KVM”

Ho sempre amato le descrizioni “funzionali” dei devices.

Se dovessi descrivere un server, il primo requisito che mi verrebbe in mente sarebbe “è un computer completamente gestibile da remoto”; un requisito cardine, che dovrebbe entrare a far parte della stessa definizione di macchina server.

Come si gestisce da remoto una macchina fisica? Vedo già sbrilluccicare gli occhi del vostro vendor di switch KVM…

NO! I moduli KVM sono costosi, richiedono parecchia banda, non sono inclusi di serie (a parte rari casi) nelle vostre macchine server e comunque non fanno tutto quello che fa IPMI. È nato un grosso business attorno ad essi nel settore SMB a causa delle installazioni fisiche di Windows Server, ma… se nel 2016 pensate davvero di installare Windows Server non virtualizzato su un server per uso generalista (esistono casi edge dove la virtualizzazione è problematica), forse avete sbagliato blog.

Cos’è IPMI

Una descrizione generale di IPMI la trovate qui; la mia idea a riguardo, è che si tratti di una delle più misconosciute (sempre in ambito SMB) e utili funzionalità di gestione remota, molto più dei vari DRAC, iLO, IMM.

IPMI permette di controllare accensione/spegnimento della macchina, leggerne qualsiasi sensore, settare diverse impostazioni senza mai adoperare il BIOS (ad esempio, il device di boot), e ancora dialogare con il sistema operativo (o hypervisor di turno) tramite un’interfaccia dedicata out-of-band, seriale.

Come funzionalità OOB, IPMI non dipende dal software installato sulla macchina, né da eventuali agent.

Come si usa IPMI

Dovreste essere in grado di configurare completamente un server appena sballato senza mai collegarvi un monitor; sì, davvero.

Tutto quello di cui ha bisogno un server, oltre all’alimentazione, è una rete. Solitamente, le macchine provviste di IPMI hanno una porta ethernet dedicata al management; collegatela alla vostra rete, ed eseguendo

 ipmitool lan set 1 ipsrc dhcp 

IPMI verrà abilitato; basta rintracciare il lease per cominciare ad utilizzarlo.
Ad esempio, potremmo controllare se la nostra macchina è accesa con

 ipmitool -H ipmi_ip -U user -P password chassis power status 

e magari attivarla con

 ipmitool -H ipmi_ip -U user -P password chassis power on 

. Oppure, decidere di resettarla “elettricamente”:

 ipmitool -H ipmi_ip -U user -P password chassis power reset 

tutto senza mai toccare il tasto di accensione.
Controllare temperatura esterna e delle componenti, funzionamento delle ventole ed altri sensori hardware, è altrettanto semplice:

 ipmitool -H ipmi_ip -U user -P password sensor list 

e ora, una chicca: stufi di attendere il momento topico per premere F2, ESC &co per entrare nel bios dell’ultimo Proliant fiammante?

Ecco come impostare l’entrata automatica nel bios al successivo riavvio:

 ipmitool -H ipmi_ip -U user -P password chassis bootparam set bootflag force_bios 

Come avrete intuito, è possibile anche impostare qualsiasi dispositivo di boot tramite IPMI; il provisioning automatizzato tramite boot PXE impostato da IPMI è il metodo standard per la preparazione delle macchine utilizzate nelle server farm cloud.

SOL

Tutto molto bello, no? Ma eccoci arrivati alla funzionalità groundbreaking, “the real thing”; Serial-Over-Lan, o SOL per gli amici. In altri termini, redirezione della seriale via ethernet. Per la precisione, una porta seriale virtuale alla quale viene inviato l’output “video” del BIOS, dei vari controllers e del sistema operativo (se configurato opportunamente).

Adesso sapete come vengono fatti quei video in cui la fase di boot della macchina appare in un terminale: ve lo siete sempre chiesti, ammettetelo.

A titolo di esempio, ecco un video del boot di una mia macchina visto tramite SOL, una CentOS che fa da host per la virtualizzazione basato su KVM.

La SOL è uno strumento molto potente: possibile accedere al bios, quindi si può anche reinstallare da zero la macchina, e modificarne qualsiasi impostazione.

Non è tutto: come vedete alla fine del video, dopo il boot del sistema operativo si presenta anche il prompt di login… da questo, possiamo accedere alla macchina come faremmo in locale: costituisce a tutti gli effetti uno strumento di gestione out-of-band del sistema operativo, ovvero utilizzabile anche in caso la configurazione di rete del sistema sia per qualche motivo compromessa; ottimo per sperimentare con il networking, senza correre il rischio di essere tagliati fuori dalla gestione della macchina.

Tutti i principali OS/Hypervisor enterprise supportano pienamente la console seriale:

  • qualsiasi distribuzione di Linux può essere facilmente configurata per esporre una console seriale, basta seguire la documentazione della particolare distribuzione;
  • XenServer (il cui dom0 è Linux, naturalmente) include la voce “XenServer – Serial” nel menù di boot: rendetela default;
  • VMware ESXi può essere anch’esso facilmente configurato per la redirezione della console sulla porta seriale.

E AMT?

La Intel Active Management Technology è una tecnologia pensata per sistemi desktop e workstation, ma presente anche in diversi sistemi server. Alcune delle sue funzionalità si sovrappongono a quelle di IPMI e ne sono una evoluzione (sempre interessante vedere cosa riporta la wiki a riguardo), inoltre sono presenti grandi miglioramenti alla sicurezza, con un enforcing della cifratura TLS per le comunicazioni.
Avendo avuto modo di testare alcune sue caratteristiche, posso dire che la sintassi e le modalità di utilizzo delle funzionalità che mappano quelle classiche di IPMI via commandline (controllo status di alimentazione, ad esempio) sono abbastanza complesse rispetto alla controparte tradizionale.

Di contro, le funzioni per il provisioning automatico sono piuttosto avanzate, cosa che rende questa tecnologia parecchio idonea a deployment massivi nelle grandi enterprise.

AMT è pensato per essere utilizzato con software di management appositi, e il protocollo web-based sottostante è piuttosto complicato rispetto ad IPMI. Su piattaforma Linux vi consiglio amtterm, che fornisce una esperienza SOL-equivalente (notare che AMT include anche il KVM vero e proprio) con modalità molto user-friendly, mentre la tool wsmancli  consente di utilizzare appieno le funzionalità avanzate.

Alcuni produttori pensano di sostituire/affiancare AMT ad IPMI nel prossimo futuro; a mio avviso, come per l’interfaccia seriale (che adesso ha più di 40 anni!), lo zoccolo duro-legacy di IPMI rimarrà con noi ancora per diverso tempo…

Sopravvivere al velociraptor che cancella la tua tesi di laurea lanciando banane

Ovvero, come combinare insieme GIT e SSH per rendere (quasi) impossibile perdere un file.

In questi giorni c’è stato tanto rumore mediatico riguardo alla violazione di account iCloud contenenti dati personali, e non sono mancate brecce in altri noti sistemi poco tempo addietro.

I sistemi cloud proposti al mercato consumer per l’archiviazione dei dati da qualche altra parte hanno conosciuto una crescita incredibile negli ultimi anni, grazie e sopratutto al mercato mobile che ha posto l’accento sulla possibilità di guasti/furti del dispositivo: un cellulare è intrinsecamente più rubabile e danneggiabile di un PC desktop.

Mi sembra incredibile e sopratutto inaccettabile che a 42 (!) anni dalla nascita di SCCS si possano ancora perdere dei dati per l’ignoranza e/o l’incuria dell’operatore; ho visto parecchi miei conoscenti disperarsi di fronte a files corrotti, modifiche involontarie ma ormai salvate…

Gli attuali sistemi di cloud storage come Dropbox, iCloud, Google drive ed altri (mi riferisco sempre a prodotti consumer) limitano molto la problematica, ma permangono delle criticità.

Privacy

Dove sono i miei dati? Chi ha i miei dati? Qualcuno fa analisi statistica/rivende metadati sui miei files? È possibile che io non possa più fisicamente accedere ai miei dati?

Limitazioni/Costi

Molti servizi offrono account gratuiti, ma in genere lo spazio disponibile è parecchio limitato… inoltre, vengono imposte delle limitazioni come il numero di repliche, la dimensione massima dei files, la tipologia di client (pensate ad iCloud!), l’accessibilità e la completa gestione gerarchica delle informazioni memorizzate. Esistono servizi enterprise-grade che superano buona parte di queste problematiche, ma i costi sono spesso proibitivi; Amazon S3 in questo è forse il miglior compromesso.

Condivisione

La possibilità di far partecipare altri utenti al proprio repository di files è spesso parecchio limitata, a meno di non condividere direttamente l’account (ORRORE!). In generale, questi servizi si prestano poco a lavori in team perché non hanno modo di gestire modifiche concorrenti ad uno stesso file, spesso è necessario fare una copia locale delle informazioni interessate e poi processare nuovamente tutto a cose fatte… parecchio inefficiente! Si può fare di meglio.

Retrospettiva

La mia risposta a questi requirements, viene dal passato: GIT, SSH, un po’ di shell aliasing. Strumenti affidabili, collaudati da generazioni di sviluppatori nel tempo, e sopratutto adatti ad un uso professionale… che oggi possiamo utilizzare anche per esigenze personali, dati i giganteschi passi avanti fatti da elaboratori alla portata di tutti.

È molto significativo notare come si spaccino per novità delle conquiste tecnologiche vecchiotte: il “cloud computing” nasce negli anni ’60 con i mainframe IBM (avete presente tn3270 che accede ad ISPF? No?), i sistemi di controllo versione datano prima del 1975, telnet era disponibile già nel ’68.

Oggi è tutto parecchio più comodo, maturo e sicuro; il problema è semmai che l’allargamento della base di utenza anche ad analfabeti (non solo) informatici ha portato ad un deciso livellamento verso il basso delle interfacce utente, che richiedono sempre meno apprendistato e al contempo nascondono la grandissima parte delle tecnologie sottostanti alle finestre sbrilluccicose.

Requisiti

Parlando di GIT, molti sviluppatori che mi leggeranno lo assoceranno al servizio GitHub; bene, quel che propongo io e di fare quello che fa GitHub lato server: diventare GitHub, diventare il servizio, per avere pieno controllo sul posizionamento e la gestione dei nostri dati.

Ecco la lista della spesa:

  •  Due o più macchine con sistema POSIX o quasi-POSIX (Linux, UNIX, BSD, Mac OS X vanno benissimo); se siete dei temerari, anche Windows con CGYWIN. Nelle macchine dovranno essere installati ssh server e client, oltre ad ovviamente GIT ed una shell POSIX o similare a vostra scelta (io uso ZSH).
  •  Una configurazione del network che vi permetta di raggiungere mutuamente le macchine su una porta a vostra scelta, anche attraverso NAT e reindirizzamenti vari va bene. Anzi, è consigliato: cambiate la porta di default per ssh. Fatelo. Punto. Riconfigurate le regole del firewall di conseguenza.
  • La capacità di non cominciare a scrivermi commenti stile “cosa è Linux?”, “non ho mai usato GIT, come si fa un commit? Cosa è un branch?”, “Ma io ho android”, “eh la peppa, io uso razzomissileOS e funziona tutto più meglio assai di quello che scrivi tu”: per informarvi su queste cose ci sono DOC e wiki ufficiali, io sto scrivendo di una metodologia per combinare insieme degli strumenti in un determinato scenario… per creare uno strumento nuovo.

Che lo spirito del RTFM vi accompagni sempre.

Uno sguardo d’insieme

Supposto quindi che sappiate usare GIT e siate anche dei sysadmin UNIX/Linux discretamente in allenamento, passiamo alla descrizione di alto livello di ciò che faremo.

Presa una cartella contenente dei files nella nostra macchina, l’idea è che grazie a GIT ogni cambiamento del quale faremo un “commit” verrà registrato come “istantanea” di tutti i file presenti nella cartella (sto semplificando, possiamo aggiungere file che si trovano ovunque ovviamente): questa istantanea sarà anche corredata di un commento esplicativo dei cambiamenti effettuati, così da avere una storyline di tutto il nostro progetto.

Inoltre, ed è questo il pezzo interessante, tutto questo repository contenente sia i file all’ultima versione sia tutte le versioni degli snapshots precedenti all’attuale sia tutti i commenti esplicativi alle varie revisioni, verrano replicati su N macchine remote. Naturalmente, sarà anche possibile clonare tutto il repository da queste macchine per generare sia delle nuove cartelle di lavoro, sia dei nuovi repository master dai quali poter clonare tutto, ecc ecc. E questo, su qualsiasi dispositivo che abbia GIT ed accesso ad uno qualsiasi fra i servers.

La connessione fra server e client, sulla quale opererà GIT, verrà incapsulata dentro il protocollo SSH utilizzato tramite scambio di chiavi asimmetrico di chiavi RSA (niente ID-password, grazie!). E tutta questa procedura verrà automatizzata, in modo da ridursi a un semplice comando, quantomeno per l’upload dei cambiamenti; leggi: “per pararsi il culo da perdite di dati”.

Essendo il flusso di dati criptato tramite RSA, a meno di non fare delle fesserie nella config e di cambiare periodicamente le chiavi RSA (la crittografia asimmetrica è soggetta ad attacchi di tipo statistico, se le chiavi si usano a lungo), il sistema è utilizzabile anche da sistemi separati dalla WAN (su internet, ecco). Pensate al computer di casa e quello dell’ufficio, per esempio. O un altro pc da qualche altra parte del mondo, cambia nulla.

Implementazione

Passiamo alla realizzazione pratica: chiameremo A-server la macchina server e B-client la macchina client (indicherò con A-server e B-client anche gli IP/nomi_dns delle macchine): il server conterrà il repo sul quale pusheremo le modifiche, il nostro backup insomma, che potremmo anche clonare in altre macchine; il repository sul server sarà di tipo bare repo, cioè conterrà i files codificati nei vari snapshots, ma nessuna cartella di lavoro per l’utente.

Il client, oltre alla propria copia locale del repository, contenente tutto quanto è presente nel bare repo (ma nella cartella locale nascosta .git), e ANCHE la cartella di lavoro (che tecnicamente è una copia dell’ultimo snapshot).

Usiamo repository bare sul server per risparmiare spazio manca l’ulteriore clone dell’ultimo snapshot, detto “working tree“.

Warning!

Questo non è un howto per utenti della prima ora, quindi molti passaggi che sono dipendenti dall’implementazione e del vostro sistema operativo verranno omessi: descrivo COSA fare, ma non COME fare; se avete letto una RFC nella vostra vita (o un libro di analisi matematica), non dovreste avere problemi.

SSH pairing

Per prima cosa, dobbiamo permettere alle due macchine di comunicare fra loro, naturalmente via ssh, senza dover inserire ogni volta username e password: a tale scopo, permetteremo il collegamento tramite pairing di chiavi RSA. Creiamo le chiavi sul client; accediamo ad essa e nel terminale digitiamo:

 user@B-client: ssh-keygen -t rsa 

L’output confermerà la creazione. Creiamo quindi la cartella di destinazione sul server

 user@B-client: ssh user@A-server mkdir -p .ssh 

e trasferiamo la chiave appena creata

 user@B-client: cat .ssh/id_rsa.pub | ssh user@A-server 'cat >> .ssh/authorized_keys' 

assegnando i permessi corretti

 user@B-client: ssh user@A-server "chmod 700 .ssh; chmod 640 .ssh/authorized_keys" 

verificate che sia possibile effettuare il login senza inserire credenziali.

Creazione dei repo

Creiamo quindi il repo in una cartella della macchina A-server; dopo esserci loggati in essa e aver creato la cartella /path/to/repo_server/, eseguiamo:

 user@A-server: git init --bare /path/to/repo_server/ 

Questo sarà il nostro repository remoto. La configurazione sul server, ammesso di aver configurato correttamente ssh, firewall e il resto del networking, finisce qui… quindi, passiamo sul client! Creiamo il repository sul client, esattamente come fatto sul server:

 user@B-client: git init /path/to/repo_client/ 

e adesso, recidiamo il nodo gordiano: aggiungiamo l’origine remota al nostro repository. Ciò risponde alla domanda, “dove verrano mandati dati” da parte del·

client (che, ricordiamolo, è il sistema sul quale lavoriamo e del quale vogliamo avere un backup distribuito). Notare che nella riga sottostante sto usando una porta diversa dalla standard per ssh:

 user@B-client: git remote add A-server ssh://user@A-server:60001/path/to/repo_server/ 

Adesso proviamo a creare un file, fare un commit e poi l’output di

 user@B-client: git push A-server 

dovrebbe confermare il funzionamento di quanto configurato, trasferendo gli elementi dal repo locale a quello remoto. Anche git status da ora in avanti terrà traccia dello status del repository remoto, segnalandovi quandi commit non avete ancora uploadato ecc. Una ulteriore conferma può essere data provando a clonare il repository remoto in locale:

 git clone user@A-server:60001/path/to/repo_server/ 

Automazione

Adesso che abbiamo un repository distribuito, possiamo aggiungere altri nodi-server o iniziare a cooperare con altri soggetti (anche non in LAN!) utilizzando il bare-repo come piattaforma per sviluppare qualsiasi progetto; ma sopratutto, possiamo rendere più ergonomico il funzionamento del sistema con dei piccoli aliasing (da mettere nel .bashrc, o ciò che usa la vostra shell in proposito) ad esempio possiamo syncare dei repo multipli remoti e/o locali, reindirizzando l’output dell’avvenuta (o meno) sincronizzazione ad un file di log:

 alias syncall='git push A-server 2>> /path/to/log.txt && git push B-server 2>> /path/to/log.txt && git push C-server 2>> /path/to/log.txt` 

un’altra cosa interessante, possono essere dei log arricchiti:

 alias glog='git log --stat --max-count=10' 

Qualche appunto pratico sulla sicurezza

Cambiate SEMPRE la porta di default di ssh. SEMPRE. È il servizio più attaccato su sistemi UNIX-like. Anche se siete su CentOS e dovrete metter mano alle policy di SELINUX, fatelo. E mettete una porta alta, non standard. Non disattivate SELINUX o il firewall, per carità; sono cose che si configurano una tantum e poi funzionano sempre, mentre un’intrusione potrebbe rovinarvi, per sempre.

Cambiate spesso le chiavi ssh se lavorate sulla rete internet. Ovviamente, non usate la stessa chiave per uploadare la nuova: fatevi un account a parte solo per queste operazioni, che usere solamente per cambio chiavi e compiti amministrativi: per i push in generale passa molta più roba, ed è attaccabile senza esagerate difficoltà se vi sniffano con una certa costanza. Magari un giorno scriverò anche di questo.

Data la delicatezza dello scambio chiavi, sarebbe opportuno eseguire la prima sincronizzazione stando fisicamente collegati (o almeno in LAN) con il server, se il repo contiene dati sensibili.

Tenere tutto su ambienti virtualizzati con vm generalmente scollegate/spente che si attivano alla bisogna è sempre consigliabile.