1 25/05/2026 9 min

Se vuoi sapere se SSH accetta davvero l’autenticazione via password, non basta leggere un singolo file di configurazione. Su molte macchine il comportamento effettivo dipende da più livelli: config globale, eventuali blocchi Match, impostazioni ereditate da distro o pannelli, e in alcuni casi anche da PAM e policy di hardening. Il punto è verificare lo stato effettivo, non quello teorico.

La domanda pratica è semplice: un utente remoto può entrare con password su questa porta SSH, in questo momento? Per rispondere in modo affidabile conviene controllare tre cose: la configurazione renderizzata da sshd, i log del demone e un test di autenticazione che non ti tagli fuori dalla sessione attuale.

Il controllo giusto parte dalla configurazione effettiva

Il parametro che ti interessa è PasswordAuthentication. Se vale yes, il server può accettare password; se vale no, la password è disabilitata a livello SSH. Però c’è un dettaglio spesso sottovalutato: sshd può applicare valori diversi per host, utente, gruppo o indirizzo sorgente tramite blocchi Match. Quindi il file principale non basta.

Il modo più rapido per vedere la configurazione che il demone sta realmente usando è questo:

sudo sshd -T | grep -i '^passwordauthentication\|^kbdinteractiveauthentication\|^usepam\|^pubkeyauthentication'

Se il comando restituisce passwordauthentication yes, la password è abilitata per il profilo globale corrente. Se restituisce no, è disabilitata. Qui non stai leggendo una supposizione: stai interrogando il parser di sshd.

Se vuoi essere più preciso e capire se un utente o un indirizzo specifico cade dentro un blocco Match, usa una variante con i parametri di contesto:

sudo sshd -T -C user=nomeutente,host=server.example.com,addr=203.0.113.10 | grep -i '^passwordauthentication\|^kbdinteractiveauthentication\|^usepam'

Questo è utile quando un hardening apparentemente corretto viene aggirato o limitato da una regola condizionale. È un caso classico con accessi per subnet, jump host o account amministrativi.

Dove guardare nel file di configurazione

Su molte distribuzioni la configurazione principale è in /etc/ssh/sshd_config, ma non fermarti lì. In ambienti moderni è frequente trovare frammenti in /etc/ssh/sshd_config.d/*.conf. Un override lì dentro può ribaltare il valore che hai visto nel file principale.

Controlla con:

grep -RniE '^(PasswordAuthentication|KbdInteractiveAuthentication|ChallengeResponseAuthentication|UsePAM|AuthenticationMethods|Match)\b' /etc/ssh/sshd_config /etc/ssh/sshd_config.d 2>/dev/null

Le righe da tenere d’occhio sono queste:

  • PasswordAuthentication yes|no: abilita o disabilita la password.
  • KbdInteractiveAuthentication yes|no: può incidere su flussi PAM e challenge-response.
  • UsePAM yes|no: se disattivato, in certi scenari la gestione dell’accesso cambia in modo sostanziale.
  • AuthenticationMethods: può imporre combinazioni che escludono la password come metodo singolo.
  • Match: può applicare eccezioni per utente, gruppo, host o indirizzo.

Una nota pratica: ChallengeResponseAuthentication è un nome ancora presente in molte guide vecchie, ma sulle versioni recenti il parametro rilevante è spesso KbdInteractiveAuthentication. Se stai leggendo documentazione datata, non dare per scontato che il nome del parametro sia quello giusto per la tua release.

Verifica i log prima di cambiare qualcosa

Se la password sembra disabilitata ma non sai perché, i log ti dicono se il rifiuto dipende da autenticazione, policy o da un errore di configurazione. Su sistemi con systemd puoi partire da:

sudo journalctl -u ssh -u sshd --since '15 min ago' --no-pager

Su alcune distro il servizio si chiama sshd, su altre ssh. Se non sai quale sia quello corretto, elenca i servizi disponibili:

systemctl list-units --type=service | grep -i ssh

Nei log cerca messaggi del tipo:

Failed password for <user> from <ip> port <port> ssh2
Authentication refused: bad ownership or modes for directory /home/<user>
User <user> not allowed because listed in DenyUsers
Connection closed by authenticating user <user> <ip> port <port> [preauth]

Il primo indica che la password è stata effettivamente tentata e rifiutata. Il secondo e il terzo non parlano di password in sé, ma di problemi di permessi o policy che impediscono l’autenticazione. È un errore comune confondere un blocco di accesso con la disabilitazione della password.

Test controllato senza perdere l’accesso

Non fare mai il test dalla stessa sessione da cui stai modificando SSH se c’è il rischio di tagliarti fuori. Apri una seconda shell e prova un login esplicito con password da un host di test o da un utente non privilegiato.

Il comando più diretto è:

ssh -o PreferredAuthentications=password -o PubkeyAuthentication=no nomeutente@server.example.com

Se il server accetta password, ti verrà chiesta la password dell’utente. Se invece ricevi un rifiuto immediato o il prompt non arriva mai, hai già una prima conferma che la password non è disponibile come metodo valido per quella sessione.

Per distinguere un problema di password da un problema di policy, lancia il client con verbosità alta:

ssh -vvv -o PreferredAuthentications=password -o PubkeyAuthentication=no nomeutente@server.example.com

Nell’output cerca indizi come Authentications that can continue: oppure Next authentication method: password. Se la password non compare tra i metodi disponibili, il problema è a monte rispetto alla digitazione della password stessa.

Leggi il comportamento di PAM senza fare assunzioni

Quando UsePAM yes è attivo, SSH può appoggiarsi a PAM per la logica di autenticazione e account management. In questo caso la password può essere formalmente abilitata in sshd, ma l’accesso può comunque fallire per policy PAM, lock dell’account, scadenza password o restrizioni locali.

Se vuoi capire se stai entrando in quel territorio, controlla i file PAM per SSH, spesso in /etc/pam.d/sshd:

sudo sed -n '1,200p' /etc/pam.d/sshd

Non serve memorizzare tutte le righe: cerca moduli come pam_unix, pam_faillock, pam_tally2, pam_access o policy custom. Se il problema è un blocco PAM, la password resta attiva come meccanismo SSH, ma l’account viene respinto a livello di stack autenticativo.

Un esempio tipico è un account bloccato per troppi tentativi falliti. In quel caso il log non dirà “password disabilitata”, ma qualcosa di più vicino a un rifiuto per lockout o account non valido. Verifica il file di log del sistema o i log di sicurezza secondo la distro: su Debian/Ubuntu spesso in /var/log/auth.log, su RHEL-like spesso in /var/log/secure.

Capire se la password è consentita ma non consigliata

Molti ambienti tengono la password abilitata per compatibilità, ma la scoraggiano in pratica tramite altre misure: MFA, AuthenticationMethods che richiedono combinazioni, restrizioni per subnet, o configurazioni che danno priorità assoluta alla chiave pubblica. Questo non è un dettaglio accademico: se stai facendo hardening, devi sapere se la password è davvero ancora un percorso valido o solo una fallback residuale.

Controlla se è presente una policy di questo tipo:

grep -RniE '^AuthenticationMethods\b' /etc/ssh/sshd_config /etc/ssh/sshd_config.d 2>/dev/null

Se trovi qualcosa come AuthenticationMethods publickey, la password non basta, anche se PasswordAuthentication yes è impostato. Se trovi publickey,password, la password è richiesta come secondo fattore o come secondo step, non come accesso autonomo.

Verifica portata e impatto prima di cambiare il valore

Se il tuo obiettivo è abilitare o disabilitare la password, il blast radius non è teorico: puoi bloccare gli accessi amministrativi, interrompere automazioni o lasciare aperta una superficie d’attacco non desiderata. Prima di toccare la config, identifica chi si autentica oggi con password e chi usa chiavi.

Per avere un quadro minimo puoi incrociare log e inventario account. Non serve uno script invasivo: spesso basta osservare gli ultimi tentativi di login e le chiavi registrate in ~/.ssh/authorized_keys sugli account critici. Se la macchina è gestita centralmente, verifica anche eventuali tool di provisioning o access broker che sovrascrivono sshd_config.

Se vuoi fare un cambio controllato, mantieni una sessione SSH già aperta, prepara un accesso alternativo e salva un backup della configurazione prima della modifica. Una copia semplice basta per il rollback:

sudo cp -a /etc/ssh/sshd_config /etc/ssh/sshd_config.bak.$(date +%F-%H%M%S)

Su sistemi che usano frammenti in sshd_config.d, conviene salvare anche i file interessati o usare il versioning del deploy, altrimenti il rollback è solo parziale.

Metodo pratico per dire “sì” o “no” senza ambiguità

Se vuoi una procedura sintetica, usa questa sequenza:

  1. Interroga il demone con sshd -T per vedere il valore effettivo di PasswordAuthentication.
  2. Se serve, ripeti il test con -C per simulare utente e indirizzo specifici.
  3. Controlla i file in /etc/ssh/sshd_config e /etc/ssh/sshd_config.d/ per override o Match.
  4. Leggi i log di ssh/sshd per distinguere rifiuto di password, blocco account o errore di policy.
  5. Esegui un login di prova con -o PreferredAuthentications=password per validare il comportamento reale.

Questa sequenza riduce il rischio di interpretare male una configurazione che sembra chiara ma non lo è. L’errore più frequente è fermarsi al file principale e ignorare gli override. Il secondo è confondere un blocco PAM con una password disabilitata.

Quando conviene disabilitare davvero la password

Dal punto di vista della sicurezza, su un server esposto a Internet la scelta più pulita è spesso disabilitare la password e tenere solo chiavi pubbliche, eventualmente con MFA o restrizioni aggiuntive. Questo riduce la superficie di attacco contro brute force e credential stuffing. Ma la decisione non va presa a occhi chiusi: se hai automazioni, utenti legacy o accessi di emergenza, devi progettare prima il percorso alternativo.

Se invece stai solo verificando lo stato, non cambiare nulla finché non hai un piano di rollback. In SSH il rollback può essere semplice, ma un errore di sintassi o un Match scritto male può impedire il riavvio del demone o cambiare il comportamento per interi gruppi di utenti.

Controllo finale: stato, sintassi e ritorno operativo

Prima di riavviare o ricaricare il servizio, valida la sintassi della configurazione:

sudo sshd -t

Se il comando non produce output, la sintassi è valida. Se restituisce errore, correggi prima di toccare il servizio. Poi ricarica in modo controllato secondo la policy della tua distribuzione:

sudo systemctl reload sshd

Dopo il reload, ripeti il test con sshd -T e un login di prova da una seconda sessione. Se la password deve essere abilitata, verifica che il prompt compaia e che il login funzioni. Se deve essere disabilitata, verifica che il client non proponga più quel metodo e che i log riportino il rifiuto atteso.

Assunzione operativa: i percorsi file citati valgono per la maggior parte delle distribuzioni Linux recenti; se la tua piattaforma usa un layout diverso o un pannello che rigenera SSH, il punto da chiudere è sempre lo stesso: leggere la configurazione effettiva del demone, non solo il file editato.