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

Estou trabalhando a partir do URL que encontrei aqui:

http://web.archive.org/web/20160404025901/http://jaybyjayfresh.com/2009/02/04/logging-in-without-a-password-certificates-ssh/

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

Não tenho certeza do que fazer a seguir.

Verifique se as permissões no ~/.sshdiretório e seu conteúdo estão corretas. Quando configurei minha autenticação de chave ssh pela primeira vez, eu não tinha a ~/.sshpasta configurada corretamente e ela gritou comigo.

• Seu diretório pessoal ~, seu ~/.sshdiretório e o ~/.ssh/authorized_keysarquivo na máquina remota devem ser graváveis ​​somente por você: rwx------e rwxr-xr-xsão bons, mas rwxrwx---não são bons¹, mesmo se você for o único usuário do seu grupo (se você preferir modos numéricos: 700ou 755não 775) .
  Se ~/.sshou authorized_keysfor um link simbólico, o caminho canônico (com links simbólicos expandidos) é verificado .
• Seu ~/.ssh/authorized_keysarquivo (na máquina remota) deve ser legível (pelo menos 400), mas você também precisará ser gravável (600) se adicionar mais chaves a ele.
• Seu arquivo de chave privada (na máquina local) deve ser legível e gravável apenas por você:, rw-------ie 600.
• Além disso, se o SELinux estiver definido para imposição, talvez seja necessário executar restorecon -R -v ~/.ssh(veja, por exemplo, o bug do Ubuntu 965663 e o relatório de bug do Debian # 658675 ; isso está corrigido no CentOS 6 ).

Cept _{Exceto em algumas distribuições (Debian e derivadas) que corrigiram o código para permitir gravabilidade em grupo, se você for o único usuário em seu grupo.}

Se você tiver acesso root ao servidor, a maneira mais fácil de resolver esses problemas é executar o sshd no modo de depuração, emitindo algo como /usr/sbin/sshd -d -p 2222no servidor (o caminho completo para o executável do sshd é necessário, which sshdpode ajudar) e, em seguida, conectar-se a partir do cliente 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 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. A interrupção do daemon SSH não mata as conexões existentes, portanto, é possível fazer isso por meio de um terminal remoto, mas é um pouco arriscado - se a conexão for interrompida de alguma forma no momento em que a substituição da depuração não estiver em execução, você estará bloqueado na máquina até que você possa reiniciá-lo. Os comandos necessários:

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

(Dependendo da sua distribuição Linux, a primeira / última linha pode ser systemctl stop sshd.service/ em systemctl start sshd.servicevez disso.)

Seu diretório pessoal é criptografado? Nesse caso, para sua primeira sessão ssh, você precisará fornecer uma senha. A segunda sessão ssh no mesmo servidor está trabalhando com a chave de autenticação. Se for esse o caso, você pode mover seu authorized_keysdiretório para um diretório não criptografado e alterar o caminho ~/.ssh/config.

O que acabei fazendo foi criar uma /etc/ssh/usernamepasta, pertencente ao nome de usuário, com as permissões corretas, e colocar o authorized_keysarquivo lá. Em seguida, alterou a diretiva AuthorizedKeysFile /etc/ssh/configpara:

AuthorizedKeysFile    /etc/ssh/%u/authorized_keys

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

Depois de copiar as chaves para a máquina remota e colocá-las dentro da authorized_keysimpressora, você deve fazer algo assim:

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

Apenas tente estes comandos a seguir

1. ssh-keygen

   Pressione a tecla Enter até receber o prompt

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

   (Uma vez solicitará a senha do sistema host)

3. ssh root@ip_address

   Agora você deve conseguir fazer login sem nenhuma senha

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

O SELinux no RedHat / CentOS 6 tem um problema com a autenticação 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

Encontramos o mesmo problema e seguimos as etapas da resposta. Mas ainda 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 foi montado pelo NFS e os dois clientes estavam usando as mesmas chaves).

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

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 nome do host 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 foi alternar a chave rsa padrão para a que continha usuário @ myclient. Quando uma chave é o padrão, não há verificação do nome do cliente.

Depois, encontramos outro problema, após a troca. Aparentemente, as chaves estã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 recarregando as chaves no agente ssh:

ssh-add

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

• 'yes' a 'no' para ChallengeResponseAuthentication, PasswordAuthentication, UsePAM

• 'no' a 'yes' para PubkeyAuthentication

Com base em http://kaotickreation.com/2008/05/21/disable-ssh-password-authentication-for-added-security/

Certifique-se de que AuthorizedKeysFileaponta para o local correto, use %ucomo um espaço reservado para o nome de usuário:

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

Pode ser que você só precise descomentar a linha:

AuthorizedKeysFile .ssh / allowed_keys

Lembre-se de que você deve recarregar o serviço ssh para que as mudanças ocorram:

service sshd reload

Dois comentários: isso substituirá o arquivo original. Eu apenas copio a chave pública gerada e faço algo como:

cat your_public_key.pub >> .ssh/authorized_keys

Isso anexará 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 criar um link rígido apontando entre authorized_keyse authorized_keys2, apenas por precaução.

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.

Encontrei um problema semelhante e segui as etapas 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 realmente 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

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

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

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

No arquivo / etc / selinux / config, altere o SELINUX para desativado de impor que o ssh sem senha funcione com êxito.

No início, sou capaz de fazê-lo de uma maneira. Agora, pelas duas maneiras, sou capaz de fazer ssh sem senha.

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

chown -R root:root /root

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

Para mim, a solução era oposta à de Wojtek Rzepala : eu não percebi que ainda estava usando authorized_keys2, o que foi preterido . Minha configuração do ssh parou de funcionar em algum momento, presumivelmente quando o servidor foi atualizado. Renomear .ssh/authorized_keys2como .ssh/authorized_keyscorrigido o problema.

D'oh!

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

1. DO CLIENTE - Gerar chave: as chaves ssh-keygen -t rsa
   pública e privada ( id_rsa.pube id_rsa) serão automaticamente armazenadas no ~/.ssh/diretório.
   A configuração será mais fácil se você usar uma senha vazia. Se você não estiver disposto a fazer isso, siga este guia, mas verifique também o item abaixo.
   
   
2. DO CLIENTE - Copiar chave pública para o servidor : ssh-copy-id user@server
   a chave pública do cliente será copiada para o local do servidor ~/.ssh/authorized_keys .
   
   
3. DO CLIENTE - Conecte-se ao servidor:ssh user@server
   
   

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

• Verifique as ~/sshpermissões de pasta na máquina cliente e servidor .
• Faça check- /etc/ssh/sshd_configin no servidor para garantir que RSAAuthentication, PubkeyAuthenticatione as UsePAMopções não estejam desativadas, elas possam ser ativadas por padrão com yes.
• Se você digitou uma senha durante a geração da chave do cliente, tente ssh-agent& ssh-addpara obter conexões sem senha na sua sessão.
• Verifique o conteúdo /var/log/auth.logno servidor para descobrir o problema do motivo pelo qual a autenticação de chave é ignorada.

Eu estava tendo exatamente o mesmo problema com o PuTTY ao conectar-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 funcionou no PuTTY para conectar-se a outro host).

Graças ao comentário valioso de @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 as 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: esta pergunta discute como configurar o servidor SSH para aceitar chaves DSA: https://superuser.com/questions/1016989/ssh-dsa-keys-no-longer-work-for-password-less-authentication?lq = 1

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 invocá-lo como

script_name username remote_machine

Eu tive um problema semelhante com o ssh. No meu caso, o problema era que eu instalei o hadoop cloudera (do rpm no centos 6) e ele criou hdfs do usuário com o diretório home

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

Alterei / etc / passwd /var/lib/hadoop-hdfspara /home/hdfs, mudei o diretório home para um novo local e agora posso conectar-me com a autenticação de chave pública.

Eu só tinha este mesmo problema, e para mim a solução foi ajustado UsePAMpara no. Veja, mesmo com PasswordAuthenticationdefinido como no, você ainda receberá keyboard-interactive, e no meu caso, meu programa ssh local continuava por padrão, por algum motivo.

Contexto extra para ajudar qualquer pessoa com a mesma situação: estou conectando de um host executando o Dropbear a outro executando o OpenSSH. Com PasswordAuthenticatione UsePAMambos configurados nona máquina remota, receberei a seguinte mensagem se digitar ssh user@server:

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

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

Pode haver um pouco mais de informação aqui.

Depois de verificar as permissões e tentar várias outras soluções listadas aqui, finalmente removi o diretório ssh do servidor, a instalação da minha chave pública novamente.

Comandos do servidor:

# rm -rf ~/.ssh

Comandos locais:

# ssh-copy-id user@192.168.1.1        # where <user> is your username and <192.168.1.1> is the server IP

No servidor:

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

Foi directory permission issue. Era 777 no servidor, então I changed it back to 700. Este é o fixedmeu problema ssh password less login failuremesmo depois de copiar $USER/.ssh/id_rsa.pubpara o servidor $USER/.ssh/authorized_keys.

Outra opção é uma variante do 's @Jagadish resposta : para straceo daemon ssh.

Tem a vantagem significativa de não precisarmos parar o sshd, o que pode resultar em um bloqueio completo se algo der errado.

Primeiro, encontramos o pid do processo principal do sshd. Aqui podemos ver executando um pstree -pa|less.

  |-sshd,633 -D  <-- THIS IS WHAT WE WANT!
  |   `-sshd,21973   
  |       `-sshd,21996    
  |           `-bash,22000
  |               `-screen,638 -r

Depois de saber que o pid é 633, podemos strace, seguindo seus filhos:

strace -p 633 -s 4096 -f -o sux

O resultado será que tudo o que esse sshd e seus processos filhos fizeram será rastreado no arquivo nomeado suxno diretório local.

Em seguida, reproduza o problema.

Ele terá uma lista enorme de registros de chamadas do kernel, o que é incompreensível / irrelevante para nós, mas não em todos os lugares. No meu caso, o importante era isso:

6834  sendto(4, "<38>Jan 15 18:49:21 sshd[6834]: User cica not allowed because account is locked\0", 84, MSG_NOSIGNAL, NULL, 0) = 84

Isso significava que o sshd tentou registrar a mensagem User cica não permitida porque a conta está bloqueada - apenas não pôde, porque o log não é suficiente para isso. Mas já sabemos, a pubkey foi rejeitada porque a conta estava bloqueada.

Ainda não é uma solução - agora precisamos pesquisar no Google, o que significa uma "conta bloqueada" no caso do sshd. Provavelmente será um truque trivial /etc/passwd, /etc/shadowmas o importante é feito - o problema não é misterioso, mas facilmente debugável / googlável.

No meu caso, eu tinha todas as permissões corretas e, mesmo ao executar o ssh com o sinalizador -vvv, não conseguia descobrir qual era o problema.

Então eu gerei novo certificado no host remoto

ssh-keygen -t rsa -C "your_email@example.com"

e copiou chaves geradas para a máquina local e adicionou nova chave pública a ~ / .ssh / allowed_keys no host remoto

cat id_rsa.pub >> authorized_keys

O uso de chaves geradas da conexão da máquina host remota agora funciona. Portanto, se outras soluções falharem, outra coisa é tentar.

Meu cenário era que eu tinha um servidor NAS no qual criei um backupbotusuário, após a criação da minha conta principal, que foi capaz de efetuar login para criar o backupbotusuário inicialmente . Após mexer sudo vim /etc/ssh/sshd_confige criar o backupbotusuário, é vimpossível criar, pelo menos no Ubuntu 16.04, e com base na sua ~/.vimrcconfiguração, um arquivo de troca deixado pela edição de sua sessão do vim /etc/ssh/sshd_config.

Verifique se: /etc/ssh/.sshd_config.swpexiste e se o remove e reinicie o sshddaemon:

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

Isso resolveu magicamente o meu problema. Eu já havia verificado todas as minhas permissões e até as impressões digitais RSA das chaves pública e privada. Isso é estranho e provavelmente um bug sshd, especificamente nesta versão:

OpenSSH_7.4p1 Ubuntu-10, OpenSSL 1.0.2g 1 de março de 2016