Não é possível ssh mesmo com chave pública adicionada a authorized_keys

Question

Eu tenho uma gota no Oceano Digital que estou tentando me dar acesso ssh. Não tenho certeza do que foi feito anteriormente. Eu tentei adicionar minha chave pública através da interface do usuário do Oceano Digital. Isso não funcionou, eu continuei recebendo permission denied (publickey) .

Eu acessei o servidor através do console marítimo digital e adicionei manualmente minha chave pública a /root/.ssh/authorized_keys . Eu então tentei usar o ssh ssh [email protected] . Isso não funcionou (permissão negada).

Então, tentei adicionar um novo usuário, criei o diretório /home/me/.ssh com as permissões 700 no diretório .ssh e 600 no arquivo authorized_keys . Então eu tentei ssh [email protected] . Isso não funcionou também.

Reiniciar o daemon ssh também não altera nada.

O que estou perdendo?

Editar:

Aqui está a saída detalhada do ssh.

link

Editar 2:

LogLevel DEBUG3 output:

    

Answer 1

Acabei de reinstalar openssh-server , o que resolveu o problema. As soluções dadas são todas ótimas, mas não funcionaram para mim. Eu não tenho ideia do que estava causando o problema, mas acho que o desenvolvedor anterior pode ter mexido com a configuração e estragado tudo muito mal.

Eu duvido que haja alguém com uma questão tão específica quanto a minha. No entanto, se você tiver um droplet Digital Ocean, não poderá obter acesso SSH e nenhuma das soluções fornecidas funcionar, reinstale o servidor SSH executando esses comandos por meio do console do Oceano Digital. Tenha em atenção que este é um processo destrutivo e apaga ficheiros de configuração antigos em /etc/ssh/ (não o seu diretório .ssh ).

apt-get purge openssh-server
apt-get autoremove
apt-get autoclean
apt-get install openssh-server

Assumindo que o seu cliente ssh / chaves estão em ordem, você deve ser capaz de conectar o SSH ao seu servidor.

    

Answer 2

Configuração do cliente

Configurar ~/.ssh/config

Configurar as entradas do host para ssh é realmente fácil e vai lhe poupar muitos problemas. Aqui está um exemplo:

Host digitaloceanbox
Hostname 111.111.111.111
User root
PubKeyAuthentication yes
IdentityFile /home/user/.ssh/digitalocean-rsa
ForwardX11 yes


Host github github.com
Hostname github.com
User git
PubKeyAuthentication yes
IdentityFile /home/user/.ssh/github-rsa
ForwardX11 no

Neste exemplo, configuramos digitaloceanbox e github e github.com para que possamos fazer os seguintes comandos:

1. ssh github
2. ssh digitaloceanbox

Se quisermos fazer login como um usuário diferente daquele especificado no arquivo de configuração, basta colocar user@ no começo:

• ssh user@digitaloceanbox

Gerando ssh chaves

ssh-keygen -t rsa -b 4096 -C user@homemachine
Generating public/private rsa key pair.
Enter file in which to save the key (/home/user/.ssh/id_rsa):  /home/user/.ssh/digitalocean-rsa
Enter passphrase (empty for no passphrase): 
Enter same passphrase again: 
Your identification has been saved in /home/user/.ssh/digitalocean-rsa
Your public key has been saved in /home/user/.ssh/digitalocean-rsa.pub.
The key fingerprint is:
SHA256:p9PYE/tveF2n//bLbp3ogYDtMtYEC5ziQiPxeob6fbo user@homemachine

Observe que eu especifiquei o caminho completo da chave privada que desejo gerar quando solicitado por ssh-keygen . Eu também defini o comentário ( -C ) que me permite identificar facilmente chaves em máquinas remotas.

Isso criará dois arquivos:

1. %código%
   • tecla PRIVATE . Nunca compartilhe isso .
2. %código%
   • Chave pública. Isso é o que você armazena no servidor para autenticar.

Quando você fornecer sua chave .ssh/digitalocean-rsa , verifique se é a versão .ssh/digitalocean-rsa.pub !! Quando você adicionar ao seu ssh , certifique-se de adicionar a chave privada correta que corresponde à chave pública adicionada ao sistema.

Configuração do Servidor

A maioria das instalações virá com a autenticação de chave pública habilitada. Se você começar a fazer todas as coisas por vontade própria, poderá ter alguns problemas, no entanto. Quando o OP estiver com problema, recomendo que o OP exclua o diretório .pub para começar de novo.

Não é recomendável usar ~/.ssh/config para acessar o usuário raiz no sistema remoto. Recomenda-se que você use /root/.ssh/ em outro usuário e, em seguida, passe a raiz usando sua senha ( ssh ).

Adicione chaves ao host usando ssh

Independentemente de você decidir criar outro usuário e usar sudo su - como esse usuário ou o usuário raiz, a maneira recomendada de colocar as chaves ssh-copy-id em um servidor é a seguinte:

1. ssh

Isso permite que ssh crie o diretório e os arquivos necessários com as permissões necessárias. Isso significa que não há chances de você perder permissões ou precisar lembrar dos detalhes. Basta usar a ferramenta para fazer o upload das chaves.

Desativar autenticação de senha

Dito isso, assim que você tiver a chave e verificado que é possível se conectar usando as chaves, é recomendável desabilitar a Autenticação de Senha em ssh-copy-id -i /home/user/.ssh/digitalocean-rsa.pub user@digitaloceanbox e reiniciar o serviço:

1. Editar sshd
2. sshd
3. /etc/ssh/sshd_config

E os novos usuários?

Se você desabilitar a Autenticação de Senha, como poderá chamar novos usuários? Uma maneira é adicionar arquivos de modelo ao diretório PasswordAuthentication no . Depois de digitar um usuário, faça o seguinte:

1. sudo systemctl restart sshd
2. /etc/skel
3. Edite todos os arquivos encontrados em sudo cp -r .ssh/ /etc/skel/ para que fiquem em branco, a menos que você queira digitar automaticamente para cada usuário recém-criado.

Quando você criar novos usuários com ls /etc/skel/.ssh , esse usuário terá o /etc/skel/.ssh/ , que você pode editar e terá as permissões adequadas.

Depuração

Você pode assistir ao arquivo de log sudo useradd -m newuser para ver por que as conexões falham ou são recusadas:

1. .ssh/authorized_keys

Enquanto você está executando este comando, use outro terminal para tentar um login. Muitas vezes as mensagens fornecidas são boas o suficiente para ajudar a identificar o problema ou encontrar uma solução on-line.

    

Answer 3

O Ssh é bastante exigente quanto à propriedade, permissões de arquivos e diretórios com chaves ssh.

~ / .ssh / deve pertencer ao proprietário e ter 700 permissões. ~ / .ssh / authorized_keys deve pertencer ao proprietário e ter 600 permissões.

Então, para root:

sudo chown root:root -R /root/.ssh/
sudo chmod 700 /root/.ssh/
sudo chmod 600 /root/.ssh/authorized_keys

Para usuário:

sudo chown me:me -R /home/me/
sudo chmod 700 /home/me/.ssh/
sudo chmod 600 /home/me/.ssh/authorized_keys

E tente novamente.

É claro que você também deve verificar em / etc / ssh / sshd_config se o root tem permissão para efetuar login, ou apenas com as chaves ssh.

Se você tem:

PasswordAuthentication no

então você pode definir:

PermitRootLogin yes

E, em seguida, reinicie o sshd:

/etc/init.d/sshd restart

e tente novamente.

Note que com o ssh, o daemon sshd pode ser reiniciado mesmo quando se usa uma sessão ssh para isso. O Doessh foi projetado para lidar com isso.

Olhando para os fragmentos de arquivos de log enviados, parece que você está usando o MacOSX? Você poderia criar uma nova chave ssh lá?

Além disso, descobri no passado que quando eu tenho mais de uma chave ssh privada no meu computador local para o meu usuário, isso às vezes torna impossível fazer login remotamente com o ssh. Ajudou muito a fazer entradas no computador local no arquivo ~ / .ssh / config, para resolver isso. Por exemplo:

Host my-vps
  HostName my-vps-ip-address-here
  IdentityFile ~/.ssh/id_rsa-my-private-key-location
  User my-username-here

Depois disso, tente na linha de comando do seu computador local:

ssh -v my-vps

Ao usar chaves ssh, assim como nenhuma chave ssh para alguns outros logins, você pode, além de entradas com chaves ssh, também definir um login ssh sem uso da chave ssh no arquivo ~ / ssh / config, por exemplo:

Host pi
  Hostname 192.168.1.111
  Port 22
  User pi
  PasswordAuthentication yes
  PreferredAuthentications password

Isso funciona bem para mim. Também é possível definir qual chave usar na linha de comando:

ssh -v [email protected] -i .ssh/id_rsa

Isso pode facilitar a depuração, e na linha de comando isso deve sempre funcionar no computador local.

    

Answer 4

Verifique novamente a configuração do daemon ssh (deve estar em /etc/ssh/sshd_config ) e verifique:

PubkeyAuthentication yes
AuthorizedKeysFile %h/.ssh/authorized_keys

Verifique também o arquivo de configuração para ver se AllowUsers ou AllowGroups foi definido, pois eles agem como listas brancas para usuários e grupos, respectivamente.

Além disso, notei que você está tentando adicionar uma chave ao usuário root. Por padrão, o login raiz deve ser desativado, mas você também pode alterar isso através do campo PermitRootLogin .

    

Answer 5

De acordo com os registros que você vinculou, acho que você tem problemas no lado do cliente que não encontrou o arquivo chave privada .

• Primeiro verifique o arquivo ~/.ssh/id_rsa existente em sua máquina local e é o correto _ (se você tiver mais).

• Verifique as permissões da pasta .ssh (deve ser drwx------ , se não executar sudo chmod 700 ~/.ssh ) e seu conteúdo (deve ser -rw------- , se não executar sudo chmod 600 ~/.ssh/* ) . Aplique as mesmas permissões para a máquina remota também.

Além disso, você pode tentar forçar o uso da sua chave privada , atribuindo-a diretamente ao ssh com o parâmetro -i .

• Você pode executar algo como o seguinte:

  ssh -i /path/to/your/private-key [email protected]

  ou

  ssh -i ~/.ssh/id_rsa [email protected]

Você pode obter mais informações sobre a página de manual do ssh (executar man ssh no seu terminal) .

Lembre-se também se você deseja fazer o login como root user, sua conta root precisa estar ativada antes do login, criando uma senha para ele com sudo passwd root ou sua ferramenta de administração do servidor (Ubutntu tem raiz conta desativada por padrão) . Você pode obter mais informações em Wiki do Ubuntu .

Espero que ajude.

    

Answer 6

Esse problema apareceu para mim usando a imagem Debian no Digital Ocean. De alguma forma, durante o breve processo de configuração, provavelmente quando eu defini a senha de root, o proprietário de /root foi alterado para o usuário debian . Eu vi o seguinte em /var/log/auth.log :

Jul 26 20:58:17 docker sshd[12576]: Authentication refused: bad ownership or modes for directory /root

A simples execução de chown root:root -R /root resolveu o problema.

HTH

    

Answer 7

Apenas tive um problema muito semelhante. Isso funcionou para mim - Adicione esta linha para / etc / ssh / sshd_config

AuthorizedKeysFile %h/.ssh/authorized_keys 

Em seguida, reinicie o ssh da maneira usual.