ssh incapace di negoziare - nessun metodo di scambio chiave corrispondente trovato

Sto provando ad accedere al mio router DSL, perché ho problemi con la posta della riga di comando. Spero di poter riconfigurare il router.

Quando do il sshcomando, ecco cosa succede:

$ ssh enduser@10.255.252.1

Unable to negotiate with 10.255.252.1 port 22: no matching key exchange method found. Their offer: diffie-hellman-group1-sha1

così ho guardato questo post di stackexchange e ho modificato il mio comando in questo, ma ottengo un problema diverso, questa volta con le cifre.

$ ssh -oKexAlgorithms=+diffie-hellman-group1-sha1 enduser@10.255.252.1

Unable to negotiate with 10.255.252.1 port 22: no matching cipher found. Their offer: 3des-cbc

quindi c'è un comando per offrire la 3des-cbc crittografia? Non sono sicuro di 3des, ad esempio se voglio aggiungerlo permanentemente al mio sistema.

Esiste un comando per consentire il 3des-cbccodice?

Qual è il problema qui? Non sta chiedendo la password.

Questo particolare errore si verifica durante l'impostazione del canale crittografato. Se il sistema e il sistema remoto non condividono almeno un codice, non esiste un codice su cui concordare e non è possibile alcun canale crittografato. Di solito i server SSH offrono una manciata di cifre diverse per soddisfare diversi client; Non sono sicuro del motivo per cui il tuo server sarebbe configurato per consentire solo 3DES-CBC.

Ora, 3DES-CBC non è terribile. È lento e offre meno sicurezza rispetto ad alcuni altri algoritmi, ma non è immediatamente fragile finché le chiavi sono selezionate correttamente. La stessa CBC ha alcuni problemi quando il testo cifrato può essere modificato in transito, ma sospetto fortemente che la corruzione risultante sarebbe respinta dall'HMAC di SSH, riducendo l'impatto. In conclusione, ci sono scelte peggiori rispetto a 3DES-CBC e ce ne sono di migliori. Tuttavia, procedere sempre con cautela quando si ignorano le impostazioni predefinite relative alla sicurezza, comprese le scelte dell'algoritmo di cifratura e scambio di chiavi.Tali valori predefiniti sono i valori predefiniti per un motivo; alcune persone piuttosto intelligenti hanno speso un po 'di energia cerebrale considerando le opzioni e determinato che ciò che è stato scelto come predefinito offre la migliore sicurezza complessiva rispetto al compromesso delle prestazioni.

Come hai scoperto, puoi utilizzare -c ...(o -oCiphers=...) per specificare quale cifra offrire dal lato client. In questo caso l'aggiunta -c 3des-cbcconsente solo 3DES-CBC dal client. Poiché questo corrisponde a una cifra offerta dal server, è possibile stabilire un canale crittografato e la connessione procede alla fase di autenticazione.

Puoi anche aggiungere questo al tuo personale ~/.ssh/config. Per evitare di apportare una modifica globale per risolvere un problema locale, è possibile inserirlo in una Hoststanza. Ad esempio, se la tua configurazione SSH attualmente dice (esempio fittizio):

Port 9922

specificando una porta predefinita globale di 9922 anziché la 22 predefinita, è possibile aggiungere una stanza host per l'host che necessita di una configurazione speciale e una stanza host globale per il caso predefinito. Sarebbe diventato qualcosa come ...

Host 10.255.252.1
    Ciphers 3des-cbc
    KexAlgorithms +diffie-hellman-group1-sha1
Host *
    Port 9922

Il rientro è facoltativo, ma trovo che migliora notevolmente la leggibilità. Le righe vuote e le righe che iniziano con #vengono ignorate.

Se accedi sempre (o principalmente) allo stesso utente su quel sistema, puoi anche specificare quel nome utente:

Host 10.255.252.1
    Ciphers 3des-cbc
    KexAlgorithms +diffie-hellman-group1-sha1
    User enduser
Host *
    Port 9922

Non è necessario aggiungere una Host *stanza se non c'era nulla nella tua ~ / .ssh / config per cominciare, come in quel caso solo le impostazioni predefinite compilate o a livello di sistema (in genere da / etc / ssh / ssh_config) sarebbero Usato.

A questo punto, la riga di comando ssh per connettersi a questo host si riduce a semplicemente

$ ssh 10.255.252.1

e tutti gli altri utenti del sistema e le connessioni a tutti gli altri host dal sistema non sono interessati dalle modifiche.

Ok ho letto la manpage e l'ho capito.

Non volevo modificare il mio file di configurazione, quindi ho cercato il termine "cifratura" nella pagina man che mi mostrava l' -copzione; questo mi permette di specificare il tipo di crittografia. il comando end era quindi:

ssh -oKexAlgorithms=+diffie-hellman-group1-sha1 -c 3des-cbc enduser@10.255.252.1

Di recente ho riscontrato questo problema utilizzando PuTTY per connettermi a una versione più recente di Ubuntu. Sembra che le versioni precedenti di PuTTY non avessero cifrature aggiornate. Quindi il download dell'ultima versione di PuTTY ha risolto il problema. Potrebbe essere un'altra soluzione.

Un'altra risposta per MacOSX e CLI comamnds (SFTP, per esempio): fare riferimento a questo articolo @ http://www.openssh.com/legacy.html (Opzioni legacy OpenSSL). Stavo ottenendo un errore coerente di "Impossibile negoziare" che è stato risolto dalle informazioni in questo articolo, in particolare l'impostazione di un parametro di configurazione nel file "~ / .ssh / config".

A proposito, ho ricevuto questo errore quando il mio server SFTP di destinazione (non sotto la mia amministrazione) ha finalmente disattivato TLS 1.0 (opzione di crittografia SSL) e richiede TLS 1.1 o 1.2.