WardtermClient SSH
IT
Scarica

Come disabilitare l'accesso con password in SSH

Prima verifica che l'accesso con chiave funzioni e tieni una sessione aperta. Poi crea /etc/ssh/sshd_config.d/00-no-passwords.conf con PasswordAuthentication no e KbdInteractiveAuthentication no, esegui sudo sshd -t, ricarica il servizio e controlla il risultato con sudo sshd -T. Modificare solo sshd_config spesso non ha effetto, perché vince un file drop-in precedente.

Aggiornata il . Eseguito su OpenSSH 10.0 su Debian 13 con un client su macOS, compresi l'annullamento da parte del drop-in, il login con password tramite keyboard-interactive e sshd che si ferma davanti a un file errato.

Prima di cambiare qualsiasi cosa

Dimostra che una chiave funziona. Questo comando prova solo le chiavi, quindi una password non può nascondere un problema:

ssh -o PreferredAuthentications=publickey user@server

Non hai ancora una chiave? Genera una chiave SSH Ed25519 e mettila prima sul server.

Controlla che questo account possa usare sudo, e tieni aperta una sessione fino all'ultimo passo. Nel nostro test le sessioni esistenti sono andate avanti dopo un reload, quindi quella sessione è la tua via di rientro se le nuove impostazioni ti chiudono fuori. Se il tuo provider ha una console web, trovala adesso.

Vedi cosa è in vigore oggi

sudo sshd -T | grep -iE '^(passwordauthentication|kbdinteractiveauthentication|usepam|permitrootlogin) '

sshd -T stampa i valori che sshd usa davvero dopo aver letto tutti i suoi file. Fidati di questo, non di quello che leggi in sshd_config.

Perché modificare sshd_config spesso non serve a nulla

Per la maggior parte delle impostazioni, sshd usa il primo valore che trova. Sulle versioni attuali di Debian e Ubuntu, la riga Include /etc/ssh/sshd_config.d/*.conf è vicino all'inizio di sshd_config, quindi i file drop-in vengono letti per primi, in ordine di nome. Controlla il tuo:

grep -n Include /etc/ssh/sshd_config
ls /etc/ssh/sshd_config.d/

Le immagini cloud spesso contengono un file come 50-cloud-init.conf con PasswordAuthentication yes. Abbiamo provato proprio questo caso: con quel file presente, impostare PasswordAuthentication no in sshd_config lasciava sshd -T ancora su yes.

Un file il cui nome viene ordinato per primo vince su tutti, ed è per questo che il nome qui sotto inizia con 00. Se non c'è una riga Include, come nei server più vecchi di OpenSSH 8.2 o con un file personalizzato, metti le impostazioni nello stesso sshd_config, sopra qualsiasi blocco Match, e rimuovi le righe precedenti che le impostano.

Crea il file drop-in

sudo tee /etc/ssh/sshd_config.d/00-no-passwords.conf >/dev/null <<'EOF'
PasswordAuthentication no
KbdInteractiveAuthentication no
PermitRootLogin prohibit-password
EOF

KbdInteractiveAuthentication deve essere disattivata anche lei. Con solo PasswordAuthentication no e questa impostazione attiva, il nostro server di prova accettava ancora la password dell'account, perché PAM la chiede tramite keyboard-interactive. Prima di OpenSSH 8.7 l'opzione si chiamava ChallengeResponseAuthentication, e il vecchio nome funziona ancora come alias.

UsePAM può restare yes. PAM gestisce anche i controlli dell'account e la preparazione della sessione, e con le due righe qui sopra non offre più la richiesta della password. Alcune distribuzioni sconsigliano di disattivarlo, quindi lascialo com'è.

PermitRootLogin prohibit-password permette a root di entrare solo con una chiave. Usa no se nessuno deve entrare come root. Fino a OpenSSH 10.0, sshd -T mostra prohibit-password con il suo nome più vecchio, without-password.

Prova il file, poi ricarica

sudo sshd -t
sudo sshd -T | grep -iE '^(passwordauthentication|kbdinteractiveauthentication) '

sshd -t non stampa nulla quando la configurazione è valida. Non saltarlo: abbiamo inviato il segnale di reload a uno sshd con una riga non valida in un file drop-in, ed è terminato, lasciando nulla in ascolto per le nuove connessioni.

sudo systemctl reload ssh     # Debian, Ubuntu
sudo systemctl reload sshd    # RHEL, Fedora, Arch

Preferisci reload a restart. Un reload chiede solo allo sshd in esecuzione di rileggere la configurazione, e la nostra sessione aperta lo ha superato. Su Debian 13 il file del servizio esegue anche sshd -t prima di inviare il segnale, quindi un file errato blocca lì il reload, ma non contare sul fatto che ogni distribuzione lo faccia.

Conferma da un altro terminale

Lascia stare la sessione aperta e prova un login con password dal tuo computer:

ssh -o PubkeyAuthentication=no -o PreferredAuthentications=password,keyboard-interactive user@server

Il risultato deve essere Permission denied (publickey). senza nessuna richiesta di password. Poi controlla che la tua chiave entri ancora con una nuova connessione. Solo allora chiudi la vecchia sessione.

Se compare ancora la richiesta della password

  • Esegui di nuovo sudo sshd -T. Se mostra yes, un altro file lo imposta prima: cerca con sudo grep -ri passwordauthentication /etc/ssh/.
  • Cerca un blocco Match. Può riattivare le password per alcuni utenti o indirizzi, e un semplice sshd -T non lo mostra. Passa i dettagli della connessione per valutarlo: 
    sudo sshd -T -C user=user,host=example.com,addr=203.0.113.10 | grep -i ^passwordauthentication
  • Controlla di raggiungere questo server e questa porta, e non un'altra macchina dietro lo stesso nome.
  • La richiesta della passphrase di una chiave non è una richiesta di password. Arriva dal tuo computer e sblocca la tua chiave.

Domande

Basta PasswordAuthentication no?

Non sempre. Con KbdInteractiveAuthentication attivo, PAM può ancora chiedere la password tramite keyboard-interactive. Spegnili entrambi.

Perché sshd_config dice no ma le password funzionano ancora?

Un file in /etc/ssh/sshd_config.d viene letto prima e vince. Controlla il valore in uso con sudo sshd -T.

Devo impostare UsePAM no?

No. PAM gestisce anche i controlli sull'account e le sessioni. Con le due impostazioni spente, non chiede più la password.

Fonti

Altro in Chiavi e accesso

Tutte le guide