“Às vezes” recebo “Permission denied (publickey)”

Question

Contexto: ssh: ing para o meu servidor ssh de algum lugar com chave (ou seja, não passwd), e às vezes não funciona.

Servidor: Ubuntu 16.04 LTS, totalmente corrigido. Servidor OpenSSH. Senhas e login root desativados.

Clientes: Tentei com o cliente OSX OpenSSH e o cliente OpenSSH Ubuntu 17.10.

Saída com erro de ssh -vvv "server" ao falhar (do OSX):

debug1: Authentications that can continue: publickey
debug3: start over, passed a different list publickey
debug3: preferred publickey,keyboard-interactive,password
debug3: authmethod_lookup publickey
debug3: remaining preferred: keyboard-interactive,password
debug3: authmethod_is_enabled publickey
debug1: Next authentication method: publickey
debug1: Offering public key: RSA SHA256:xxxx/E /Users/xxx/.ssh/id_rsa
debug3: send_pubkey_test
debug3: send packet: type 50
debug2: we sent a publickey packet, wait for reply
debug3: receive packet: type 51 <-- HERE, diff from success
debug1: Authentications that can continue: publickey
debug2: we did not send a packet, disable method
debug1: No more authentication methods to try.
[email protected]: Permission denied (publickey).

Saída com erro de ssh -vvv "server" ao obter sucesso (da OSX, este um par de minutos depois da falha acima):

debug1: Authentications that can continue: publickey
debug3: start over, passed a different list publickey
debug3: preferred publickey,keyboard-interactive,password
debug3: authmethod_lookup publickey
debug3: remaining preferred: keyboard-interactive,password
debug3: authmethod_is_enabled publickey
debug1: Next authentication method: publickey
debug1: Offering public key: RSA SHA256:xxx/E /Users/xxx/.ssh/id_rsa
debug3: send_pubkey_test
debug3: send packet: type 50
debug2: we sent a publickey packet, wait for reply
debug3: receive packet: type 60 <-- HERE, success, diff from fail
debug1: Server accepts key: pkalg rsa-sha2-512 blen 279
debug2: input_userauth_pk_ok: fp SHA256:xxx/E
debug3: sign_and_send_pubkey: RSA SHA256:xxx/E
Enter passphrase for key '/Users/xxx/.ssh/id_rsa': 
debug1: identity added to agent: /Users/xxx/.ssh/id_rsa
debug3: send packet: type 50
debug3: receive packet: type 52
debug1: Authentication succeeded (publickey).
Authenticated to yyy.zzz ([123.456.789.012]:22).

E eles são bem parecidos, a diferença é nessa linha:

debug3: receive packet: type 51 (when failing)
debug3: receive packet: type 60 (when succeeding)

Isso me leva a acreditar que é um problema do lado do servidor. Em /var/log/auth.log , localizei estas entradas:

Feb  7 09:30:59 server-name sshd[48527]: Connection closed by (client public IP) port 64050 [preauth] (the only mention of this connection attempt)
Feb  7 09:34:17 server-name sshd[48725]: Accepted publickey for yyy from (client public IP) port 64134 ssh2\: RSA SHA256:xxx/E (the succeeding attempt)

Então, há algo acontecendo, mas agora estou perplexo? Alguma idéia de como resolver isso?

Pode ser uma informação relevante: O servidor ssh tem um IP público, e há aproximadamente dez (10) tentativas ruins de conexão ssh por minuto (somente a porta 22 está aberta). Parece que por alguns minutos depois de eu ter logado no servidor localmente é sempre possível fazer logon remoto via ssh. O servidor fica atrás de um firewall físico, com a porta 22 encaminhada, e o comportamento é o mesmo da minha sub-rede local.

    

Answer 1

Depois de mexer um pouco, descobri que o problema estava conectado a um diretório pessoal criptografado (o que eu perdi completamente durante a configuração, já que estava configurando mais de 10 VMs por meio de scripts).

Ainda confuso de que o servidor não registrou que não conseguiu acessar /home/userdir/.ssh/authorized_keys e mostrou apenas:

Feb  7 09:30:59 server-name sshd[48527]: Connection closed by (client public IP) port 64050 [preauth] (the only mention of this connection attempt)

Em geral, existem duas soluções:

1. Descriptografe o diretório inicial (isso é confuso, eu não recomendaria isso). Google para instruções. ecryptfs permanent decrypt obtém bons resultados.
2. Mova o authorized_keys para fora da sua pasta pessoal criptografada para que seja acessível.

Desde que 1) é confuso, eu recomendaria 2).

Movendo authorized_keys

Eu recomendaria criar uma estrutura de diretórios em /etc/ssh/ like /etc/ssh/keys/%user/authorized_keys e alterando a linha AuthorizedKeyFile em /etc/ssh/sshd_config para corresponder. Ou seja:

#original (%h expands to /home/userdir, which is encrypted)
AuthorizedKeysFile     %h/.ssh/authorized_keys
#new (%u expands to username)
AuthorizedKeysFile     /etc/ssh/keys/%u/authorized_keys

Depois de fazer o login agora, você deve estar em uma pasta home minimalista sem conteúdo, execute ecryptfs-mount-private para descriptografar a pasta home (você precisará inserir a frase secreta, por padrão, sua senha). A maneira mais fácil de contornar isso é adicionar um .profile na sua pasta home minimalista que o descriptografa e envia para sua pasta pessoal real.

# place in minimalistic .profile
ecryptfs-mount-private
# if below doesn't work, replace with static cd /home/userdir
cd $HOME