Errori di battitura nel terminale: quando il typo di un singolo carattere fa tutta la differenza del mondo
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_keysNotate 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 a .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.
John Toscano
Appassionato di Linux e della cultura open-source da vent’anni, continuo a fare del mio meglio per diffondere tale filosofia e soprattutto condividere la conoscenza.
C’è sempre qualcuno da qualche parte nel mondo che sta avendo un problema che tu hai già risolto e, condividendo la soluzione, puoi fare la differenza.
Se quel qualcuno sei tu, chiedi pure alla community. La trovi ovunque, ad esempio su reddit.com/r/italyinformatica, reddit.com/r/fedora, reddit.com/r/debian, reddit.com/r/ubuntu, reddit.com/r/archlinux, reddit.com/r/linux, sui forum specifici delle distro oppure sulle loro wiki.
Perchè nessun problema andrebbe risolto più di una volta.
[https://it.linkedin.com/in/john-toscano]
Se vuoi sostenerci, puoi farlo acquistando qualsiasi cosa dai diversi link di affiliazione che abbiamo nel nostro sito o partendo da qui oppure alcune di queste distribuzioni GNU/Linux che sono disponibili sul nostro negozio online, quelle mancanti possono essere comunque richieste, e su cui trovi anche PC, NAS e il ns ServerOne. Se ti senti generoso, puoi anche donarmi solo 1€ o più se vuoi con PayPal e aiutarmi a continuare a pubblicare più contenuti come questo. Grazie!
Hai dubbi o problemi? Ti aiutiamo noi!
Se vuoi rimanere sempre aggiornato, iscriviti al nostro canale Telegram.Se vuoi ricevere supporto per qualsiasi dubbio o problema, iscriviti alla nostra community Facebook o gruppo Telegram.
Cosa ne pensi? Fateci sapere i vostri pensieri nei commenti qui sotto.
Ti piace quello che leggi? Per favore condividilo con gli altri.
