Já tive alguns logins de emparelhamento de chaves "funcionando" em meus servidores, mas um deles sempre teve problemas e finalmente chegou ao ponto de interferir em certas tarefas.
A situação:
Host é o meu PC que estou usando para o ssh para os servidores. O servidor1 foi configurado primeiro e tem uma configuração de autenticação de chave pública ssh em funcionamento. O Server2 foi configurado após o Server1 e teve problemas de login desde o início. O mesmo nome de usuário é usado para todos os três. Todos os três computadores possuem diretórios pessoais criptografados.
O problema:
Quando você tentar SSH no Servidor2 do Host, após o Host ter sido reiniciado / reinicializado, será solicitada uma senha, se você digitar a senha e continuar, você poderá fazer o ssh sem problemas, contanto que o Host não o faça. reinicialize. Após qualquer reinicialização, você precisará redigitar a senha.
Isso às vezes pode ser evitado se você usar ssh com a tag -vvv . Sob essa condição, você não precisa digitar uma senha no primeiro login, mas todas as tentativas subsequentes de SSH exigem uma senha.
Teste:
Eu tenho usado: ssh -o PreferredAuthentications=publickey Server2 para testar a conectividade usando o acesso de chave pública somente entre o Host e o Server2. Usarei os resultados desses testes em vez dos testes -vvv output, pois ele é mais curto. Eu comparei a saída -vvv do sshing ao Server2 e o Servidor1 em funcionamento e a única área visível de divergência está na seguinte área:
Para o servidor1:
debug1: Offering RSA public key: /home/USER/.ssh/id_rsa
debug3: send_pubkey_test
debug2: we sent a publickey packet, wait for reply
debug1: Server accepts key: pkalg ssh-rsa blen 279
Para o servidor2:
debug1: Offering RSA public key: /home/USER/.ssh/id_rsa
debug3: send_pubkey_test
debug2: we sent a publickey packet, wait for reply
debug1: Authentications that can continue: publickey,password
O conteúdo do Host ~/.ssh/id_rsa.pub corresponde ao arquivo ~/.ssh/authorized_keys do Server2.
Os arquivos ssh_config e sshd_config são idênticos entre o Server1 e o 2.
O conteúdo e as permissões de ~ / .ssh no Server2:
total 56
drwx------ 2 USER USER 4096 Jul 1 17:59 .
drwx------ 6 USER USER 4096 Jun 30 11:50 ..
-rw------- 1 USER USER 391 Apr 28 17:31 authorized_keys
-rw------- 1 USER USER 1679 Jun 30 14:51 id_rsa
-rw-r--r-- 1 USER USER 394 Jun 30 14:51 id_rsa.pub
-rw-r--r-- 1 USER USER 442 Jun 30 10:32 known_hosts
Os últimos três arquivos estão lá porque este servidor precisa ser capaz de fazer o ssh para outro servidor.
Os resultados de / usr / sbin / sshd -d no Server2 são:
debug1: sshd version OpenSSH_7.2, OpenSSL 1.0.2g 1 Mar 2016
debug1: key_load_private: Permission denied
Could not load host key: /etc/ssh/ssh_host_rsa_key
debug1: key_load_private: Permission denied
Could not load host key: /etc/ssh/ssh_host_dsa_key
debug1: key_load_private: Permission denied
Could not load host key: /etc/ssh/ssh_host_ecdsa_key
debug1: key_load_private: Permission denied
Could not load host key: /etc/ssh/ssh_host_ed25519_key
debug1: setgroups() failed: Operation not permitted
debug1: rexec_argv[0]='/usr/sbin/sshd'
debug1: rexec_argv[1]='-d'
debug1: Set /proc/self/oom_score_adj from 0 to -1000
debug1: Bind to port 22 on 0.0.0.0.
Bind to port 22 on 0.0.0.0 failed: Permission denied.
debug1: Bind to port 22 on ::.
Bind to port 22 on :: failed: Permission denied.
Cannot bind any address.
Isso é idêntico à saída para o Server1.
Os resultados dos testes usando ssh -o PreferredAuthentications=publickey Server2 são os seguintes:
Login com falha: Permission denied (publickey,password)
- Depois de reinicializar o host
- Depois que o terminal do host trava
- Depois de estabelecer uma conexão
-vvv ssh
- Depois de reiniciar o serviço ssh (funciona apenas às vezes)
O único método possível para obter um login bem-sucedido é autenticar primeiro a senha.
Tentativas da solução:
Solução alternativa criptografada do diretório inicial. Falhou.
O usuário conseguiu ssh sem fornecer uma senha, no entanto, a sessão exigiu que o diretório inicial fosse descriptografado (o qual o Servidor1 não requer) e o .profile e os arquivos associados não foram usados adequadamente.
Como eu permito que este servidor aceite sessões ssh de pares de chaves? Deve ser configuração idêntica ao Server1 em relação ao serviço ssh. Eu tenho procurado por logs e saídas por um tempo agora, então talvez um novo conjunto de olhos possa detectar algo que eu perdi.
EDIT: Agora, o primeiro login após a reinicialização da máquina é bem-sucedido, mas uma tentativa de login subsequente requer uma senha. Se a senha for fornecida na segunda tentativa, todas as tentativas seguintes funcionarão.