Comandi Linux e competenze della shell
ssh: la connessione che gestisce la tua infrastruttura
ssh non è una comodità, è il trasporto su cui si basa ogni operazione su ogni server e ~/.ssh/config è un contratto con te stesso futuro alle 3 del mattino. Alias host, voci IdentityFile, target ProxyJump e impostazioni keepalive trasformano le frasi di flag ricordate in comandi di una sola parola. I tunnel (-L, -R, -D) e il multiplexing ControlMaster sono ciò che trasforma "una shell" in una superficie di comando dell'infrastruttura ed entrambi sono lavori di file di configurazione, non di memoria.
Punti chiave
- Metti tutto in ~/.ssh/config: gli alias dell'host con User, IdentityFile, IdentitiesOnly yes e ProxyJump rendono 'ssh prod-web1' una parola; una frase di segnalazione digitata in modo identico cinque volte al giorno è una voce di configurazione mancante.
- Le chiavi sono l'unico gioco: ssh-keygen -t ed25519 -C 'role@team', metà pubblica di Authorized_keys e PasswordAuthentication no sul server una volta che la rotazione ha effettivamente dimostrato di funzionare.
- Gli host Jump sono compressi in un flag: ssh -J bastion.corp internal-host o ProxyJump bastion.corp nel blocco Host; i vecchi incantesimi ProxyCommand funzionano ancora e non sono più compito di nessuno.
- I tunnel sono specifici per lo scopo: -L 5432:db.internal:5432 per raggiungere un database, -D 1080 come shim SOCKS attraverso una rete rigorosa, -R per esporre un dev box locale, ciascuno associato a localhost a meno che non lo si allarghi esplicitamente.
- Il multiplexing di ControlMaster (ControlMaster auto, ControlPath ~/.ssh/cm-%r@%h:%p, ControlPersist 10m) interrompe la riesecuzione degli handshake a ogni apertura e consente il funzionamento multi-finestra su un host istantaneo.
- Keepalive mantiene le sessioni tramite NAT e interruzioni del firewall inattivo: ServerAliveInterval 60 più ServerAliveCountMax 3 lato client batte i misteriosi rapporti "sessione morta a 4 minuti" per la maggior parte del tempo.
- Limita l'accesso pericoloso: -N (nessun comando remoto) per port forwarding puri, -n per lavori batch che leggono da stdin e fail2ban più MaxAuthTries sani in modo che la forza bruta muoia nei log invece che negli account.
- L'ordine di debug è importante: ssh -vvv rivela l'analisi della configurazione, la negoziazione di autenticazione e gli errori del canale in quell'ordine e un dump dell'host -G risponde "perché ha scelto quella chiave e quell'utente" senza toccare un server.
Nota dal campo
Una volta ho disabilitato PasswordAuthentication prima che la nuova chiave fosse effettivamente in Authorized_keys e ho bloccato fuori il mio team per una sera. Il rituale ora: seconda sessione aperta, chiave funzionante e ServerAliveInterval nella configurazione in modo che le interruzioni NAT del bastione inattivo smettano di uccidere le sessioni.
Domande frequenti
In una frase ciascuno: -L, -R, -D?
-L trasporta una porta locale in avanti verso un servizio remoto, -R spinge indietro una porta remota verso la tua macchina (sai esattamente cosa hai esposto) e -D apre un proxy SOCKS dinamico attraverso la connessione.
La mia sessione si interrompe dopo alcuni minuti di inattività. Aggiustare?
La causa più comune è un timeout di inattività su un NAT o un firewall: impostare ServerAliveInterval sul client (e mantenere TCPKeepAlive sano sul server); la stessa correzione appartiene alla configurazione che usi per i salti del bastione nel seminterrato.
Chiavi ssh-agent o senza passphrase?
Agente, sempre: mantiene le chiavi decrittografate per sessione in modo che le chiavi mantengano le passphrase e l'automazione rimanga non interattiva; ForwardAgent sì su un bastione fidato va bene e ssh-add -l ti dice cosa è caricato prima di mentire a te stesso.
Come posso smettere di riscrivere le specifiche del tunnel?
Linee LocalForward e RemoteForward all'interno dei blocchi Host: 'ssh dbtunnel' quindi fa tutto; una voce per scopo mantiene il file leggibile e consente agli audit di vedere esattamente chi inoltra cosa.
Come Kinetikatech aiuta con comandi linux e competenze della shell
Lo abbiamo già risolto centinaia di volte: I comandi e le abitudini di scripting che decidono se un amministratore gestisce un server o lo combatte: cerca, trasforma, trasferisci e supervisiona testo e processi con gli strumenti presenti in ogni installazione di base. Con Sicurezza server Linux e Gestione server, ottiene il ciclo completo: valutiamo, implementiamo, vigiliamo 24 ore su 24 e rispondiamo in 30 minuti quando conta.