Il typo, familiare occorrenza di chiunque lavori di fronte a una tastiera. Che sia un errore di battitura o una semplice distrazione, stiamo parlando di quegli errori piccoli e insignificanti che possono cambiare completamente il significato di comandi dati da terminale e dai quali nessuno è immune: se non ne avete visti mai fare a un certo collega, non avete atteso abbastanza.

L’argomento è uno di quelli di cui, probabilmente, non avreste mai pensato di leggere un articolo intero su un blog e di cui non ne sentivate nemmeno troppo la mancanza. Reputiamo, tuttavia, valga la pena parlarne almeno una volta perché, anche e soprattutto nel mondo tecnologico, le conseguenze che possono derivare da un banale e innocente errore, specie se si è su una shell di produzione, possono essere abbastanza serie.

Se non vi è mai capitato, complimenti: o siete un’anomalia statistica oppure la paranoia vi ha salvati, con un ravvedimento e conseguente correzione pochi secondi prima di premere INVIO.

Ebbene, nonostante la leggerezza che il titolo di questo articolo possa suscitarvi, l’approssimazione e l’imprecisione vostra o dei colleghi possono compromettere (con una adeguata dose di sfortuna associata) anche un’intera azienda. Pensate alla sovrascrittura di file non ancora backuppati, o dell’intera alberatura di backup magari proprio in fase di restore, o anche all’apertura eccessiva di un firewall verso range di IP errati e pubblici.

Non siete convinti? Quanti danni si possano fare, quindi, sbagliando uno o due caratteri durante una giornata lavorativa? Analizziamo qualche casistica.

Gli errori più comuni e innocui saranno probabilmente nelle mail e, in generale, nell’interazione con altre persone. Tali errori tendono a essere generalmente non consequenziali ma è pratica altrettanto comune comunicare via chat e, magari, scrivere un comando per un collega, che potrebbe non notare l’imprecisione o copiare velocemente ed eseguire il comando prima che la notiate e correggiate.

Facciamo qualche esempio:

[root@control1 ~]# ssh-keygen -l -f .ssh/id_rsa
3072 SHA256:Mzh7cirv7UoJmqwf2FiJd7ILlX8zM+cv3FdzFL2Jves root@control1.lab.local (RSA)
[root@control1 ~]# ssh-keygen -k -f .ssh/id_rsa
[root@control1 ~]# ssh-keygen -l -f .ssh/id_rsa
.ssh/id_rsa is not a public key file.
[root@control1 ~]#

Cos’è successo, qui? Ci serviva conoscere il fingerprint di una chiave ssh ma, invece dello switch -l, ci è partito un -k, che sta giusto di fianco sulla tastiera ma che ha una funzione completamente diversa e andrebbe a sovrascrivere la vostra chiave con tutt’altro file atto a tutt’altro scopo.

In un secondo, avete perso la chiave. Come noterete, il terzo comando che abbiamo dato usa nuovamente lo switch corretto -l per mostrarvi che quel file, che avete accidentalmente sovrascritto, non è più nemmeno una chiave privata: qualsiasi script automatizzato su quell’host che usi quella chiave per connettersi ad altri host dell’infrastruttura smetterà immediatamente di funzionare e potreste non accorgervene subito, o affatto. Ci si augura che quegli script non facessero nulla di importante.

Errori nella configurazione di whitelist/blocklist o generalmente regole firewall possono essere abbastanza impattanti (e raramente in senso positivo), così come possono essere devastanti rsync fatti con i path sbagliati (bastano uno / o un . nei posti sbagliati), per non parlare di tutte le situazioni peculiari che si possono andare a generare durante operazioni con i filesystem.

Ma andiamo avanti. Siete di fretta (notate un pattern?) e dovete aggiungere una chiave al file authorized_keys per permettere a un nuovo utente di connettersi a un certo bastion host. Per farlo, fate uso della comodissima redirezione bash (il >), come segue:

[root@control1 ~]# echo "ssh-ed25519 AAAAC3NzaC1lZDI1NTE5AAAAIBhv6yD2xDm1/hhKJ9wkaCfuawqqnJT4U2ln26pphfAA root@control1.lab.local" > .ssh/authorized_keys

Notate qualcosa di strano? Ebbene si, avete usato > e non >>, che ha un significato completamente diverso: volevate aggiungere la vostra riga alla fine del file e, invece, avete piallato tutto il file, che ora conterrà soltanto la riga da voi indicata. Improvvisamente, avrete perso la lista di chiavi memorizzate in precedenza, poiché questa lista conterrà adesso soltanto l’ultima che avete aggiunto.

Se aveste fatto un errore simile con l’/etc/fstab, avreste avuto un sistema non più avviabile e, se non ve ne foste accorti subito, la problematica sarebbe potuta venire fuori proprio durante altre criticità ben più serie, costringendovi a cambiare i vostri piani.

A volte, al netto di tentativi di recupero file eliminato non sempre agevoli o possibili (specie se li avete appena sovrascritti con altri dati), un backup o una snapshot possono essere l’unico modo per recuperare degli errori di questo tipo, ma non sempre la via d’uscita è agevole o indolore.

Il range di possibilità che possono concretizzarsi, comunque, diventa tanto più grande quanto più lo è la nostra immaginazione: dal riavvio di host sbagliati di produzione, all’eccessiva o insufficiente apertura di porte e privilegi, a cambiamenti alla configurazione DNS che creano immediato disservizio e missioni spaziali fallite, il disastro è dietro l’angolo e, se combinato con altre contingenze, il danno è presto fatto.

E va bene, magari non sarete voi a inviare per sbaglio delle mail a degli indirizzi in Mali che erano invece destinate al Pentagono (del resto, confondere .mil con .ml è tanto facile quanto passare da una vacanza esotica a una erotica) ma, come abbiamo visto, il potenziale di far danni è ampio e abbondante, e potrebbe non essere colpa del tutto vostra.