Estou tentando conectar-me a um Linode (executando o Ubuntu 12.04 LTS) da minha máquina local (também executando o Ubuntu 12.04 LTS)

Eu criei uma chave pública e privada em minha máquina local e copiei minha chave pública no arquivo allowed_keys do meu Linode. No entanto, sempre que tento ssh no meu Linode, recebo a mensagem de erro Permission denied (publickey).

Não é um problema com a configuração do ssh no meu Linode, porque eu posso usá-lo na minha máquina Windows usando a autenticação de chave.

No meu .sshdiretório na minha máquina Ubuntu local, tenho meus arquivos id_rsae id_rsa.pub. Preciso criar um arquivo allowed_keys na minha máquina local?

EDIT: É isso que recebo quando corro ssh -vvv -i id_rsa [youruser]@[yourLinode]:

debug3: authmethod_lookup publickey
debug3: remaining preferred: keyboard-interactive,password
debug3: authmethod_is_enabled publickey
debug1: Next authentication method: publickey
debug1: Offering RSA public key: id_rsa
debug3: send_pubkey_test
debug2: we sent a publickey packet, wait for reply
debug1: Authentications that can continue: publickey
debug2: we did not send a packet, disable method
debug1: No more authentication methods to try.
Permission denied (publickey).

PubKeyAuthentication

Configure seu cliente

1. Gere sua chave
   • ssh-keygen
2. Configure o ssh para usar a chave
   • vim ~/.ssh/config
3. Copie sua chave para o seu servidor
   • ssh-copy-id -i /path/to/key.pub SERVERNAME

Seu arquivo de configuração da etapa 2 deve ter algo semelhante ao seguinte:

Host SERVERNAME
Hostname ip-or-domain-of-server
User USERNAME
PubKeyAuthentication yes
IdentityFile ./path/to/key

Você pode adicionar IdentitiesOnly yespara garantir o sshuso de IdentityFilee sem outros arquivos-chave durante a autenticação, o que pode causar problemas e não é uma boa prática.

Solução de problemas

1. use a opção "-vvv"
2. Verifique se o servidor possui sua chave PUBLIC (.pub).
3. Verifique se o seu IdentiyFile aponta para a sua chave PRIVATE.
4. Verifique se o diretório .ssh possui 700 e se os arquivos possuem 700 permissões (rwx ------).
5. tail -f /var/log/auth.log (no servidor) e monitore os erros ao tentar fazer login
6. Se você tiver muitos arquivos de chave, tente IdentitiesOnly yeslimitar a autenticação para usar a chave única especificada.

Às vezes, o problema vem de permissões e propriedade. Por exemplo, se você quiser fazer o login como root, /root, .sshe authorized_keysdeve pertencer a raiz. Caso contrário, o sshd não poderá lê-los e, portanto, não saberá se o usuário está autorizado a efetuar login.

No seu diretório pessoal:

chown -R your_user:your_user .ssh

Quanto aos direitos, vá com 700 por .sshe 600 porauthorized_keys

chmod 700 .ssh
chmod 600 .ssh/authorized_keys

Você não precisa authorized_keysdo seu cliente.

Você deve dizer ao ssh-client para realmente usar a chave que você gerou. Existem várias maneiras de fazer isso. Apenas para o tipo de teste ssh -vvv -i .ssh/id_rsa [youruser]@[yourLinode]. Você precisará fornecer sua senha sempre que quiser se conectar ao servidor.

Se isso funcionou você pode adicionar a chave do ssh-agentcom ssh-add .ssh/id_rsa(você terá que fornecer a senha apenas uma vez por isso e ele deve funcionar enquanto você não sair / reboot)

Verifique também o valor de PasswordAuthenticationin /etc/ssh/sshd_confige, se for, noaltere para yes. Não se esqueça de reiniciar o serviço ssh depois disso.

O problema que tive foi usar as chaves erradas no cliente. Eu havia renomeado id_rsa e id_rsa.pub para outra coisa. Você pode renomeá-los para o padrão ou, quando emitir o comando ssh, use-o assim

ssh -i ~/.ssh/private_key username@host

Verifique também se o diretório pessoal do usuário (no servidor) realmente pertence ao usuário que está sendo transferido (foi definido como root: root no meu caso).

Deveria ter ficado:

sudo chown username:username /home/username;

Encontrei esse problema recentemente com meu servidor web.

Normalmente, mantenho uma lista de chaves autorizadas em todos os meus servidores ~/.ssh/authorized_keys2. Da minha experiência, sshdirá procurar ~/.ssh/authorized_keysou ~/.ssh/authorized_keys2por padrão.

No caso do meu servidor web, o /etc/ssh/sshd_configtinha esta linha

AuthorizedKeysFile    %h/.ssh/authorized_keys

ao invés de

AuthorizedKeysFile    %h/.ssh/authorized_keys2

Eu apliquei o último, reiniciei meu daemon ssh e resolvi meu problema ao fazer login com ssh usando meu pubkey.

Outra causa possível pode estar na AllowedUsersconfiguração /etc/ssh/sshd_conf. NOTA: a lista é delimitada por espaço (não por vírgula) conforme aprendi da maneira mais difícil.

AllowUsers user1 user2 user3

Se tudo mais falhar, verifique se o usuário de login pertence ao AllowedGroup do ssh. Ou seja, seus usuários são membros do grupo mostrado na seguinte linha no /etc/ssh/sshd_configservidor:

AllowGroups ssh #Here only users of 'ssh' group can login

No meu caso, o cliente é o ubuntu 14.04lts, o servidor foi win 2012 server rodando cygwin. Eu estava usando 'ssh administrator @ xxxx', quando o diretório do servidor de 2012 no cygwin era / home / Administrator. Portanto, diferenciava maiúsculas de minúsculas. Quando tentei 'ssh Administrator @ xxxx' (observe a letra A no administrador), funcionou bem.

Uma mensagem de erro como 'usuário não encontrado' teria me levado à solução muito mais rapidamente do que 'Permissão negada (chave pública, teclado interativo)'.

Eu tive o mesmo problema ao copiar a chave pública de um usuário comum (por exemplo, johndoe) de um sistema cPanel Centos para um servidor Ubuntu na AWS. Como sugerido por gertvdijk acima, eu verifiquei /var/log/auth.loge com certeza disse Authentication refused: bad ownership or modes for directory /home/johndoe. Acontece que eu tinha errado 777 ' /home/johndoeao tentar definir /home/johndoe/public_htmlcomo a raiz de documento do host virtual padrão para o apache2 (isso também não é necessário para essa tarefa).

Veja também as respostas aqui e aqui

O servidor precisa apenas ter a chave pública .ssh/authorized_keyse o cliente (computador em que você está trabalhando) precisa ter a chave privada (.pem ou se estiver usando SFTP com o Filezilla, .ppk)

Para aqueles usuários Putty como eu que chegaram a esse segmento, você também pode receber esse erro se se esqueceu de adicionar o usuário user @ Ip!

Outros sendo permissão no arquivo de chave chmod para 600)

ssh 1.1.1.1 -i /path/to/.pem file 
Permission denied (publickey).`

ssh user@1.1.1.1 -i /path/to/.pem file 

Isso foi o que funcionou para mim, a correção não é minha, mas eu prefiro escrevê-la aqui caso outra pessoa tenha o mesmo problema.

O autor original publicou aqui: digital-ocean-public-access-key-denied

sudo nano /etc/ssh/sshd_config

Substitua este

UsePAM yes
IgnoreUserKnownHosts no
PasswordAuthentication no

Com isso

UsePAM no
IgnoreUserKnownHosts no
PasswordAuthentication yes

Salve o arquivo e reinicie o ssh

reload ssh

ssh deve funcionar agora pedindo uma senha

Eu tive o mesmo problema descrito na pergunta. A saída da execução ssh -vvv -i id_rsa [youruser]@[yourLinode]na máquina cliente foi semelhante à descrita na pergunta. Eu verifiquei todas as permissões de arquivo e diretório, conforme recomendado nas outras respostas, e elas estavam corretas.

Aconteceu que, ao copiar o arquivo gerado id_rsa.pubpara a máquina do servidor, como arquivo ~username/.ssh/authorized_keys, eu acidentalmente omiti a palavra ssh-rsadesde o início. Adicioná-lo resolveu o problema.

Também funciona no Ubuntu 16.04.

O problema está dentro do sshd_configarquivo

Aqui está a solução ULTIMATE:

Faça logon como raiz no seu servidor Ubuntu

vi /etc/ssh/sshd_config

Agora vá para o final e mude o valor de "não" para "sim".

Deve ficar assim:

Altere para no para desativar as senhas de texto não criptografado

PasswordAuthentication yes
service sshd reload

para fazer efeito.

Agora você pode simplesmente usar uma chave usando o seguinte comando da sua máquina LOCAL (também conhecida como laptop etc)

Então, abra a nova janela do terminal e NÃO faça login no servidor, basta colocar este comando:

ssh-copy-id john @ serverIPAddress

(Substitua john pelo seu nome de usuário).

você deveria ir

Algumas pessoas que se perguntam podem ter configurado o acesso ssh para ser a chave apenas na conta raiz e, em seguida, criaram um novo usuário e não perceberam que precisam

ssh root@your-ip-address

rsync --archive --chown=[user]:[user] ~/.ssh /home/[user]

logout

Então tente novamente. Substitua [usuário] por sua nova conta de usuário.

Isso é comum ao configurar um novo servidor no DigitalOcean quando você usa as teclas ssh na instalação.

https://www.digitalocean.com/community/tutorials/initial-server-setup-with-ubuntu-18-04

No meu caso, o problema foi causado pela cópia em um .sshdiretório de uma máquina mais antiga. Acontece que minha configuração SSH mais antiga estava usando chaves DSA que foram descontinuadas . Mudar para um novo par de chaves, desta vez baseado em RSA, resolveu o problema para mim.

O método a seguir pode funcionar se você puder acessar a máquina A e a máquina B independentemente (por exemplo, da máquina C).

Se o ssh-copy-id não estiver funcionando, a autenticação por senha poderá ser desativada. A seguir está uma solução alternativa .

Ter a chave pública do machineA nas chaves autorizadas do machineB (ou seja, ~ / .ssh / allowed_keys) permitirá que você faça o ssh na máquinaA. Isso também se aplica ao scp.

Após gerar os pares de chaves usando: ssh-keygen

Na máquina A , executecat ~/.ssh/id_rsa.pub

Saída de amostra:

ssh-rsa AAAAB3NzaSGMFZW7yB anask@mahineA

Copie a chave impressa ( ⌘ Command+ Cou CRTL+ C) e adicione-a ao arquivo ~ / .ssh / allowed_keys na máquinaB .

Por exemplo, execute o seguinte na máquinaB :

echo 'ssh-rsa AAAAB3NzaSGMFZW7yB anask@mahineA' >> ~/.ssh/authorized_keys