Vraag "Voeg de juiste host-sleutel toe aan known_hosts" / multiple ssh host-keys per hostname?


Als ik probeer te ssh in een computer die ik bestuur, krijg ik de bekende boodschap:

@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@
@    WARNING: REMOTE HOST IDENTIFICATION HAS CHANGED!     @
@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@
IT IS POSSIBLE THAT SOMEONE IS DOING SOMETHING NASTY!
Someone could be eavesdropping on you right now (man-in-the-middle attack)!
It is also possible that a host key has just been changed.
The fingerprint for the RSA key sent by the remote host is
[...].
Please contact your system administrator.
Add correct host key in /home/sward/.ssh/known_hosts to get rid of this message.
Offending RSA key in /home/sward/.ssh/known_hosts:86
RSA host key for [...] has changed and you have requested strict checking.
Host key verification failed.

Ik heb inderdaad de sleutel veranderd. En ik las een paar dozijn postings die zeiden dat de manier om dit probleem op te lossen is door de oude sleutel van de te schrappen known_hosts het dossier.

Maar wat ik zou willen is dat SSH zowel de oude sleutel als de nieuwe sleutel accepteert. De taal in het foutbericht ("Add correct host key") suggereert dat er een manier moet zijn om de juiste host-sleutel toe te voegen zonder de oude te verwijderen.

Ik heb niet kunnen achterhalen hoe de nieuwe host-sleutel moet worden toegevoegd zonder de oude te verwijderen.

Is dit mogelijk, of is de foutmelding gewoon extreem misleidend?


121
2017-10-13 14:01


oorsprong


Dit is de host-sleutel die de fout genereert. Een host moet maar één sleutel hebben. Dit heeft niets te maken met client- of gebruikerssleutels. Heeft u één IP-adres dat tussen verschillende hosts zweeft of zoiets? - David Schwartz
In mijn geval weet ik dat ik in de nabije toekomst veel van de twee sleutels zal wisselen, terwijl ik met wat dingen aan het spelen ben. Het lijkt erop dat dit ook nuttig zou zijn in de ene IP met meerdere hosts situatie die u suggereert. Ik wil vooral weten of dit mogelijk is voor mijn eigen opleiding, afgezien van een specifieke praktische toepassing. - Samuel Edwin Ward


antwoorden:


  1. haal de rsa-sleutel van uw server:

    $ ssh-keyscan -t rsa server_ip
    # server_ip SSH-2.0-OpenSSH_4.3
    server_ip ssh-rsa AAAAB3NzaC1yc2EAAAABIwAAAQEAwH5EXZG...
    
  2. en op de client, voeg deze sleutel toe aan ~/.ssh/known_hosts:

    server_ip ssh-rsa AAAAB3NzaC1yc2EAAAABIwAAAQEAqx9m529...(the offending key)
    server_ip ssh-rsa AAAAB3NzaC1yc2EAAAABIwAAAQEAwH5EXZG...
    

126
2017-10-13 14:38



Dit werkte! Ik gebruik echter "HashKnownHosts", dus de vermelding leek een beetje misplaatst. Gelukkig wees ssh_config (5) mij op ssh-keygen (1), die verklaarde dat ik "ssh-keygen -H" kan gebruiken om de ongewiste items te hashen. Dank je! - Samuel Edwin Ward
Dit "werkt", maar u verifieert de sleutel niet, dus bent u kwetsbaar voor mitm-aanvallen ... - JasperWallace
@JasperWallace, zolang de eerste stap wordt gedaan via een beveiligde verbinding (bijvoorbeeld met behulp van localhost), zou het behoorlijk veilig moeten zijn, denk ik - ony
Is er een manier om alle typen sleutels van de server te verzamelen? Soms weet je niet of het RSA, DSA, ECDSA, RSA1 ... etc. zijn - Sopalajo de Arrierez
@SopalajodeArrierez dezelfde manpage zegt ook dat je typen met komma's kunt scheiden, doe dat ook ssh-keyscan -t rsa1,dsa,rsa,ecdsa,ed25519 server_ip - maar de enige reden om te vinden rsa1 en dsa sleutels is om servers te identificeren die moeten worden bijgewerkt / opnieuw geconfigureerd - kbolino


Verwijder de vermelding van bekende_hosts met behulp van:

ssh-keygen -R *ip_address_or_hostname*

Hiermee wordt de problematische IP of hostnaam verwijderd known_hosts bestand en probeer opnieuw verbinding te maken.

Van de manpagina's:

-R hostname
  Verwijdert alle sleutels die behoren tot de hostnaam van een bekend_hosts-bestand. Deze optie is handig om hash-hosts te verwijderen (zie de optie -H   bovenstaande).


74
2018-02-09 06:49



"hoe de nieuwe hostsleutel toe te voegen zonder de oude te verwijderen." - Samuel Edwin Ward
Dit is de beste oplossing! - Thomas Decaux
Hoe heeft dit 19 stemmen? Het komt niet in de buurt van het beantwoorden van de gestelde vraag .. - Molomby
Je vraag komt op de tweede plaats als ik googel voor "git ssh update host key automatically". Dit antwoord is wat ik zocht. Door een nieuwe vraag te openen met precies wat ik wil, kan deze als een duplicaat worden gesloten. - Jason Goemaat
Hostnaam werkt ook - damluar


Een heel eenvoudige manier is:

cp ~/.ssh/known_hosts ~/.ssh/known_hosts.bak

Bewerk dan bekendehosts om de originele sleutel te wissen en gebruik dan ssh naar de host met:

ssh name@computer

Het zal de nieuwe sleutel automatisch toevoegen; vergelijk dan de twee bestanden. Een programma zoals meld is een leuke manier om de twee bestanden te vergelijken. Voeg vervolgens de bestanden samen om ervoor te zorgen dat bekende_hosts beide sleutels bevatten

Mijn 'reden' om twee sleutels te houden is dat het bestemmingsysteem multiboot is, hoewel ik durf te zeggen dat er een manier is om de sleutels over de installaties te synchroniseren, het lijkt eenvoudiger om meerdere sleutels toe te staan.

BEWERK 2015/06

Ik zou nu moeten toevoegen dat ik het nog eenvoudiger vind [zolang de invoer herkenbaar is, normaal gezien van de hostnaam / het IP-adres, afgezien van het foutbericht dat verwijst naar zijn specifieke locatie];

  1. Bewerk bekende_hosts om # toe te voegen aan het begin van het 'oude' item in known_hosts tijdelijk
  2. Verbind [ssh met de host], ga akkoord met de prompt om de nieuwe sleutel 'automatisch' toe te voegen
  3. Bewerk dan bekende_hosts opnieuw om het # te verwijderen

Er is zelfs de optie HostKeyAlias ​​als in

ssh -o HostKeyAlias=mynewaliasforthemachine name@computer

vervolgens, nadat de ssh-client de nieuwe sleutel onder de alias heeft toegevoegd, kunt u bekende_hosts bewerken om de 'echte' hostnaam / het IP-adres voor de alias te vervangen of een verbinding maken met die incarnatie van die host met de aliasoptie evermore


16
2018-04-30 22:29



Dit 'meld'? meldmerge.org - Samuel Edwin Ward
dat is de meld :) apt-get / yum install naam is gewoon meld - Mark
Ik deed een variant op je suggestie die goed werkte - in plaats van cp, mv, dan ssh, dan cat ~ / .ssh / known_hosts.bak ~ / .ssh / known_hosts> tmp; mv tmp ~ / .ssh / known_hosts - Peter N Lewis


Ik heb hetzelfde probleem met een raspberry pi die ik opstart met verschillende systemen (dev-systeem voor het compileren van arm-binaries, project, xbmc, enz.) En die hetzelfde probleem zijn tegengekomen. Ze gebruiken DHCP op een lokaal netwerk en mijn router hergebruikt altijd hetzelfde IP-adres, omdat het MAC-adres hetzelfde was. Ik heb het opgelost door verschillende domeinnamen in mijn hosts-bestand te gebruiken:

10.10.10.110 pi-dev
10.10.10.110 pi-xbmc
10.10.10.110 pi-etc

Het bekende_hosts-bestand slaat vingerafdrukken op hostnaam op, ook al is het hetzelfde IP-adres, elke unieke hostnaam krijgt een ander item.

Toen ik een nieuw systeem gebruikte, kreeg ik het beu om de namen toe te voegen aan hosts-bestanden, dus kwam ik op een nog luie manier met behulp van voorloopnullen op ip-adressen zoals:

$ ssh pi@10.10.10.110
$ ssh pi@010.10.10.110
$ ssh pi@10.010.10.110

Elke variant van het (niet-geanicaliseerde) ip-adres krijgt zijn eigen vermelding in bekende_hosts.


7
2017-11-04 02:28



De OpenSSH-mensen werden wijs voor me, deze maas in de wet werkt niet meer in recentere versies. - Mike
Je kunt gebruiken CheckHostIP no in ~/.ssh/config om de maas in de wet te kunnen gebruiken. U kunt zelfs uw aliassen daar definiëren, zodat u niet hoeft te knoeien met /etc/hosts en definieer CheckHostIP no alleen voor deze 3 hostnamen. - GnP


Als zowel uw client als uw server OpenSSH 6.8 of nieuwer hebben, kunt u de UpdateHostKeys yes optie in uw ssh_config of ~/.ssh/config. Bijvoorbeeld:

Host *
    UpdateHostKeys yes

Hierdoor slaat SSH alle hostsleutels op die de server moet hebben known_hostsen wanneer een server één hostsleutel wijzigt of verwijdert, wordt de sleutel ook in uw account gewijzigd of verwijderd known_hosts.


2
2017-09-22 04:28



Dit is verreweg het meest bruikbare antwoord! Hoewel het niet expliciet een manier biedt om de oorspronkelijke vraag op te lossen als een hostsleutel al is gewijzigd, zijn alle andere antwoorden onveilig omdat ze de nieuwe hostsleutel niet verifiëren. Met deze optie kunt u veilig overschakelen naar nieuwe hostsleutels. - Jaap Eldering


Ik begrijp niet waarom je met twee sleutels wilt werken, maar je kunt zeker meer dan één geldige sleutel toevoegen aan de ~/.ssh/known_hosts bestand, maar u moet het handmatig doen.

Een andere oplossing zou kunnen zijn om de StrictHostKeyChecking=no optie voor deze specifieke host:

ssh -o StrictHostKeyChecking=no user@host

die je in je alias zou kunnen stoppen ~/.profile of iets dergelijks.

alias hc=ssh -o StrictHostKeyChecking=no user@host

1
2017-10-13 14:49



StrictHostKeyChecking lijkt in dit geval niet te helpen; blijkbaar specificeert het alleen het gedrag als de host niet in het bekende_hosts-bestand is. Hier genoemd: gossamer-threads.com/lists/openssh/dev/45349#45349 - Samuel Edwin Ward
Het werkt hier. U krijgt de waarschuwing, maar de login gaat verder. - Sven♦
Dat is raar. Gebruikt u wachtwoordverificatie? Gebruikt u OpenSSH? - Samuel Edwin Ward


als jij enkel en alleen ssh op een lokaal netwerk dan ...

Een eenvoudige oplossing is om het oude sleutelbestand te wissen en het te vervangen door een lege. Hiermee kunt u al uw verbindingen opnieuw autoriseren met nieuwe sleutels. Als u ssh-sleutels hebt opgeslagen voor sites buiten uw lokale netwerk, moet u ervoor zorgen dat uw eerste verbinding veilig is, zoals u deed toen u voor het eerst verbinding maakte met die server.

bv

cp known_hosts known_hosts.old
rm known_hosts
nano known_hosts

Druk vervolgens op spatie, backspace cntl + x en 'y' om de nieuwe buffer (bestand) op te slaan. Het is een slechte gewoonte, maar goed als je niet regelmatig buiten je lokale netwerk bent (bijvoorbeeld een uni of een werkserver)

Op een veilig lokaal netwerk is dit veilig omdat je simpelweg geen man in de middelste aanval kunt krijgen.

Het is altijd beter om code te gebruiken die u begrijpt!


0
2018-06-15 21:44



Het geheel afvegen known_hosts bestand zal elke keer de meeste beveiliging negeren die anders door ssh wordt geboden. - kasperd
Ik zou zelfs willen beweren dat het op een beveiligd intern netwerk veiliger is om uw code te begrijpen en de beveiliging te omzeilen dan om code zonder bedenkingen te kopiëren. Op een extern netwerk zou de situatie anders zijn. - Aaron


Zoveel antwoorden, maar zoveel antwoorden die de beveiliging opgeven door strikte hostcontrole volledig uit te zetten, of niet-gerelateerde hostinformatie te vernietigen of de gebruiker te dwingen interactief sleutels te accepteren, mogelijk op een later tijdstip, wanneer het onverwacht is.

Hier is een eenvoudige techniek waarmee je een strikte controle van je host kunt toestaan, maar de sleutel op een gecontroleerde manier bijwerkt, wanneer je dat doet verwachten het om te veranderen:

  • Verwijder de oude sleutel en update deze in één opdracht

    ssh-keygen -R server.example.com && \
        ssh -o StrictHostKeyChecking=no server.example.com echo SSH host key updated.
    
  • Herhaal met IP-adres (sen) of andere hostnamen als je ze gebruikt.

Het voordeel van deze aanpak is dat deze de server exact één keer gebruikt. De meeste versies van ssh-keygen lijken geen foutmelding terug te geven als de server die u probeert te verwijderen niet bestaat in het bekende hosts-bestand, als dit een probleem voor u is, gebruikt u de twee opdrachten achter elkaar.

Deze aanpak verifieert ook de connectiviteit en geeft een leuk bericht voor logs in de ssh-opdracht (die inlogt, de hostsleutel update en uitgangen SSH-hostsleutel bijgewerkt dan gaat het meteen weer weg.

Als uw versie van ssh-keygen een niet-nul-exitcode retourneert en u dit liever zonder fout, ongeacht of de vorige verbinding wilt afhandelen, gebruikt u gewoon de twee opdrachten achter elkaar, waarbij eventuele fouten in de opdracht ssh-keygen worden genegeerd.

Als u deze techniek gebruikt, hoeft u uw ssh-opdracht nooit te variëren of de hostcontrole uit te schakelen, behalve tijdens die ene ssh-opdracht. Je kunt er zeker van zijn dat toekomstige ssh-sessies zonder conflict zullen werken of een nieuwe sleutel expliciet moeten accepteren, zolang de bovenstaande ssh-opdracht foutloos is.


-1
2017-09-18 01:56





Ik had hetzelfde probleem.

Alles wat ik deed was sudo nano /home/user/.ssh/ host_allow en wist de sleutel.

Toen ik terugging naar de server, heeft het een nieuwe sleutel toegevoegd.


-3
2018-05-18 11:31



Wat meer informatie over waarom dit gebeurt zou nuttig zijn voor het antwoord. - Drew Khoury


Gebruik sed commando om de overtredende regel te verwijderen

OUTPUT: as show in above example
Offending key in /home/user/.ssh/known_hosts:86

Verwijder de regel 86 zoals vermeld in bekende hosts.

CODE: 
sed -i '86d' /home/user/.ssh/known_hosts

De volgende keer dat toegang wordt verkregen via ssh, zal het systeem automatisch een nieuwe sleutel toevoegen.

nieuwere versies van ssh

gebruik:

ssh-keygen -R <hostname|ip address>

Het zal de naam van de hostnaam verwijderen en een back-up van oud maken .known_host zoals known_hosts.old


-4
2018-06-14 05:47



"Maar wat ik zou willen, is dat SSH zowel de oude sleutel als de nieuwe sleutel accepteert." Je antwoord doet dit niet. - Samuel Edwin Ward