När du försöker använda ssh för att komma i kontakt med en fjärrserver kan du få ett felmeddelande som inte visar någon matchande nyckelutbytesmetod innan du får ett förslag på vilken krypteringsalgoritm du vill använda. Du kommer inte att kunna ansluta till fjärrservern när du upplever felet. Denna process kan vara väldigt frustrerande, men felet är så vanligt att du ofta hittar Unix-typer som pratar om hur de upplever det och ger samma råd för att komma ut ur skogen.
Följande metoder för att åtgärda felet har testats på allt som ssh fungerar på, men du kommer sannolikt att hitta detta problem på Unix- och Linux-system. Du borde kunna använda samma process för att korrigera den om du kör ssh på Windows eller något exotiskt, men du kanske tycker att växlingsalternativen är något annorlunda.
Metod 1: Återkontakt av servern och regenereringsnycklar
Innan du gör något annat, se till att du kan reproducera felet. Ibland beror detta felmeddelande bara på att det finns en tjänst på fjärrsidan som för närvarande inte körs, vilket kan ha korrigerats under tiden. Medan vi körde ssh i en virtuell maskin som tillät anslutning till en falsk serveradress som var inställd på det dokumentationsgodkända exemplet.org, men du vill istället ersätta en riktig nätverksadress.
Om du fortfarande får den, försök sedan regenerera nycklarna med ssh-keygen -A från kommandotolken. Detta uppdaterar cachen som ssh-applikationen använder för att ansluta till fjärrservern. Spärra det kanske du vill försöka starta om ssh genom att köra service ssh starta om och ge det några ögonblick.
Om du fortfarande har problem, betyder det att servern och klienten aldrig kunde komma överens med rätt protokoll att använda. OpenSSH implementerar en svimlande mängd olika protokoll, men det inaktiverar ett antal av dessa eftersom de nu är kända för att vara komprometterade och därför osäkra. Du vill uppdatera alla ssh-paket vid servern i ekvationen, så se till att systemadministratören är medveten om vad som händer. Om det är din egen server kan du ta en stund att uppdatera dem.
Om detta inte är ett alternativ och du känner igen farorna med att använda en komprometterad algoritm, finns det ett sätt på klientsidan att kringgå detta felmeddelande.
Metod 2: Aktivera äldre alternativ i OpenSSH
Ta en titt på vad felmeddelandet läser efter orden Deras erbjudande: att se vilken algoritm fjärrservern föredrar. Medan de flesta system ska använda openssh7, som redan har inaktiverat den äldre föråldrade diffie-hellman-group1-sha1-tekniken, får du veta att du ska använda sha1 om de fortfarande sitter fast på openssh6 eller något liknande.
Springa ssh -oKexAlgorithms = + diffie-hellman-group1-sha1 testhost@example.org oavsett den faktiska nätverksvärden eller IP-adressen för fjärrservern är att åtgärda problemet på klientsidan. Om detta löser problemet letade det efter ett äldre sha1-baserat protokoll för att ansluta. Den här äldre sha1-baserade lösningen inaktiverades av goda skäl, men du kan kringgå den mer permanent genom att använda nano- eller vim-redaktörerna för att öppna ~ / .ssh / config-filen och lägga till raderna:
Värd exempel.org
KexAlgorithms + diffie-hellman-group1-sha1
Tänk på att du vill se till att plustecknet finns där eftersom det betyder att ssh kommer att läggas till istället för att ersätta de säkrare standardvärdena. När servern uppdaterar paketen använder du i de flesta fall säkrare protokoll.
Om du fick ett fel innan det nämnde ssh-dss-protokollet istället för sha1-versionen kan du istället prova det här kommandot följt av namnet på din värd: ssh -oHostKeyAlgorithms = + ssh-dss , som om det fungerar måste du redigera ~ / .ssh / config-filen igen. Efter värdraden lägger du till en flik och följande:
HostKeyAlgorithms + ssh-dss
Kom ihåg att precis som sha1-systemet har ssh-dss-nyckeln upphört för extremt rationella säkerhetsproblem associerade med det. Att använda detta kan införa sårbarheter i din anslutning, så det bör endast ses som en tillfällig fix om ens det. Se till att uppdatera servern så snart som möjligt.
3 minuter läst
