Por que o MBP 10.12 está usando uma chave ECDSA em vez da minha chave RSA?

Question

Esta questão pode pertencer à comunidade Ask Different, mas vou perguntar aqui, já que esta é mais uma questão unix.

Estou usando um MBP executando o OSX 10.12.4. Na minha janela de terminal, quando eu ssh para localhost, ele está usando uma "chave ECDSA". Eu tinha configurado uma chave RSA de antes, então não sei por que está tentando usar uma chave ECDSA. Eu nem sei o que é ECDSA e eu não sabia configurar uma chave com esse algoritmo. Se eu tentar conectar-me a outro servidor, ele estará usando meu RSA sem problemas.

Esta é a saída quando tento ssh para localhost:

$ ssh localhost
The authenticity of host 'localhost (::1)' can't be established.
ECDSA key fingerprint is SHA256:1234567.
Are you sure you want to continue connecting (yes/no)? no
Host key verification failed.

Esta é a saída quando tento enviar um ssh para um servidor remoto:

ssh hostname.domainname.com
The authenticity of host 'hostname.domainname.com (10.10.10.10)' can't be established.
RSA key fingerprint is SHA256:abcdefg. 
   (yes, the fingerprint different from ECDSA key above)
Are you sure you want to continue connecting (yes/no)?

Eu tinha configurado um cluster hadoop de nó único local que funcionava antes, mas aconteceu algo em que agora não consigo inicializar o cluster b / c Não consigo ssh para localhost. Eu apaguei todas as entradas no meu arquivo known_hosts que mencionou 127.0.0.1 ou localhost, mas ainda estou tendo problemas. No meu arquivo .ssh / config, não faço menção ao ECDSA.

Como faço para que meu laptop pare de usar o ECDSA ao conectar o host local? Como acabei usando o ECDSA? Qualquer ajuda é apreciada.

EDIT # 2: Quando executo ssh -v localhost , vejo algumas mensagens interessantes. Espero que alguém possa me ajudar a decodificar o que isso está dizendo porque não faz sentido para mim. Meu arquivo id_rsa está presente, mas diz que não é:

$ ssh -v localhost
OpenSSH_7.4p1, LibreSSL 2.5.0
debug1: Reading configuration data /Users/first.last/.ssh/config
debug1: Reading configuration data /etc/ssh/ssh_config
debug1: /etc/ssh/ssh_config line 53: Applying options for *
debug1: Connecting to localhost [::1] port 22.
debug1: Connection established.
debug1: identity file /Users/first.last/.ssh/id_rsa type 1
debug1: key_load_public: No such file or directory
debug1: identity file /Users/first.last/.ssh/id_rsa-cert type -1
debug1: key_load_public: No such file or directory
debug1: identity file /Users/first.last/.ssh/id_dsa type -1
debug1: key_load_public: No such file or directory
debug1: identity file /Users/first.last/.ssh/id_dsa-cert type -1
debug1: key_load_public: No such file or directory
debug1: identity file /Users/first.last/.ssh/id_ecdsa type -1
debug1: key_load_public: No such file or directory
debug1: identity file /Users/first.last/.ssh/id_ecdsa-cert type -1
debug1: key_load_public: No such file or directory
debug1: identity file /Users/first.last/.ssh/id_ed25519 type -1
debug1: key_load_public: No such file or directory
debug1: identity file /Users/first.last/.ssh/id_ed25519-cert type -1
debug1: Enabling compatibility mode for protocol 2.0
debug1: Local version string SSH-2.0-OpenSSH_7.4
debug1: Remote protocol version 2.0, remote software version OpenSSH_7.4
debug1: match: OpenSSH_7.4 pat OpenSSH* compat 0x04000000
debug1: Authenticating to localhost:22 as 'first.last'
debug1: SSH2_MSG_KEXINIT sent
debug1: SSH2_MSG_KEXINIT received
debug1: kex: algorithm: curve25519-sha256
debug1: kex: host key algorithm: ecdsa-sha2-nistp256
debug1: kex: server->client cipher: [email protected] MAC: <implicit> compression: none
debug1: kex: client->server cipher: [email protected] MAC: <implicit> compression: none
debug1: expecting SSH2_MSG_KEX_ECDH_REPLY
debug1: Server host key: ecdsa-sha2-nistp256 SHA256:Zg4yEz5WCZVbQEutpAM5zRw+Tk+2gUGFtSYOSTsVfTU
debug1: Host 'localhost' is known and matches the ECDSA host key.
debug1: Found key in /Users/first.last/.ssh/known_hosts:75
debug1: rekey after 134217728 blocks
debug1: SSH2_MSG_NEWKEYS sent
debug1: expecting SSH2_MSG_NEWKEYS
debug1: SSH2_MSG_NEWKEYS received
debug1: rekey after 134217728 blocks
debug1: SSH2_MSG_EXT_INFO received
debug1: kex_input_ext_info: server-sig-algs=<ssh-ed25519,ssh-rsa,ssh-dss,ecdsa-sha2-nistp256,ecdsa-sha2-nistp384,ecdsa-sha2-nistp521>
debug1: SSH2_MSG_SERVICE_ACCEPT received
debug1: Authentications that can continue: publickey,password,keyboard-interactive
debug1: Next authentication method: publickey
debug1: Offering RSA public key: /Users/first.last/.ssh/id_rsa
debug1: Server accepts key: pkalg ssh-rsa blen 279
Authentication failed.
$ 

O conteúdo do meu diretório .ssh é o seguinte, então eu não sei o que o sistema operacional está fumando quando diz que o id_rsa não está presente, a menos que as permissões estejam de alguma forma me atrapalhando:

authorized_keys*  id_rsa            config*
id_rsa.pub*       known_hosts*

    

Answer 1

Acho que você está confundindo as teclas do host com as chaves do usuário. Quando você faz SSH em um host, o host se autentica com sua chave de host e, em seguida, você se autentica no host com sua chave de usuário.

Os Macs sempre geraram suas próprias chaves de host. Versões recentes do macOS foram atualizadas das chaves do host RSA para as chaves do host ECDSA, porque a criptografia da Elliptic Curve é considerada mais segura que a RSA. A segurança da RSA se baseia no fato de que ninguém encontrou uma maneira fácil de fatorar os produtos de grandes números primos. Infelizmente, ninguém provou que é irredutivelmente difícil também. Acredito que a criptografia da curva elíptica é comprovadamente difícil.

Enquanto você remove as referências a localhost e 127.0.0.1 a partir de known_hosts, remova também as entradas para ::1 , que é o equivalente IPv6 de 127.0.0.1.

Você não precisa rebaixar a chave de host SSH do seu Mac do ECDSA para o RSA para fazer o SSHing no trabalho localhost. Basta digitar "yes" uma vez quando o SSHing no host local e sua chave de host do ECDSA serão armazenados em seu arquivo known_hosts.