O SSH Keyfile funciona para todos os usuários, exceto um.

Question

Eu tenho um script de backup que está falhando para um usuário e esperava que alguns de vocês pudessem me apontar na direção certa. Eu acho que estou perto, mas preocupado em cometer erros. O servidor de destino é um ambiente SCP de cadeia com 4 usuários / pastas residenciais diferentes. O servidor de backup é capaz de fazer backup de 3 dos 4 usuários / pastas, mas falha para um usuário deles a cada vez. Todos eles usam a mesma chave SSH e ref o mesmo arquivo de chaves.

Não sei como isso aconteceu, mas gostaria de ver como posso fazer com que o usuário4 volte a fazer o backup. Não sei como fazer isso sem criar uma nova chave ou algo assim, mas não quero quebrar os outros usuários. Basicamente, eu só quero adicionar o 4º usuário de volta ao mix para que ele possa usar a chave.

Aqui está o que está acontecendo.

chen-backup (backup server)
dest-server (destination server, SCP jailed, 4 home directories that are being backed up, each home directory has ownership from user1, user2, user3 and user4::user4 cannot backup)

O script é executado no chen-backup, usando o rsync e um arquivo de configuração localizado em root / .ssh / chebackconfig

chbackconfig: Servidor de destino do host         Nome do host dest-server.apples.com         IdentityFile ~ / .ssh / dest_backup_id

O arquivo SSH para dest_backup_id é apenas um arquivo SSH normal.

Se eu rodar ssh user4 @ dest-server, eu recebo uma solicitação de PW (que eu não sei). Se eu executo isso para todos os outros usuários, apenas me permite entrar sem problemas. Se eu for para o servidor de destino e alterar o PW para o User4, terei que criar um novo ssh-keygen? Além disso, se eu alterar os PWs do user4, isso quebrará as chaves que outros sistemas estão usando para acessar o servidor de destino?

Acho que estou tendo dificuldades para entender completamente as chaves e outras coisas.

    

Answer 1

se você especificar explicitamente a chave no seu teste, como:

ssh -i ~/.ssh/dest_backup_id user4@dest-server

isso tem sucesso?

Você pode usar um -v com ssh para aumentar a verbosidade da saída, o que pode ser útil no isolamento de problemas dessa natureza.

A primeira coisa que eu verificaria é que o user4 tem um arquivo $HOME/.ssh/authorized_keys e que a chave pública está lá.

Se a chave estiver listada corretamente, verifique se as permissões no diretório $HOME/.ssh e em todos os arquivos estão corretos. E $HOME também.

chmod go-w /home/$USERNAME
chmod 700 /home/$USERNAME/.ssh
chmod 644 /home/$USERNAME/.ssh/authorized_keys

Além disso, verifique se todos os arquivos são de propriedade do usuário certo:

chown -R $USERNAME /home/$USERNAME/.ssh

Além disso, é uma boa ideia verificar os registros. Geralmente, sshd registra em /var/log/auth.log , mas você pode verificar isso no arquivo /etc/ssh/sshd_config . Aumente o detalhamento da criação de log, se for necessário, e reinicie os serviços ssh.

Na minha experiência, quando o ssh com uma chave não está funcionando como esperado, é um problema de permissões. Talvez alguém tenha copiado um arquivo como root e tenha esquecido de usá-lo, ou talvez as permissões estejam abertas demais na chave privada ou algo assim.

E, não, a alteração da senha não afetará o uso das ssh_keys. Enquanto uma senha e um ssh_key parecem executar funções semelhantes em termos de permitir acesso a um sistema, eles o fazem através de mecanismos muito diferentes, e o sshd realmente não tem confiança na senha (embora geralmente deva haver uma conta, e não deve ser bloqueado).