Le chiavi SSH DSA non funzionano più per l'autenticazione senza password

Dopo l'aggiornamento a Fedora 23, l'autenticazione senza password (basata su chiave pubblica) non funziona più in SSH: quando provo a SSH su un host, richiede la mia password sull'host remoto. Non riesco a farlo usare la mia chiave privata SSH. Tutto ha funzionato bene con Fedora 22.

La mia chiave pubblica è una chiave DSA ( ~/.ssh/id_dsa.pub). Sto usando OpenSSH 7.1 ( openssh-7.1p1-5.fc23.x86_64).

Come posso ottenere nuovamente l'autenticazione senza password per funzionare correttamente?

— DW
fonte

Dupe di superuser.com/questions/962918/… e (cross) unix.stackexchange.com/questions/247612/…

— dave_thompson_085

Grazie, @ dave_thompson_085. Questo non è un duplicato di superuser.com/q/962918/93541 . Questa domanda è chiedersi come usare ssh -Q. Questo sta chiedendo come risolvere un guasto di SSH. Ho trovato parte del materiale su superuser.com/q/962918/93541 e altrove utile per identificare questa soluzione, ma la risposta lì descrive come utilizzare ssh -Qe non risponde a questa domanda (ad esempio, non spiega come risolvere questo problema), quindi dal mio punto di vista non è un dup. Quello su Unix e Linux è molto simile; Vorrei averlo visto prima. Grazie ancora per i link!

— DW,

Ack, hai ragione. Li ho contrassegnati entrambi come "OpenSSH 7.0 no DSA" che nel primo caso non è abbastanza vicino. Scusate.

— dave_thompson_085,

Risposte:

Questo è il risultato dell'aggiornamento a OpenSSH 7.0. Come dicono le note sulla versione di OpenSSH 7.0 , "Il supporto per host ssh-dss e chiavi utente è disabilitato di default in fase di esecuzione".

La soluzione è aggiungere la seguente riga ~/.ssh/configsu ogni macchina client (ogni macchina su cui si esegue il client SSH):

PubkeyAcceptedKeyTypes=+ssh-dss

Se il server utilizza OpenSSH 7.0 o più recente, avrete anche bisogno di aggiungere questa linea a /etc/ssh/sshd_configsu ogni macchina server.

In alternativa, puoi generare una chiave SSH completamente nuova e aggiungerla al tuo file authorized_keys su ogni server a cui desideri accedere. Ti consiglio di usare RSA , per evitare problemi di compatibilità. Non consiglio ECDSA, poiché apparentemente gnome-keyring-daemon non rileva automaticamente le chiavi SSH di tipo ECDSA.

Nota editoriale: perché la gente di OpenSSH ha disabilitato le chiavi DSA? Non lo so. Per quanto ne so, non c'è nulla di sbagliato nella sicurezza delle chiavi DSA (ssh-dss). La pagina Web OpenSSH afferma che ssh-dss è debole, ma per quanto ne so, ssh-dss a 1024 bit non è più debole di RSA a 1024 bit e le chiavi RSA a 1024 bit non sono disabilitate.

— DW
fonte

La selezione del tipo di chiave viene discussa sulla sicurezza per qualche tempo. La sicurezza delle chiavi DSA è discutibile dall'inizio e meno sicura se non si dispone di un buon generatore casuale (di cui non si può essere certi). E poiché ora ci sono altri tipi di chiavi possibili da usare, non c'è motivo di trattenere quelli discutibili.

— Jakuje,

@Jakuje, sì, la selezione del tipo di chiave è discussa sulla sicurezza delle informazioni qui e qui . Ho letto tutto questo prima di scrivere la mia osservazione editoriale e rimango perplesso sul motivo per cui le chiavi DSA sono state disabilitate: non sono più deboli delle chiavi RSA della stessa lunghezza, che non sono state disabilitate. Non c'è nulla in nessuno di quei thread che indichi che DSA sia "discutibile" e, come dice Thomas Pornin, "non esiste alcun motivo di sicurezza per preferire un tipo a un altro, assumendo chiavi abbastanza grandi". (cont.)

— DW,

Vedi qui per una discussione più dettagliata.

— DW,

I miei due centesimi

Come .ssh/configfile di modifica per consentire questo sembra essere un'idea non così buona , suggerisco

Crea una nuova chiave, utilizzando lo strumento recente.

Quindi copia la nuova chiave pubblica (nella clipbord)
Accedi un'ultima volta usando la vecchia chiave:
```
ssh -i .ssh/id_dsa.pub -o PubkeyAcceptedKeyTypes=+ssh-dss user@host
```
Quindi aggiorna @hostil authorized_keysfile, aggiungendo il tuo nuovo pubkey e disconnettiti
```
cat >>.ssh/authorized_keys
```
paste, quindi Ctrl+D
Accedi con una nuova chiave usando la sintassi predefinita:
```
ssh user@host
```
1. Quindi aggiorna @hostil authorized_keysfile, rimuovendo il tuo vecchio pubkey (lo uso sed -e 1d -i .ssh/authorized_keysquando il mio vecchio pubkey è in linea 1con questo file).
2. Ti suggerisco di aggiornare il tuo server SSH se puoi.
3. disconnettersi

Verifica se la vecchia chiave non funziona più.

ssh -i .ssh/id_dsa.pub -o PubkeyAcceptedKeyTypes=+ssh-dss user@host
...
Permission denied...

Questo non deve funzionare ;-)

Puoi anche ricontrollare se tutto è a posto:
```
ssh user@host uptime
```

— F. Hauri
fonte

Non è ovvio per me il motivo per cui pensi che modificare ~/.ssh/confignon sia una buona idea.

— DW

Perché questo è deprecato e l'autore ssh raccomanda di non usare. Vedi openssh.com/legacy.html

— F. Hauri,

Oh capisco. Sembra che la tua preoccupazione non sia con l'idea di modificare di ~/.ssh/configper sé ma piuttosto con l'idea di consentire il DSA. Grazie per aver spiegato. Questo ha senso. (Penso di aver già affrontato nella mia risposta e nei miei commenti perché trovo sconcertante quella raccomandazione, ma non proverò a discuterne qui.)

— DW

La modifica .configti sshconsente di eseguire a lungo e persino di non usare algoritmi deboli . Usando -o Pubkey...dalla riga di comando, non perdonerai che c'è qualcosa da aggiornare .

— F. Hauri,