Tipo: real Trigger: SSH Connection refused su tutte le porte configurate, accesso console TTY disponibile Severity: High Tempo stimato: 30–60 minuti MITRE ATT&CK: —
Scenario#
Il server risponde (servizi attivi, es. n8n funzionante), ma SSH dà Connection refused su tutte le porte. La causa più comune è ssh.service in stato disabled — il servizio non riparte dopo un reboot. Possibile trigger: apt upgrade che sovrascrive sshd_config o resetta lo stato del servizio.
1. Triage — Cosa guardo subito#
- Verifica che il server risponda (ping, servizi HTTP)
- Testa SSH su tutte le porte configurate:
ssh -v barno@IP -p 2222 -i ~/.ssh/id_ed25519
ssh -v barno@IP -p 22 -i ~/.ssh/id_ed25519- Se
Connection refusedsu tutto → accedi alla console TTY da Hetzner - Abilita Rescue Mode da pannello Hetzner e riavvia
2. Procedura Rescue — Montare il disco#
Una volta nel rescue (root@rescue), il disco del server reale è visibile ma non montato.
# Verifica layout dischi
lsblk -f
# Il disco principale è già montato su /mnt/system (Hetzner lo fa in automatico)
# Se non lo fosse:
mount /dev/sda1 /mnt/systemTutto quello che modifichi in root@rescue senza chroot tocca solo il sistema rescue in RAM, NON il tuo Ubuntu reale su disco.
Entra nel sistema reale via chroot:
chroot /mnt/system /bin/bashOra sei dentro il tuo Ubuntu come se fossi in locale.
3. Analisi — Cosa cerco#
# Controlla la config SSH
cat /etc/ssh/sshd_config | grep -E "Port|PasswordAuth|PubkeyAuth|PermitRoot|KbdInteractive"
# Verifica utenti e chiavi
cat /home/barno/.ssh/authorized_keys
ls -la /home/barno/.ssh/Problemi comuni trovati:
| Problema | Sintomo | Fix |
|---|---|---|
ssh.service disabled | Connection refused dopo reboot | systemctl enable ssh |
KbdInteractiveAuthentication no | Password rifiutata silenziosamente | Cambiare a yes o usare chiave |
| Porta rimossa da config | Connection refused su porta specifica | Aggiungere Port XX in sshd_config |
4. Fix — Dentro il chroot#
# Modifica sshd_config
nano /etc/ssh/sshd_configConfigurazione finale sicura:
Port 2222
PermitRootLogin no
PubkeyAuthentication yes
PasswordAuthentication no
KbdInteractiveAuthentication noPrima di disabilitare PasswordAuthentication, verifica sempre che la chiave SSH funzioni da un secondo terminale aperto in parallelo.
# Reset password utente (dentro chroot)
passwd barno
# Verifica sintassi config
sshd -t5. Uscita dal Rescue e verifica#
# Esci dal chroot
exit
# Da pannello Hetzner: disabilita Rescue Mode e riavviaDopo il reboot, dal server reale:
# Abilita SSH permanente (parte sempre dopo reboot)
sudo systemctl enable ssh
sudo systemctl restart ssh
# Verifica stato
sudo systemctl status sshTest finale dal Mac:
ssh barno@IP -p 2222 -i ~/.ssh/id_ed25519_hetzner6. Hardening post-accesso#
# Controlla accessi riusciti
sudo journalctl -u ssh | grep "Accepted"
# Controlla tentativi falliti
sudo lastb -20
sudo last -20
# Verifica unità in errore
systemctl list-units --failed
# Password root robusta (20+ caratteri, salvata nel password manager)
sudo passwd rootTieni sempre aperto un secondo terminale SSH mentre modifichi sshd_config. Se qualcosa va storto, hai ancora accesso per correggere.
Falsi positivi possibili#
- I tentativi di login da IP esteri in
lastbsono quasi sempre bot automatici che scansionano internet — non sono hack se tutti i tentativi sono falliti - La riga
ssh.service disablednon significa che SSH non funziona ora, ma che non si avvia automaticamente al boot
IoC identificati#
Nessuno — non è stato rilevato accesso non autorizzato. Tutti i login in last provenivano da IP italiani dell'utente.
Causa root#
ssh.service in stato disabled — probabilmente impostato così durante la configurazione iniziale del server o dopo un apt upgrade. Il servizio non ripartiva automaticamente dopo i reboot.
