O servidor OpenSSH se recusa a aceitar a autenticação de chaves, a menos que esteja conectado ao servidor localmente

Question

Meu servidor está executando o Ubuntu-Server e possui o OpenSSH-Server instalado nele. Eu configurei o arquivo / etc / ssh / sshd_config para aceitar e requerer chaves rsa, ele procura por chaves no arquivo 'AuthorizedKeys ~ / .ssh / authorized_keys'. Nesse arquivo eu tenho duas chaves públicas separadas, uma criada usando o putty que estou usando com o WinSCP e uma criada pelo Secure Shell Client.

Meu problema é que preciso fazer login como meu usuário no servidor antes que a autenticação funcione. Se eu fosse remotamente reinicializar o servidor, tente ssh nele, recebo um erro dizendo que minha chave não pôde ser autenticada e estou com o acesso rejeitado. Assim que eu entrar e fizer login no servidor localmente, poderei fazer o ssh remotamente, contanto que o usuário continue logado.

Alguma idéia do que eu posso estar fazendo errado aqui? Estou achando que tenho meu parâmetro AuthorizedKeys configurado incorretamente no arquivo / etc / ssh / sshd_config

    

Answer 1

Então, assim como eu adivinhei: Seu $ HOME está realmente dentro de um contêiner criptografado que só é aberto no login. Para deixá-lo entrar no sistema, o sshd quer a chave pública antes de permitir a entrada e, assim, é algum tipo de problema de ovo e galinha.

Uma opção para dançar em torno do problema é colocar o arquivo .ssh/authorized_keys em outro lugar através da seguinte alteração no /etc/ssh/sshd_config :

 AuthorizedKeysFile      /home/.ssh/%u

Portanto, o usuário joe tem suas chaves públicas em /home/.ssh/joe etc etc.

Outra ideia que vale a pena tentar é fazer algo assim:

$> login
<os unlocks encrypted /home/joe>
$> cp .ssh/authorized_keys /tmp/
$> logout
<os locks encrypted /home/joe again>
$> mkdir /home/joe/.ssh/
$> cp /tmp/authorized_keys /home/joe/.ssh/

A ideia é retirar o arquivo authorized_keys do contêiner criptografado (assim como a primeira ideia) e, em seguida, colocar esse arquivo não criptografado no lugar certo. Quando você faz o login no sistema, o sistema operacional monta sua casa criptografada como uma espécie de 'sobreposição' ontop de /home/joe , ocultando o% co-de-% não criptografado.

A terceira ideia pode envolver um pouco de batida de portas: você aciona algum tipo de tráfego de rede para algumas portas secretas com alguns dados secretos que, em seguida, acionam o sistema operacional para desbloquear sua casa criptografada. Após o procedimento de batida, você poderá efetuar o login no sistema.

Desvantagens gerais / coisas a serem consideradas: essas ideias dependem de como você criptografou seu $ HOME. Se a criptografia precisar da sua senha para descriptografar os dados, você deverá fornecê-la de alguma forma.