Quando o usuário no servidor não está logado, o ssh dá: Permissão negada (chave pública)

Question

Estou configurando um servidor ssh usando autenticação de chave pública. Para isso usei este tutorial: link

Consegui fazer o login via ssh. Mas isso só funciona se eu mantiver o usuário logado no servidor (o que significa que tenho que digitar meu nome de usuário e senha na máquina do servidor e mantê-lo logado). Se eu fizer o logout do usuário no servidor, quando eu tentar logar através do ssh ele dá: "Permissão negada (chave pública)".

A minha pergunta é ... existe realmente a necessidade de manter o usuário logado no servidor para usar o ssh com authetntication de chave pública? Ou talvez eu tenha feito algo errado?

Obrigado!

Informação adicional: usando

ssh [email protected] -v

Eu recebo a seguinte saída (quando não há usuário logado no servidor).

debug1: Reading configuration data /etc/ssh_config
debug1: /etc/ssh_config line 20: Applying options for *
debug1: Connecting to 10.0.1.200 [10.0.1.200] port 22.
debug1: Connection established.
debug1: identity file /Users/thecommodore/.ssh/id_rsa type -1
debug1: identity file /Users/thecommodore/.ssh/id_rsa-cert type -1
debug1: identity file /Users/thecommodore/.ssh/id_dsa type -1
debug1: identity file /Users/thecommodore/.ssh/id_dsa-cert type -1
debug1: Remote protocol version 2.0, remote software version OpenSSH_5.9p1 Debian-5ubuntu1
debug1: match: OpenSSH_5.9p1 Debian-5ubuntu1 pat OpenSSH*
debug1: Enabling compatibility mode for protocol 2.0
debug1: Local version string SSH-2.0-OpenSSH_5.9
debug1: SSH2_MSG_KEXINIT sent
debug1: SSH2_MSG_KEXINIT received
debug1: kex: server->client aes128-ctr hmac-md5 none
debug1: kex: client->server aes128-ctr hmac-md5 none
debug1: SSH2_MSG_KEX_DH_GEX_REQUEST(1024<1024<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: DSA 2e:ca:e6:66:d1:61:35:7c:98:bb:cb:1f:49:aa:24:81
debug1: Host '[10.0.1.200]:22' is known and matches the DSA host key.
debug1: Found key in /Users/thecommodore/.ssh/known_hosts:7
debug1: ssh_dss_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
debug1: Next authentication method: publickey
debug1: Offering DSA public key: /Users/thecommodore/.ssh/id_dsa
debug1: Authentications that can continue: publickey
debug1: Trying private key: /Users/thecommodore/.ssh/id_rsa
debug1: Trying private key: /Users/thecommodore/.ssh/id_dsa
debug1: key_parse_private_pem: PEM_read_PrivateKey failed
debug1: read PEM private key done: type <unknown>
debug1: read PEM private key done: type DSA
Identity added: /Users/thecommodore/.ssh/id_dsa (/Users/thecommodore/.ssh/id_dsa)
debug1: read PEM private key done: type DSA
debug1: Authentications that can continue: publickey
debug1: No more authentication methods to try.
Permission denied (publickey).

    

Answer 1

Isso é provavelmente o resultado de um diretório inicial criptografado. Isso impede que o daemon SSH leia os arquivos de chaves e fará com que o login baseado em chave falhe. Você tem basicamente duas opções para atenuar esse problema:

• Desativar a criptografia do diretório inicial. Veja esta tutoria l (fornecida pelo OP).
• Configure o daemon SSH para ler os arquivos principais de outro local não criptografado.

Para a segunda opção, você pode criar um diretório /sshkeys/ com subdiretórios para cada usuário. Em seguida, defina o parâmetro AuthorizedKeysFile em /etc/ssh/sshd_config to /sshkeys/%u/authorized_keys e coloque os arquivos nos subdiretórios apropriados e verifique se todos os usuários têm direitos de leitura / execução para /sshkeys e se as permissões para o diretório específico do usuário pertencem ao respectivo usuário e está definido para permissões 700

Outra opção, que é mais avançada, seria usar o parâmetro AuthorizedKeysCommand e escrever um script de pesquisa para a chave, por ex. de um diretório LDAP. Isso ajudaria com o problema NFS4 / Kerberos descrito por Thorsten também. Isso exigiria que você permitisse que seus usuários colocassem a chave no campo LDAP relevante, por exemplo, com alguns scripts auxiliares adicionais.

    

Answer 2

A obtenção da sua casa a partir de um compartilhamento de rede que usa uma autenticação strong (NFSv4 kerberizado, CIFS) pode causar o mesmo problema. O PAM usará sua senha para montar o compartilhamento. Nenhuma senha - > sem casa - > sem authorized_keys