2012-05-05 23:39:28 +0000 2012-05-05 23:39:28 +0000
84
84

SSH: De authenticiteit van host kan niet worden vastgesteld

Wat betekent dit bericht? Is dit een potentieel probleem? Is het kanaal niet veilig?

Of is dit gewoon een standaardbericht dat altijd wordt weergegeven bij het maken van een verbinding met een nieuwe server?

Ik ben gewend om dit bericht te zien wanneer ik in het verleden SSH gebruik: Ik heb mijn login altijd met een wachtwoord ingevoerd op de normale manier, en ik voelde me er goed bij omdat ik geen gebruik maakte van privé/openbare sleutels (wat veel veiliger is dan een kort wachtwoord). Maar deze keer heb ik een publieke sleutel met ssh opgezet voor mijn verbinding met bitbucket, maar ik heb het bericht nog steeds gekregen. Ik ben me ervan bewust dat de passphrase prompt op het einde een andere, aanvullende veiligheidsmaatregel is, voor het ontcijferen van de private sleutel.

Ik hoop dat iemand een mooie verklaring kan geven voor wat bedoeld wordt met dit “authenticiteit kan niet worden vastgesteld” bericht. 

The authenticity of host 'bitbucket.org (207.223.240.181)' can't be established.

RSA key fingerprint is 97:8c:1b:f2:6f:14:6b:5c:3b:ec:aa:46:46:74:7c:40.
Are you sure you want to continue connecting (yes/no)? yes
Warning: Permanently added 'bitbucket.org,207.223.240.181' (RSA) to the list of
known hosts.
Enter passphrase for key '/c/Users/Steven/.ssh/id_rsa':
Bron

Antwoorden (7)

71
71
71
2012-05-06 00:23:59 +0000

Het zegt je dat je nog nooit eerder verbinding hebt gemaakt met deze server. Als je dat verwachtte, is dat volkomen normaal. Als je paranoïde bent, controleer dan de checksum/fingerprint van de sleutel met behulp van een alternatief kanaal. (Maar merk op dat iemand die je ssh-verbinding kan omleiden ook een webbrowsersessie kan omleiden.)

Als je al eerder verbinding hebt gemaakt met deze server vanaf deze installatie van ssh, dan is de server opnieuw geconfigureerd met een nieuwe sleutel, of iemand spooft de identiteit van de server. Vanwege de ernst van een man-in-the-middle aanval, is het een waarschuwing voor de mogelijkheid.

Hoe dan ook, je hebt een veilig versleuteld kanaal naar somebody. Niemand zonder de privé-sleutel die overeenkomt met de vingerafdruk 97:8c:1b:f2:6f:14:6b:5c:3b:ec:aa:46:46:74:7c:40 kan decoderen wat je stuurt.

De sleutel die je gebruikt om je te authenticeren is niet gerelateerd… je zou geen authenticatie informatie willen sturen naar een frauduleuze server die het zou kunnen stelen, en dus zou je geen veranderingen moeten verwachten afhankelijk van het feit of je een passphrase of privé-sleutel gaat gebruiken om in te loggen. U bent gewoon nog niet zo ver in het proces gekomen.
Bron
23
23
23
2016-08-10 11:42:38 +0000

Laten we zeggen dat je iemand ontmoet om wat zakengeheimen uit te wisselen. Je adviseur vertelt je dat je die persoon nog nooit ontmoet hebt, en dat het een bedrieger kan zijn. Bovendien, voor de volgende ontmoetingen met hem, gaat je adviseur je niet meer waarschuwen. Dat is wat de boodschap betekent. De persoon is de externe server, en je adviseur is de ssh-client.

Ik denk niet dat het paranoïde is om de identiteit van de persoon te controleren voordat je geheimen met haar deelt. Je zou bijvoorbeeld een webpagina kunnen openen met een foto van haar en deze vergelijken met het gezicht voor je. Of controleer haar identiteitskaart.

Voor de bitbucket server zou je een andere, meer vertrouwde computer kunnen gebruiken en de afbeelding van haar gezicht eruit halen, en die dan vergelijken met degene die je in de computer krijgt die je nu gebruikt. Gebruik: ssh-keyscan -t rsa bitbucket.org | ssh-keygen -lv -f -

Als de faces overeenkomen, kun je de sleutel toevoegen aan het bestand b.v. ~/.ssh/known_hosts (standaard locatie in veel Linux distributies) met: 

ssh-keyscan -t rsa -H bitbucket.org >> ~/.ssh/known_hosts

en de ssh client zal je niet waarschuwen zoals hij al weet haar gezicht. Het zal de gezichten vergelijken op elk moment dat je verbinding maakt. Dat is erg belangrijk. In het geval van een bedrieger (b.v. een man-in-the-middle aanval), zal de ssh client de verbinding weigeren omdat de face veranderd is.
Bron
5
5
5
2014-07-16 15:44:43 +0000

Ik hoefde alleen maar het known_hosts tekstbestand in ~/.ssh 

sudo vim ~/.ssh/known_hosts
sudo chmod 777 ~/.ssh/known_hosts

aan te maken Nadat ik dit had gedaan, voegde het de host toe en zag ik het bericht nooit meer terug.
Źródło
2
2
2
2014-12-16 08:23:53 +0000

Er is een andere gemakkelijke manier. Raak gewoon een “configuratie” bestand aan onder /root/.ssh en voeg de parameter StrictHostKeyChecking no toe. De volgende keer dat u inlogt op een server, wordt de rsa-sleutel toegevoegd aan bekende hosts en wordt er niet om een “ja” gevraagd voor de bevestiging van de authenticiteit.
Źródło
1
1
1
2012-05-05 23:52:02 +0000

Dit bericht vertelt u alleen maar dat SSH deze specifieke host-sleutel nog nooit heeft gezien, dus het is niet in staat om echt te verifiëren dat u verbinding maakt met de host die u denkt dat u bent. Wanneer je “Ja” zegt, wordt de ssh-sleutel in je bekende host-bestand gezet, en bij volgende verbindingen wordt de sleutel die het van de host krijgt vergeleken met die in het bekende host-bestand.

Er was een gerelateerd artikel over stack overflow waarin werd getoond hoe je deze waarschuwing kunt uitschakelen, https://stackoverflow.com/questions/3663895/ssh-the-authenticity-of-host-hostname-cant-be-established .
Источник
0
0
0
2017-11-04 13:51:11 +0000

Afgezien van de antwoorden die al gegeven zijn (u heeft nog nooit eerder verbinding gemaakt met deze host), is er ook een duidelijke mogelijkheid dat u nog nooit vanaf de huidige host (naar die host) verbonden bent; dit is alleen psychologisch anders; u denkt dat u verbinding maakt vanaf host A (naar B), terwijl u eigenlijk probeert te verbinden vanaf host X (naar B). Dit kan bijvoorbeeld gebeuren als u eerst van A naar X ssh-ed en dan van dezelfde terminal probeert te sshen naar B en denkt dat u nog steeds op A zit.
Источник
0
0
0
2018-05-11 11:03:59 +0000

In mijn geval werkte het wachtwoord minder login niet vanwege mijn home directory rechten omdat ik de standaard instellingen heb veranderd. Tot slot, hier is wat voor mij werkte. mijn home directory rechten zijn

/home/gebruikersnaam drwxr----x. 18 username groupname 4096 May 11 11:52 username

/home/gebruikersnaam/.ssh 

268823097 drwx------ 2 username groupname 29 May 11 11:53 .ssh

/home/gebruikersnaam/.ssh/authorized_keys 

-rw-r----- 1 username groupname 402 May 11 11:53 authorized_keys
Источник