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

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.

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.

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.

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

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 .

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.

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