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

388

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.

    
por Thom 16.04.2012 / 16:38

24 respostas

480

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.

    
por 17.04.2012 / 17:28
130

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
    
por 12.11.2012 / 08:55
49

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.

    
por 23.09.2012 / 11:31
26

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
    
por 07.11.2013 / 01:16
25

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

por 17.05.2013 / 10:46
22

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.

    
por 03.07.2012 / 09:34
12

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
    
por 08.09.2014 / 20:44
10

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
    
por 06.11.2014 / 10:34
7

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

    
por 03.06.2014 / 12:13
6

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
    
por 01.07.2013 / 17:41
4

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.

    
por 11.09.2013 / 16:29
3

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.

    
por 16.04.2012 / 16:44
3

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.

    
por 10.04.2013 / 12:09
3

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.

    
por 16.12.2014 / 11:44
2

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.

    
por 03.06.2014 / 20:36
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 chamá-lo como

script_name username remote_machine
    
por 17.04.2012 / 06:38
1

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.

    
por 09.01.2014 / 14:28
1

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!

    
por 30.09.2014 / 03:33
1

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

    
por 31.10.2014 / 20:08
1

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
    
por 06.05.2016 / 21:27
1

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.
por 19.03.2016 / 20:56
1

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

    
por 19.04.2018 / 16:44
0

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

    
por 26.11.2017 / 04:37
0

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

    
por 10.08.2018 / 23:31