desenv-web-rp.com

Por que ainda estou recebendo uma solicitação 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.

509
Thom

Verifique se as permissões no ~/.ssh diretório e seu conteúdo são adequados. Quando configurei minha autenticação de chave ssh pela primeira vez, eu não tinha o ~/.ssh pasta devidamente configurada, e gritou comigo.

  • O seu diretório pessoal ~, seu ~/.ssh diretório e o ~/.ssh/authorized_keys O arquivo na máquina remota deve ser gravável somente por você: rwx------ e rwxr-xr-x estão bem, mas rwxrwx--- não é bom¹, mesmo se você for o único usuário do seu grupo (se você preferir os modos numéricos: 700 ou 755, não 775).
    E se ~/.ssh ou authorized_keys é um link simbólico, o caminho canônico (com links simbólicos expandidos) é verificado .
  • Seu ~/.ssh/authorized_keys O arquivo (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-------, ou seja, 600.
  • Além disso, se o SELinux estiver definido como imposição, talvez seja necessário executar restorecon -R -v ~/.ssh (veja por exemplo bug do Ubuntu 96566 e relatório de bug Debian # 658675 ; este é corrigido no CentOS 6 ).

¹ 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.

601
Rob

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 2222 no servidor (é necessário o caminho completo para o executável sshd, which sshd pode ajudar) e, em seguida, conectar-se a partir do cliente com ssh -p 2222 [email protected]. Isso forçará o daemon SSH a permanecer em primeiro plano e exibir informações de depuração sobre todas as conexões. 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 tanto 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/systemctl start sshd.service em vez de.)

154
Tgr

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_keys para um diretório não criptografado e altere o caminho em ~/.ssh/config.

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

AuthorizedKeysFile    /etc/ssh/%u/authorized_keys

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

55
cee

Após copiar as chaves para a máquina remota e colocá-las dentro do authorized_keys você precisa fazer algo assim:

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

Apenas tente estes comandos a seguir

  1. ssh-keygen

    Pressione a tecla Enter até obter o prompt

  2. ssh-copy-id -i [email protected]_address

    (Uma vez solicitará a senha do sistema host)

  3. ssh [email protected]_address

    Agora você deve conseguir fazer login sem nenhuma senha

31
Ravindra

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. Alterei a permissão para 744 e ela começou a funcionar novamente.

29
Sahil

Encontramos o mesmo problema e seguimos as etapas da resposta. Mas ainda não funcionou para nós. Nosso problema foi que o logon funcionou 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 [email protected]

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: [email protected]                                          
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
16
Joachim Nilsson

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
14
David Mackintosh

Seria a falta de configuração do SSH no final do servidor. O arquivo sshd_config do lado 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

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

10
nish

Verifique se AuthorizedKeysFile aponta para o local correto, use %u como 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 alterações ocorram:

service sshd reload
6
Dziamid

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

[[email protected] ~]# 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 todos. Nós o alteramos para que outros não tivessem permissões.

[[email protected] ~]# chmod 750 /root

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

4
Jagadish

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.

4
user46932

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_keys e authorized_keys2, apenas no caso de.

4
Wojtek

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.

3
Will

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.

3
chinna

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: ssh-keygen -t rsa
    As chaves pública e privada (id_rsa.pub E id_rsa) Serão automaticamente armazenadas no diretório ~/.ssh/.
    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. FROM CLIENT - Copie a chave pública para server: ssh-copy-id [email protected]
    A chave pública do cliente será copiada para localização do servidor~/.ssh/authorized_keys.

  3. DO CLIENTE - Conecte-se ao servidor: ssh [email protected]

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

  • Verifique as permissões da pasta ~/ssh Nas máquinas cliente e servidor.
  • Marque /etc/ssh/sshd_config No servidor para garantir que as opções RSAAuthentication, PubkeyAuthentication e UsePAM não estejam desabilitadas, elas podem ser ativadas por padrão com yes.
  • Se você digitou uma senha ao gerar sua chave de cliente, tente ssh-agent E ssh-add Para obter conexões sem senha na sua sessão.
  • Verifique o conteúdo de /var/log/auth.log No server para encontrar o problema do porquê a autenticação de chave é ignorada.
2
marc

Para mim, a solução era oposta de Wojtek Rzepala : eu não percebi que ainda estava usando authorized_keys2, que foi descontinuado . Minha configuração do ssh parou de funcionar em algum momento, presumivelmente quando o servidor foi atualizado. Renomeando .ssh/authorized_keys2 Como .ssh/authorized_keys corrigiu o problema.

D'oh!

2
Michael Scheper

Eu estava tendo exatamente o mesmo problema ao conectar o PuTTY 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

2
Chad

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 [email protected]        # where <user> is your username and <192.168.1.1> is the server IP
2
Steven C. Howell

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).

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

1
Andrzej Jozwik

No servidor:

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

Isso foi directory permission issue. Era 777 no servidor, então I changed it back to 700. Este fixed meu problema com ssh password less login failure mesmo depois de copiar $USER/.ssh/id_rsa.pub Ao servidor $USER/.ssh/authorized_keys.

1
fastrizwaan

Acabei de ter o mesmo problema e, para mim, a solução foi definir UsePAM como no. Veja, mesmo com PasswordAuthentication definido como no, você ainda terá 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 PasswordAuthentication e UsePAM configuram no na máquina remota, receberei a seguinte mensagem se eu inserir ssh [email protected]:

ssh: Connection to [email protected]:22 exited: Disconnect received

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

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

1
Marty

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
1
Sriharsha

Meu cenário era que eu tinha um servidor NAS no qual criei um usuário backupbot, após a criação da minha conta principal, que foi capaz de efetuar login para criar inicialmente o backupbot user. Depois de brincar com Sudo vim /etc/ssh/sshd_config, e criando o usuário backupbot, vim pode criar, pelo menos no Ubuntu 16.04, e com base no seu ~/.vimrc config, um arquivo de troca restante da edição de sua sessão do vim de /etc/ssh/sshd_config.

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

$ 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 com sshd, especificamente nesta versão:

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

0
rivanov

Ainda outra opção é uma variante do resposta : to strace do daemon ssh do @Jagadish.

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 vê-lo 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 chamado sux no 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

Significou que o sshd tentou registrar a mensagem Usuário cica não permitido porque a conta está bloqueada - só não pôde, porque o log não é suficiente detalhado 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á trivial /etc/passwd, /etc/shadow magia, mas o importante é feito - o problema não é misterioso, mas facilmente debugável/googlável.

0
peterh - Reinstate Monica

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 em Host remoto

ssh-keygen -t rsa -C "[email protected]"

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 remota da máquina host agora funciona. Portanto, se outras soluções falharem, é outra coisa a tentar.

0
kovinet