Sim, você pode fazer isso, assim como descreveu.
baruser@here ~$ ssh-add -l 4096 10:b3:fd:29:08:86:24:a6:da:0a:dd:c6:1e:b0:66:6a id_rsa (RSA) baruser@here ~$ ssh foouser@remotesystem motd message, etc. foouser@remotesystem ~$
Suponha que eu tenha um sistema remoto chamado "remotesystem" 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 "remotesystem", 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? Isto é, e se eu quiser 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 ser capaz de "ssh foouser @ remotesystem" enquanto 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.
É um pouco de lado, mas .....
Se você está sempre usando o mesmo nome de usuário para um servidor remoto, você também pode achar útil adicionar um host em sua configuração ssh:
Host remotesystem
User baruser
Dessa forma, você não precisa se lembrar de especificar o nome de usuário ao fazer login e descarta isso ao ter problemas com chaves no futuro.
Seu nome de usuário local não importa realmente (além da chave privada ter que residir dentro do diretório pessoal do usuário local). Basta copiar a chave para a seção authorized_keys do usuário remoto e ela funcionará.
Com qualquer problema relacionado ao ssh, a primeira coisa a fazer é aumentar o detalhamento do cliente:
ssh user@machine -vvv
Se isso falhar em fornecer informações sobre o que está errado, você precisará alterar o nível de registro no servidor e reiniciar o daemon.
LogLevel DEBUG3
Você deve encontrar a saída de depuração em /var/log/auth.log (ou onde quer que o ssh esteja configurado para logar). Depois de encontrar o problema, lembre-se de configurá-lo de volta para como você o encontrou.
As permissões nos diretórios .ssh em ambas as máquinas estão 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, certifique-se de que root possa ssh. (PermitRootLogin em sshd_config) e essa chave pública (PubkeyAuthentication) e, se necessário, RSA (RSAAuthentication) estão ativados.
Se você tiver o SE Linux ativado, também precisará fazer o seguinte.
Adicione o rótulo do SELinux a authorized_keys para que possa ser acessado por 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 verifique se as permissões estão corretas em authorized_keys. Eles devem ser definidos para 600.
Tags ssh authentication solaris linux