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

SSH: A autenticidade do hospedeiro não pode ser estabelecida

O que significa esta mensagem? Será isto um problema potencial? O canal não é seguro?

Ou é simplesmente uma mensagem padrão que é _ sempre_ apresentada quando se liga a um novo servidor?

Estou habituado a ver esta mensagem quando usava SSH no passado: Sempre introduzi o meu login com uma password da forma normal, e senti-me bem porque não estava a utilizar chaves privadas/públicas (o que é muito mais seguro do que uma password curta). Mas desta vez criei uma chave pública com ssh para a minha ligação ao bitbucket, mas ainda assim recebi a mensagem. Estou ciente de que a palavra-passe no final é uma medida de segurança diferente, suplementar, para a descodificação da chave privada.

Espero que alguém possa dar uma boa explicação para o significado desta mensagem de “autenticidade não pode ser estabelecida”.

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':

Respostas (7)

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

Está a dizer-lhe que nunca se ligou a este servidor antes. Se estava à espera disso, é perfeitamente normal. Se estiver paranóico, verifique o checksum/fingerprint da chave utilizando um canal alternativo. (Mas note que alguém que pode redireccionar a sua ligação ssh também pode redireccionar uma sessão do navegador web)

Se já se ligou a este servidor antes a partir desta instalação do ssh, então ou o servidor foi reconfigurado com uma nova chave, ou alguém está a falsificar a identidade do servidor. Devido à gravidade de um ataque “man-in-the-middle”, está a avisá-lo sobre essa possibilidade.

Seja como for, tem um canal encriptado seguro para alguém. Ninguém sem a chave privada correspondente à impressão digital 97:8c:1b:f2:6f:14:6b:5c:3b:ec:aa:46:46:74:7c:40 pode descodificar o que envia.

A chave que utiliza para se autenticar não está relacionada… não quererá enviar informação de autenticação para um servidor fraudulento que a possa roubar, pelo que não deve esperar quaisquer alterações dependendo se vai utilizar uma frase-chave ou uma chave privada para se autenticar. Simplesmente ainda não chegou tão longe no processo.

23
23
23
2016-08-10 11:42:38 +0000

Digamos que se encontra com alguém para trocar alguns segredos comerciais. O seu conselheiro diz-lhe que nunca conheceu essa pessoa antes e que ela pode ser uma impostora. Além disso, para as próximas reuniões com ele, o seu conselheiro já não o vai avisar. É isso que a mensagem significa. A pessoa é o servidor remoto e o seu conselheiro é o cliente ssh.

Não me parece paranóico verificar duas vezes a identidade da pessoa antes de partilhar segredos com ela. Por exemplo, pode abrir uma página web com uma fotografia dela e compará-la com a cara que tem à sua frente. Ou verificar o seu bilhete de identidade.

Para o servidor bitbucket, poderia usar um computador diferente e mais confiável e obter a fotografia do seu rosto a partir dele, e depois compará-lo com o que obtém no computador que está a usar agora. Use:

ssh-keyscan -t rsa bitbucket.org | ssh-keygen -lv -f -

Se o faces corresponder, pode adicionar a chave ao ficheiro e.g. ~/.ssh/known_hosts (localização padrão em muitas distribuições Linux) com:

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

e o cliente ssh não o avisará como já sabe her face. Ele irá comparar as caras sempre que você se conectar. Isto é muito importante. No caso de um impostor (por exemplo, um ataque man-in-the-middle), o cliente ssh irá rejeitar a ligação porque a face terá mudado.

5
5
5
2014-07-16 15:44:43 +0000

Tive simplesmente de criar o ficheiro de texto known_hosts em ~/.ssh

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

Depois de o fazer, adicionou o anfitrião e nunca mais vi a mensagem.

2
2
2
2014-12-16 08:23:53 +0000

Existe outra forma fácil Basta tocar num ficheiro “config” em /root/.ssh e adicionar o parâmetro StrictHostKeyChecking no Da próxima vez que fizer login num servidor, a chave rsa será adicionada aos hosts conhecidos_hosts e não irá pedir “sim” para confirmação de autenticidade

1
1
1
2012-05-05 23:52:02 +0000

Esta mensagem é apenas SSH dizendo-lhe que nunca viu esta chave de anfitrião em particular antes, por isso não é capaz de verificar verdadeiramente que se está a ligar ao anfitrião que pensa que é. Quando diz “Sim”, coloca a chave ssh no seu ficheiro de hosts conhecidos, e depois nas ligações subsequentes irá comparar a chave que recebe do host com a do ficheiro de hosts conhecidos.

Havia um artigo relacionado com o overflow da pilha mostrando como desactivar este aviso, https://stackoverflow.com/questions/3663895/ssh-the-authenticity-of-host-hostname-cant-be-established .

0
0
0
2017-11-04 13:51:11 +0000

Para além das respostas já dadas (nunca se ligou a este anfitrião antes), existe também a possibilidade distinta de nunca se ter ligado do anfitrião actual (a esse anfitrião); isto é apenas psicologicamente diferente; pensa que se está a ligar do anfitrião A (a B), enquanto que está realmente a tentar ligar-se do anfitrião X (a B). Isto pode, por exemplo, acontecer quando primeiro ssh-ed de A para X e depois do mesmo terminal tenta ssh para B pensando que ainda está em A.

0
0
0
2018-05-11 11:03:59 +0000

No meu caso a palavra-passe menos login não estava a funcionar devido às minhas permissões de directório pessoal porque alterei as definições por defeito. Finalmente, aqui está o que funcionou para mim. as minhas permissões do directório home são

/home/username

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

/home/username/.ssh

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

/home/username/.ssh/authorized_keys

-rw-r----- 1 username groupname 402 May 11 11:53 authorized_keys