Cosa fa#
Protocollo crittografico per l'accesso remoto sicuro. Prima di SSH esistevano telnet e rlogin — trasmettevano tutto in chiaro, password inclusa. SSH risolve due problemi fondamentali: autentica che il server e' quello che dice di essere (anti man-in-the-middle), e cifra tutto il traffico.
TL;DR#
# Due problemi distinti:
1. Come so che il SERVER e' chi dice di essere? → known_hosts (TOFU)
2. Come il server sa che IO sono chi dico? → password o challenge-response
# Tre algoritmi in gioco (output reale ssh -v):
curve25519-sha256 → scambio chiavi DH effimero (PFS)
ssh-ed25519 → firma del server (verifica identita')
chacha20-poly1305 → cifratura datiHandshake completo — prima connessione#
sequenceDiagram
participant C as CLIENT (Kali)
participant S as SERVER (Bandit)
note over S: Coppia fissa:
private_key → segreto
public_key → condivisibile
C->>S: 1. TCP SYN
S->>C: TCP SYN-ACK
C->>S: 2. Negoziazione versioni e algoritmi
S->>C: Negoziazione versioni e algoritmi
S->>C: 3. public_key del server
note over C: SHA256(public_key) = fingerprint
"Are you sure? fingerprint: SHA256:xxx"
→ scrivi YES
→ salvato in ~/.ssh/known_hosts
C->>S: 5. DH effimero — parametro pubblico client
S->>C: DH effimero — parametro pubblico server
note over C,S: Entrambi calcolano la stessa chiave simmetrica
senza trasmetterla → PFS
C->>S: 6. SSH2_MSG_NEWKEYS — "da qui tutto cifrato"
note over C: 7. Autenticazione client
(password o challenge-response)
C->>S: Credenziali
S->>C: 8. Shell aperta — ok
I due problemi che SSH risolve#
1. Man-in-the-middle — autenticazione del server#
Con telnet non sapevi se ti stavi connettendo al server giusto. SSH risolve questo con le chiavi host:
# ~/.ssh/known_hosts — esempio
ctf.labs.overthewire.org ssh-ed25519 AAAAC3NzaC1lZDI1NTE5...
# Se la chiave cambia → WARNING
@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@
@ WARNING: REMOTE HOST IDENTIFICATION HAS CHANGED! @
@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@Il warning non e' un errore — e' una protezione. Puo' significare:
- Server reinstallato (normale)
- IP riassegnato (normale)
- Attacco man-in-the-middle (raro ma possibile)
# Rimuovi la vecchia entry e riconnettiti per verificare il fingerprint
ssh-keygen -R hostname
ssh -v hostname2. Intercettazione del traffico — crittografia#
Telnet trasmette tutto in chiaro. SSH cifra con chacha20-poly1305 dopo aver concordato la chiave con Diffie-Hellman effimero (PFS).
Il fingerprint — cos'e' davvero#
# Prima connessione:
The authenticity of host 'ctf.labs.overthewire.org' can't be established.
ED25519 key fingerprint is SHA256:xxxxxx
Are you sure you want to continue connecting (yes/no)?fingerprint = SHA256(chiave_pubblica_del_server)
Non e' la chiave privata — quella non la vedi mai.
Non e' la firma — quella cambia ogni sessione (e' effimera).
E' un hash della chiave pubblica — stabile, verificabile, univoco.Scrivere yes significa: "ho visto questa chiave pubblica, me la ricordo".
Da quel momento known_hosts la confronta ad ogni connessione.
TOFU — Trust On First Use#
TLS: CA preinstallata nel OS → verifica automatica sempre
SSH: Prima volta → verifica manuale (sei tu il CA)
Dopo → known_hosts fa da memoriaCLIENT SERVER
| |
| ◄────────────────────────── public_key |
| |
| SHA256(public_key) = fingerprint |
| confronta con ~/.ssh/known_hosts |
| |
├── MATCH → connessione ok |
| |
└── MISMATCH → BLOCCO |
"WARNING: REMOTE HOST |
IDENTIFICATION HAS CHANGED!" |
possibile attacco MITM |Perfect Forward Secrecy#
curve25519 in SSH e' effimero come ECDHE in TLS:
Sessione 1: chiavi a1, b1 → chiave simmetrica K1 → scartata
Sessione 2: chiavi a2, b2 → chiave simmetrica K2 → scartata
Sessione 3: chiavi a3, b3 → chiave simmetrica K3 → scartataIl momento in cui entrambi i lati attivano la crittografia:
debug1: SSH2_MSG_NEWKEYS sent # "da qui tutto cifrato"Autenticazione con chiave — challenge-response#
sequenceDiagram
participant C as CLIENT
participant S as SERVER
C->>S: "voglio autenticarmi con la chiave pubblica X"
note over S: controlla ~/.ssh/authorized_keys
S->>C: challenge (numero casuale)
note over C: firma il challenge
con la MIA CHIAVE PRIVATA
C->>S: firma
note over S: verifica la firma
con la CHIAVE PUBBLICA
S->>C: ok, entra
Perche' un challenge casuale:
1. La chiave privata non si condivide mai
2. Potrebbe essere intercettata in transito
3. Una chiave privata sul server e' un rischio se il server viene violato
4. Replay attack: firma deterministica → stesso input = stesso output
Challenge casuale → firma diversa ogni volta → non riusabileLettura output ssh -v#
ssh -v bandit0@ctf.labs.overthewire.org -p 2220debug1: OpenSSH_10.2p1 # versione client
debug1: Reading configuration data /home/barno/.ssh/config # config personale
debug1: kex: algorithm: curve25519-sha256 # scambio chiavi DH effimero
debug1: kex: host key algorithm: ssh-ed25519 # firma del server
debug1: kex: cipher: chacha20-poly1305 # cifratura dati
debug1: SSH2_MSG_NEWKEYS sent # da qui tutto cifrato
debug1: Will attempt key: /home/barno/.ssh/id_rsa # prova chiavi locali
debug1: Trying private key: /home/barno/.ssh/id_rsa # nessuna trovata
# → fallback a passwordI tipi di chiave#
| Tipo | Comando | Sicurezza | Note |
|---|---|---|---|
ed25519 | ssh-keygen -t ed25519 | Alta | Moderno, consigliato |
rsa 4096 | ssh-keygen -t rsa -b 4096 | Alta | Piu' lento, compatibile |
ecdsa | ssh-keygen -t ecdsa | Alta | Curve ellittiche |
dsa | — | INSICURO | Non usare |
rsa 1024 | — | INSICURO | Non usare |
File critici#
Client side:
~/.ssh/id_ed25519 ← chiave privata (SEGRETO — chmod 600)
~/.ssh/id_ed25519.pub ← chiave pubblica (si condivide)
~/.ssh/known_hosts ← chiavi pubbliche dei server conosciuti
~/.ssh/config ← configurazione alias e opzioni
Server side:
~/.ssh/authorized_keys ← chiavi pubbliche autorizzate (chmod 600)
/etc/ssh/sshd_config ← configurazione del demone SSH
/etc/ssh/ssh_host_* ← chiavi host del serverConfronto SSH vs TLS#
SSH TLS
Scambio chiavi curve25519-sha256 X25519MLKEM768
Firma server ed25519 / known_hosts ECDSA / certificato CA
Fiducia TOFU CA preinstallata nel OS
Cifratura dati chacha20-poly1305 AES-256-GCM
PFS curve25519 effimero ECDHE effimero
Auth client challenge-response certificato client
Replay protection challenge casuale —Stesso problema, soluzione diversa per il nodo "fiducia": TLS delega a terzi (CA), SSH delega a te (known_hosts).
Scenario Reale Blue Team#
# Hardening sshd_config — configurazione minima sicura
PermitRootLogin no # impedisce login diretto come root
PasswordAuthentication no # forza chiavi, elimina brute forceUn attaccante che compromette un server potrebbe modificare la chiave host per intercettare le connessioni successive. Il warning MITM e' il primo segnale.
Non ignorare mai il warning MITM su server di produzione. Puo' essere un rekey legittimo dopo un aggiornamento — o un attacco reale. Verifica sempre il fingerprint con il sysadmin prima di procedere.
ssh -v e' il tuo strumento di debug principale per problemi di connessione. Mostra ogni step della negoziazione — utile per capire dove fallisce l'auth.
Dove l'ho incontrato#
- bandit-13 — primo uso di chiave privata SSH
- bandit-27 — clone git su porta SSH custom
Collegato a#
- iam — categoria
- crypto — categoria
- ssl-tls — stesso schema concettuale, implementazione diversa
- cryptography — teoria crittografica di base
- ssh — comando per la connessione
- ssh-key-authentication — concetto specifico sulle chiavi
- auth-log — dove SSH scrive i log di autenticazione
- pam — SSH delega l'autenticazione a PAM
