A senha SSH no macOS falha

Question

Estou tentando configurar o login sem senha em dois macs, mini e bigmac. Está trabalhando em um, não no outro. Em cada máquina:

Eu uso "ssh-keygen -t rsa" para gerar id_rsa e id_rsa.pub (pressionando enter quando solicitado por uma senha). Eu mv os arquivos resultantes para ~ / .ssh, em seguida, scp id_rsa.pub para ~ / .ssh / authorized_keys para o Mac oposto.

Para ssh de "mini" em "bigmac", o login sem senha funciona. Quando eu tento ssh de "bigmac" em "mini", me pedem uma senha:

bigmac:~ jedevnull$ cd .ssh
bigmac:.ssh jedevnull$ ls
authorized_keys id_rsa      id_rsa.pub      known_hosts
bigmac:.ssh jedevnull$ ssh -v mini

OpenSSH_6.2p2, OSSLShim 0.9.8r 8 Dec 2011
debug1: Reading configuration data /etc/ssh_config
debug1: /etc/ssh_config line 20: Applying options for *
debug1: Connecting to mini [192.168.1.20] port 22.
debug1: Connection established.
debug1: identity file /Users/jedevnull/.ssh/id_rsa type 1
debug1: identity file /Users/jedevnull/.ssh/id_rsa-cert type -1
debug1: identity file /Users/jedevnull/.ssh/id_dsa type -1
debug1: identity file /Users/jedevnull/.ssh/id_dsa-cert type -1
debug1: Enabling compatibility mode for protocol 2.0
debug1: Local version string SSH-2.0-OpenSSH_6.2
debug1: Remote protocol version 2.0, remote software version OpenSSH_6.9
debug1: match: OpenSSH_6.9 pat OpenSSH*
debug1: SSH2_MSG_KEXINIT sent
debug1: SSH2_MSG_KEXINIT received
debug1: kex: server->client aes128-ctr [email protected] none
debug1: kex: client->server aes128-ctr [email protected] none
debug1: SSH2_MSG_KEX_DH_GEX_REQUEST(1024<2048<8192) sent
debug1: expecting SSH2_MSG_KEX_DH_GEX_GROUP
debug1: SSH2_MSG_KEX_DH_GEX_INIT sent
debug1: expecting SSH2_MSG_KEX_DH_GEX_REPLY
debug1: Server host key: RSA 0d:2e:de:45:00:ff:9b:ff:96:c5:f6:bd:c6:6a:b0:ec
debug1: Host 'mini' is known and matches the RSA host key.
debug1: Found key in /Users/jedevnull/.ssh/known_hosts:1
debug1: ssh_rsa_verify: signature correct
debug1: SSH2_MSG_NEWKEYS sent
debug1: expecting SSH2_MSG_NEWKEYS
debug1: SSH2_MSG_NEWKEYS received
debug1: Roaming not allowed by server
debug1: SSH2_MSG_SERVICE_REQUEST sent
debug1: SSH2_MSG_SERVICE_ACCEPT received
debug1: Authentications that can continue: publickey,keyboard-interactive
debug1: Next authentication method: publickey
debug1: Offering RSA public key: /Users/jedevnull/.ssh/id_rsa
debug1: Authentications that can continue: publickey,keyboard-interactive
debug1: Trying private key: /Users/jedevnull/.ssh/id_dsa
debug1: Next authentication method: keyboard-interactive
Password:

O id_rsa.pub do bigmac e o authorized_keys do mini são os mesmos.

    

Answer 1

Para encontrar a causa do problema, seria útil ver as mensagens de depuração nos lados do servidor e do cliente da conexão. A opção -d no servidor permite mensagens de depuração detalhadas no terminal para uma única conexão (ou rejeição). Então, por exemplo, no lado do servidor, execute

/usr/sbin/sshd -d -p2222

(executado em uma porta não padrão para não interferir no sshd normal) e no lado do cliente

ssh -v -p2222 ${SERVER_IP}

Para mais detalhes,

/usr/sbin/sshd -dd -p2222
ssh -vv -p2222 ${SERVER_IP}

    

Answer 2

Qualquer sistema n * x com serviço SSH (não o comando ssh, mas o sshd) depende de uma conta existente e acessível e de um arquivo que contém chaves públicas válidas para essa conta (= usuário).

Tanto a pasta ~ / .ssh como a própria chave só devem ser acessíveis por esse usuário específico. A chave deve ser chmod a 600, a pasta deve ser 700, por isso não é acessível por ninguém além do usuário (tenha cuidado para não defini-la como 600, porque você não pode ler a pasta por conta própria). O mesmo para o arquivo authorized_keys: eu recomendaria 600.

Se o arquivo que contém a chave não corresponder à restrição solicitada (somente você tem acesso), o login do ssh provavelmente falhará.

A propósito (pouco fora do tópico): Neste caso, talvez @jocala poderia ter gerado um par e usado em ambas as máquinas. Se você estiver usando várias máquinas de clientes diferentes, é muito recomendável ter várias chaves. Para ajudá-lo qual chave usar, você sempre pode criar (e preencher) um arquivo ~ / .shh / config em vez de sempre especificar a chave usando ssh -i [path_to_key] [email protected] .