Por que ainda estou recebendo uma solicitação de senha com o ssh com autenticação de chave pública?

Question

Estou trabalhando no URL que encontrei aqui:

link

Meu cliente ssh é o desktop Ubuntu 64 bit 11.10 e meu servidor é o Centos 6.2 de 64 bits. Eu segui as instruções. Eu ainda recebo uma solicitação de senha no ssh.

Não sei o que fazer a seguir.

    

Answer 1

Certifique-se de que as permissões no diretório ~/.ssh e seu conteúdo sejam adequadas. Quando eu configurei minha chave de autenticação ssh, eu não tinha a pasta ~/.ssh configurada corretamente, e ela gritou comigo.

• Seu diretório base ~ , seu diretório ~/.ssh e o arquivo ~/.ssh/authorized_keys na máquina remota devem ser graváveis somente por você: rwx------ e rwxr-xr-x estão bem, mas rwxrwx--- não é bom¹, mesmo se você for o único usuário em seu grupo (se preferir modos numéricos: 700 ou 755 , não 775 ).
  Se ~/.ssh ou authorized_keys for um link simbólico, o caminho canônico (com links simbólicos expandidos) é verificado .
• Seu arquivo ~/.ssh/authorized_keys (na máquina remota) deve ser legível (pelo menos 400), mas você precisará que ele também seja gravável (600) se você adicionar mais chaves a ele.
• Seu arquivo de chave privada (na máquina local) deve ser legível e gravável somente por você: rw------- , ou seja, 600 .
• Além disso, se o SELinux estiver configurado para impor, talvez seja necessário executar restorecon -R -v ~/.ssh (consulte, por exemplo, Bug do Ubuntu 965663 e relatório de bug # 658675 do Debian ; isto é paginado no CentOS 6 ).

¹ _{Exceto em algumas distribuições (Debian e derivativos) que corrigiram o código para permitir a capacidade de escrita de grupo se você for o único usuário em seu grupo.}

    

Answer 2

Se você tiver acesso root ao servidor, a maneira mais fácil de resolver tais problemas é executar o sshd no modo de depuração, emitindo algo como /usr/sbin/sshd -d -p 2222 no servidor (caminho completo para o executável sshd necessário, which sshd pode ajudar ) e, em seguida, conectando-se a partir do cliente com ssh -p 2222 user@host . Isso forçará o daemon SSH a permanecer em primeiro plano e exibir informações de depuração sobre cada conexão. Procure por algo como

debug1: trying public key file /path/to/home/.ssh/authorized_keys
...
Authentication refused: bad ownership or modes for directory /path/to/home/

Se não for possível usar uma porta alternativa, você pode parar temporariamente o daemon SSH e substituí-lo por um no modo de depuração. Parar o daemon SSH não elimina as conexões existentes, portanto, é possível fazer isso através de um terminal remoto, mas um pouco arriscado - se a conexão for interrompida de alguma forma quando a substituição de depuração não estiver em execução, você estará bloqueado da máquina até que você possa reiniciá-lo de alguma forma. Os comandos necessários:

service ssh stop
/usr/sbin/sshd -d
#...debug output...
service ssh start

    

Answer 3

O seu diretório pessoal é criptografado? Em caso afirmativo, para sua primeira sessão ssh, você deverá fornecer uma senha. A segunda sessão ssh para o mesmo servidor está trabalhando com a chave de autenticação. Se esse for o caso, mova seu authorized_keys para um diretório não criptografado e altere o caminho em ~/.ssh/config .

O que acabei fazendo foi criar uma pasta /etc/ssh/username , de propriedade do nome de usuário, com as permissões corretas, e colocar o arquivo authorized_keys lá. Em seguida, alterei a diretiva AuthorizedKeysFile em /etc/ssh/config para:

AuthorizedKeysFile    /etc/ssh/%u/authorized_keys

Isso permite que vários usuários tenham acesso ssh sem comprometer as permissões.

    

Answer 4

Depois de copiar as chaves para o computador remoto e colocá-las dentro do authorized_keys , você precisa fazer algo assim:

ssh-agent bash
ssh-add ~/.ssh/id_dsa or id_rsa

    

Answer 5

Apenas tente os seguintes comandos

1. ssh-keygen

   Pressione a tecla Enter até chegar ao prompt

2. ssh-copy-id -i root@ip_address

   (uma vez perguntará pela senha do sistema host)

3. ssh root@ip_address

   Agora você deve poder fazer o login sem qualquer senha

Answer 6

Eu enfrentei desafios quando o diretório inicial no controle remoto não tem privilégios corretos. No meu caso, o usuário mudou o diretório home para 777 para algum acesso local na equipe. A máquina não pôde mais se conectar com as chaves ssh. Mudei a permissão para 744 e ela começou a funcionar novamente.

    

Answer 7

O SELinux no RedHat / CentOS 6 tem um problema com a autenticação do pubkey , provavelmente quando alguns dos arquivos são criados O selinux não está configurando suas ACLs corretamente.

Para corrigir manualmente as ACLs do SElinux para o usuário root:

restorecon -R -v /root/.ssh

    

Answer 8

Nos deparamos com o mesmo problema e seguimos os passos da resposta. Mas ainda assim não funcionou para nós. Nosso problema era que o login funcionava de um cliente, mas não de outro (o diretório .ssh era montado pelo NFS e ambos os clientes usavam as mesmas chaves).

Então tivemos que dar um passo adiante. Ao executar o comando ssh no modo detalhado, você obtém muita informação.

ssh -vv user@host

O que descobrimos foi que a chave padrão (id_rsa) não foi aceita e, em vez disso, o cliente ssh ofereceu uma chave correspondente ao hostname do cliente:

debug1: Offering public key: /home/user/.ssh/id_rsa                                    
debug2: we sent a publickey packet, wait for reply                                        
debug1: Authentications that can continue: publickey,gssapi-keyex,gssapi-with-mic,password
debug1: Offering public key: /home/user/.ssh/id_dsa                                    
debug2: we sent a publickey packet, wait for reply                                        
debug1: Authentications that can continue: publickey,gssapi-keyex,gssapi-with-mic,password
debug1: Offering public key: user@myclient                                          
debug2: we sent a publickey packet, wait for reply                                        
debug1: Server accepts key: pkalg ssh-rsa blen 277                  

Obviamente, isso não funcionará em nenhum outro cliente.

Portanto, a solução em nosso caso era trocar a chave rsa padrão para a que continha user @ myclient. Quando uma chave é padrão, não há verificação para o nome do cliente.

Então nos deparamos com outro problema, depois da troca. Aparentemente, as chaves são armazenadas em cache no agente ssh local e recebemos o seguinte erro no log de depuração:

'Agent admitted failure to sign using the key'

Isso foi resolvido com o recarregamento das chaves para o agente ssh:

ssh-add

    

Answer 9

Seria SSH perder a configuração no final do servidor. O arquivo sshd_config do lado do servidor deve ser editado. Localizado em /etc/ssh/sshd_config . Nesse arquivo, altere as variáveis

• 'sim' para 'não' para ChallengeResponseAuthentication, PasswordAuthentication, UsePAM

• 'não' para 'sim' para PubkeyAuthentication

Com base no link

    

Answer 10

Verifique se AuthorizedKeysFile aponta para o local correto, use %u como espaço reservado para o nome de usuário:

# /etc/ssh/sshd_config
AuthorizedKeysFile /home/%u/authorized_keys

Pode ser que você precise apenas descomentar a linha:

AuthorizedKeysFile .ssh / authorized_keys

Lembre-se de que você precisa recarregar o serviço ssh para que as alterações ocorram:

service sshd reload

    

Answer 11

Minha solução foi que a conta estava bloqueada. Mensagem encontrada em / var / log / secure: Usuário não permitido porque a conta está bloqueada Solução: forneça ao usuário uma nova senha.

    

Answer 12

Dois comentários: isso substituirá o arquivo original. Acabei de copiar a chave pública gerada e fazer algo como:

cat your_public_key.pub >> .ssh/authorized_keys

Isso adicionará a chave que você deseja usar à lista de chaves pré-existente. Além disso, alguns sistemas usam o arquivo authorized_keys2 , por isso é uma boa ideia fazer um link físico apontando entre authorized_keys e authorized_keys2 , apenas no caso.

    

Answer 13

No arquivo / etc / selinux / config, alterando o SELINUX para desativado, impedindo o trabalho de ssh com senha sem sucesso.

Mais cedo, consegui fazer isso de uma maneira. Agora de ambas as maneiras eu posso fazer ssh sem senha.

    

Answer 14

Eu encontrei um problema semelhante e segui os passos usando o modo de depuração.

/usr/sbin/sshd -d

Isso mostrou o seguinte resultado

debug1: trying public key file /root/.ssh/authorized_keys
debug1: fd 4 clearing O_NONBLOCK
Authentication refused: bad ownership or modes for directory /root
debug1: restore_uid: 0/0
debug1: temporarily_use_uid: 0/0 (e=0/0)
debug1: trying public key file /root/.ssh/authorized_keys2
debug1: Could not open authorized keys '/root/.ssh/authorized_keys2': No such file or directory
debug1: restore_uid: 0/0
Failed publickey for root from 135.250.24.32 port 54553 ssh2
debug1: userauth-request for user root service ssh-connection method gssapi-with-mic

Foi muito confuso

[root@sys-135 ~]# ls -l /
drwxrwxrwx.   2 root root     4096 Dec 14 20:05 bin
drwxrwxrwx.   5 root root     1024 May  6  2014 boot
drwxrwxrwx.   2 root root     4096 Dec  2  2013 cgroup
drwxrwxrwx.  10 root root     1024 Sep 25 23:46 data
drwxrwxrwx. 124 root root    12288 Dec 16 10:26 etc
drwxrwxrwx.  11 root root     4096 Jan 14  2014 lib
drwxrwxrwx.   9 root root    12288 Dec 14 20:05 lib64
drwxrwxrwx.   2 root root    16384 Jan 10  2014 lost+found
drwxrwxrwx.   2 root root     4096 Jun 28  2011 media
drwxr-xr-x.   2 root root        0 Dec 10 14:35 misc
drwxrwxrwx.   2 root root     4096 Jun 28  2011 mnt
drwxrwxrwx.   4 root root     4096 Nov 24 23:13 opt
dr-xr-xr-x. 580 root root        0 Dec 10 14:35 proc
drwxrwxrwx.  45 root root     4096 Dec 16 10:26 root

Mostrou que o diretório raiz tinha permissões para cada um. Nós mudamos para que outros não tivessem permissões.

[root@sys-135 ~]# chmod 750 /root

A autenticação de chave começou a funcionar.

    

Answer 15

Uma coisa que eu tinha errado foi a propriedade no meu diretório home no sistema do servidor. O sistema do servidor foi definido como padrão: default, então eu:

chown -R root:root /root

E funcionou. Outra alternativa barata é desabilitar StrictModes: StirctModes no. em sshd_config. Isso pelo menos lhe dirá se os protocolos de troca e conexão de chaves são bons. Então você pode caçar as permissões ruins.

    

Answer 16

Estes passos devem ajudá-lo. Eu uso isso regularmente entre muitas máquinas Ubuntu 10.04 de 64 bits.

[ ! -f ~/.ssh/id_rsa.pub ] && ssh-keygen -t rsa;
ssh <username>@<remote_machine> 'mkdir -p ~/.ssh'
cat ~/.ssh/id_rsa.pub | ssh <username>@<remote_machine> 'cat >> ~/.ssh/authorized_keys'

você pode colocar isso em um script com alguns prompts e chamá-lo como

script_name username remote_machine

    

Answer 17

Eu tive um problema parecido com o ssh. No meu caso o problema foi que instalei o hadoop cloudera (do rpm no centos 6) e ele criou o hdfs do usuario com o diretório home

/var/lib/hadoop-hdfs (não padrão /home/hdfs ).

Alterei em / etc / passwd /var/lib/hadoop-hdfs para /home/hdfs , movi o diretório inicial para o novo local e agora posso me conectar à autenticação de chave pública.

    

Answer 18

Para mim, a solução foi de Wojtek Rzepala : Eu não percebi que ainda estava usando authorized_keys2 , que foi descontinuado . Minha configuração ssh parou de funcionar em algum momento, presumivelmente quando o servidor foi atualizado. A renomeação de .ssh/authorized_keys2 como .ssh/authorized_keys corrigiu o problema.

D'oh!

    

Answer 19

Acabei de ter o mesmo problema e, para mim, a solução foi definir UsePAM para no . Veja, mesmo com PasswordAuthentication definido como no , você ainda obterá keyboard-interactive e, no meu caso, meu programa ssh local manteve o padrão por algum motivo.

Fundo extra para ajudar qualquer pessoa com a mesma situação: estou conectando de um host executando o Dropbear para outro executando o OpenSSH. Com PasswordAuthentication e UsePAM ambos definidos no na máquina remota, receberei a seguinte mensagem se eu inserir ssh user@server :

ssh: Connection to user@server:22 exited: Disconnect received

Fornecendo o arquivo de identidade com -i , tudo funciona conforme esperado.

Pode haver um pouco mais de informação aqui

    

Answer 20

Após verificar as permissões e tentar várias outras soluções listadas aqui, finalmente removi o diretório ssh no servidor, a configuração minha chave pública novamente.

Comandos do servidor:

# rm -rf ~/.ssh

Comandos locais:

# ssh-copy-id [email protected]        # where <user> is your username and <192.168.1.1> is the server IP

    

Answer 21

No passado, encontrei alguns tutoriais que descrevem como obter uma configuração sem senha do ssh, mas alguns estão tristemente errados.
Vamos começar de novo e verificar todas as etapas:

1. FROM CLIENT - Gerar chave: ssh-keygen -t rsa
   A chave pública e privada ( id_rsa.pub e id_rsa ) será armazenada automaticamente no diretório ~/.ssh/ .
   A instalação será mais fácil se você usar uma frase secreta vazia. Se você não estiver disposto a fazer isso, siga este guia, mas também verifique o ponto abaixo.
2. FROM CLIENT - Copiar chave pública para servidor : ssh-copy-id user@server
   A chave pública do cliente será copiada para a localização do servidor ~/.ssh/authorized_keys . < br>
   
3. FROM CLIENT - Conecte-se ao servidor: ssh user@server
   
   

Agora, se ainda não estiver funcionando após as 3 etapas descritas, vamos tentar o seguinte:

• Verifique as permissões da pasta ~/ssh na máquina cliente e servidor .
• Verifique /etc/ssh/sshd_config no servidor para garantir que as opções RSAAuthentication , PubkeyAuthentication e UsePAM não estejam desativadas, elas podem ser ativadas por padrão com yes .
• Se você inseriu uma frase secreta ao gerar sua chave de cliente, tente ssh-agent & ssh-add para obter conexões sem senha na sua sessão.
• Verifique o conteúdo de /var/log/auth.log no servidor para descobrir o motivo pelo qual a autenticação de chaves é ignorada.

Answer 22

Eu estava tendo exatamente o mesmo problema com o PuTTY conectando-se a uma máquina Ubuntu 16.04. Foi intrigante porque o programa pscp do PuTTY estava funcionando bem com a mesma chave (e a mesma chave funcionava no PuTTY para se conectar a outro host).

Graças ao valioso comentário do @UtahJarhead, verifiquei meu arquivo /var/log/auth.log e encontrei o seguinte:

sshd[17278]: userauth_pubkey: key type ssh-dss not in PubkeyAcceptedKeyTypes [preauth]

Acontece que versões mais recentes do OpenSSH não aceitam chaves DSA por padrão. Depois que mudei de um DSA para uma chave RSA, funcionou bem.

Outra abordagem: essa questão discute como configurar o servidor SSH para aceitar chaves DSA: link

    

Answer 23

Meu cenário é que eu tenho um servidor NAS no qual criei um usuário backupbot , após a criação da minha conta principal, que conseguiu efetuar login para criar inicialmente o usuário backupbot . Depois de mexer com sudo vim /etc/ssh/sshd_config e criar o usuário backupbot , vim pode criar, pelo menos no Ubuntu 16.04, e com base no seu ~/.vimrc config, um arquivo de swap saiu do seu vim edição da sessão de /etc/ssh/sshd_config

Verifique se: /etc/ssh/.sshd_config.swp existe e, se ele for removido, reinicie o daemon sshd :

sudo rm /etc/ssh/.sshd_config.swp sudo service sshd restart

Isso resolveu magicamente o meu problema. Eu tinha verificado anteriormente todas as minhas permissões e até as impressões digitais da RSA das chaves públicas e privadas. Isso é estranho e provavelmente um bug com sshd OpenSSH_7.4p1 Ubuntu-10, OpenSSL 1.0.2g 1 Mar 2016

    

Answer 24

no servidor

ls -lh /home
sudo chmod 700 /home/$USER

Era directory permission issue , era 777 no servidor, portanto I changed it back to 700; this fixed meu problema com ssh password less login failure mesmo depois de copiar $USER/.ssh/id_rsa.pub para o servidor $USER/.ssh/authorized_keys