Posso usar a autenticação de chave SSH para fazer login em um sistema remoto com um nome de usuário diferente?

Suponha que eu tenha um sistema remoto chamado "sistema de controle remoto" e uma conta de usuário "foouser" nesse sistema.

Eu sei que no meu sistema local, posso gerar um par de chaves SSH como usuário local "foouser", colocar a chave pública no arquivo "/home/foouser/.ssh/authorized_keys" em "remotesystem". Quando eu SSH como "foouser" do meu sistema local para o "sistema de controle remoto", o SSH usa o par de chaves para me autenticar.

Mas e se meu nome de usuário local não for igual ao nome de usuário no sistema remoto? Ou seja, e se eu quiser fazer o SSH como usuário local "baruser" para "remotesystem"? Obviamente, precisarei gerar um par de chaves para "baruser" e adicionar a chave pública a "/home/foouser/.ssh/authorized_keys". Então, eu deveria poder "ssh foouser @ remotesystem" enquanto estiver logado como "baruser" localmente, e o SSH usará o par de chaves para autenticar, certo?

Estou perguntando, porque estou tentando fazer com que a autenticação de chave funcione nesse cenário, sem sucesso. Não tenho certeza se é devido à incompatibilidade de nome de usuário ou a um problema de configuração com o servidor SSH no sistema remoto.

Sim, você pode fazer isso, assim como o descreveu.

baruser @ aqui ~ $ ssh-add -l
4096 10: b3: fd: 29: 08: 86: 24: a6: da: 0a: dd: c6: 1e: b0: 66: 6a id_rsa (RSA)
baruser @ aqui ~ $ ssh foouser @ remotesystem
mensagem motd, etc.
foouser @ remotesystem ~ $

É um pouco de lado, mas ...

Se você está sempre usando o mesmo nome de usuário para um servidor remoto, também pode ser útil adicionar um host à sua configuração ssh:

Host remotesystem
    User baruser

Dessa forma, você não precisa se lembrar de especificar o nome de usuário ao efetuar login e excluir isso quando tiver problemas com chaves no futuro.

Seu nome de usuário local realmente não importa (além da chave privada ter que residir no diretório inicial do usuário local). Basta copiar a chave na authorized_keysseção do usuário remoto e ele funcionará.

Com qualquer problema relacionado ao ssh, a primeira coisa a fazer é aumentar a verbosidade do cliente:

usuário ssh @ machine -vvv

Se isso falhar em fornecer informações sobre o que está errado, você precisará alterar o nível de log no servidor e reiniciar o daemon.

LogLevel DEBUG3

Você deve encontrar a saída de depuração em /var/log/auth.log (ou onde o ssh estiver configurado para efetuar logon). Depois de encontrar o problema, lembre-se de configurá-lo novamente como o encontrou.

As permissões nos diretórios .ssh em ambas as máquinas devem estar corretas. Geralmente, isso significa 700 no diretório .ssh e no máximo 755 no diretório inicial. Além de 600 em todos os arquivos nos diretórios .ssh.

Se o usuário no sistema remoto for root, verifique se o root pode ssh. (PermitRootLogin em sshd_config) e essa chave pública (PubkeyAuthentication) e, se necessário, o RSA (RSAAuthentication) estão ativados.

Se você tiver o SE Linux ativado, também precisará fazer o seguinte.

Adicione o rótulo SELinux para authorized_keysque ele possa ser acessado pelo sshd.

semanage fcontext -a -t sshd_key_t ~foo/.ssh/authorized_keys
restorecon -Rv ~user/.ssh

Parece que você está fazendo as coisas corretamente, mas certifique-se de que as permissões estejam corretas em allowed_keys. Eles devem ser configurados para 600.