Servidor OpenSSH se recusa a aceitar autenticação de chave


13

Tentei usar a autenticação de chave pública no meu novo servidor e me deparei com esse problema.

$ ssh -v -i .ssh/server 192.168.1.100
OpenSSH_5.6p1, OpenSSL 0.9.8r 8 Feb 2011
debug1: Reading configuration data .ssh/config
debug1: Applying options for *
debug1: Reading configuration data /etc/ssh_config
debug1: Applying options for *
debug1: Connecting to 192.168.1.100 [192.168.1.100] port 22.
debug1: Connection established.
debug1: identity file .ssh/server type -1
debug1: identity file .ssh/server-cert type -1
debug1: Remote protocol version 2.0, remote software version OpenSSH_5.8p1 Debian-1ubuntu3
debug1: match: OpenSSH_5.8p1 Debian-1ubuntu3 pat OpenSSH*
debug1: Enabling compatibility mode for protocol 2.0
debug1: Local version string SSH-2.0-OpenSSH_5.6
debug1: SSH2_MSG_KEXINIT sent
debug1: SSH2_MSG_KEXINIT received
debug1: kex: server->client aes128-ctr hmac-md5 none
debug1: kex: client->server aes128-ctr hmac-md5 none
debug1: SSH2_MSG_KEX_DH_GEX_REQUEST(1024<1024<8192) sent
debug1: expecting SSH2_MSG_KEX_DH_GEX_GROUP
debug1: SSH2_MSG_KEX_DH_GEX_INIT sent
debug1: expecting SSH2_MSG_KEX_DH_GEX_REPLY
debug1: Host '192.168.1.100' is known and matches the RSA host key.
debug1: Found key in .ssh/known_hosts:1
debug1: ssh_rsa_verify: signature correct
debug1: SSH2_MSG_NEWKEYS sent
debug1: expecting SSH2_MSG_NEWKEYS
debug1: SSH2_MSG_NEWKEYS received
debug1: Roaming not allowed by server
debug1: SSH2_MSG_SERVICE_REQUEST sent
debug1: SSH2_MSG_SERVICE_ACCEPT received
debug1: Authentications that can continue: publickey,password
debug1: Next authentication method: publickey
debug1: Trying private key: .ssh/server
debug1: read PEM private key done: type RSA
debug1: Authentications that can continue: publickey,password
debug1: Next authentication method: password

e então eu tenho que inserir minha senha para entrar.

Mas, se eu já tiver uma sessão conectada a esse servidor (conectado por senha), a conexão a seguir utilizará a autenticação de chave para evitar a entrada de senha.

Se ainda não houver uma conexão SSH estabelecida, não consigo conectar sem a senha de entrada.

Isso é realmente estranho para mim, verifiquei o MD5 /usr/sbin/sshdentre o novo servidor e o outro servidor normal, é o mesmo. Depois copiei o /etc/ssh/sshd_configdo outro servidor normal para o novo servidor e executei service ssh restart. O problema ainda existe.

Como devo corrigir isso?

Respostas:


10

Verifique se a .sshpasta e os arquivos dentro dela na máquina cliente são legíveis apenas pelo proprietário ( chmod -R 600 .ssh) e se o proprietário está correto para a pasta e os arquivos (use o chowncomando, se necessário).

Verifique também a authorized_keyspasta e o arquivo no servidor (provavelmente na /root/.sshpasta ou na pasta inicial do usuário que está tentando fazer login) para garantir que suas permissões e proprietário sejam definidos da mesma maneira.


Editar: com base em mais comentários (e algumas suposições!) - você pode verificar /etc/ssh/sshd_confige ver se o seguinte parâmetro está definido como abaixo. Caso contrário, tente editá-lo.

AuthorizedKeysFile /home/%u/.ssh/authorized_keys

Observe que isso pressupõe que você não efetue login remotamente como root


meu .ssh é 700 e os arquivos .ssh são 600, e verifiquei ~ / .ssh / allowed_keys na máquina remota. A autenticação da chave pública da instalação é a primeira coisa que faço depois de instalar o sistema, portanto, não é provável que isso ocorra com outras operações. btw, problema ainda ..
lxyu

OK - estou adicionando algo à minha resposta com base nisso.
precisa saber é o seguinte

existe uma linha de "#AuthorizedKeysFile% h / .ssh / allowed_keys". Eu tentei comentar, mas não adianta ... btw, o mesmo '/ usr / sbin / sshd' com o mesmo 'sshd_config', como eles se comportam de maneira diferente?
precisa saber é

Finalmente eu reinstalei o ubuntu, então configurei o openssh-server em um minuto e ele está funcionando bem agora ... Ainda não sei o que há de errado. :(
lxyu

Às vezes é realmente difícil descobrir qual é o problema. Certa vez, escrevi incorretamente as teclas autorizadas como chaves autorizadas. Eu precisava de cerca de uma hora para solucionar isso. Você viu o erro de ortografia? É realmente complicado! :-)
nalply

4

Corrigi meu próprio caso desse erro removendo id_rsa.pubdo .ssh.

Eu havia copiado id_rsade outra máquina e distribuído por vários clientes fictícios. Portanto, id_rsae id_rsa.pubforam realmente chaves diferentes que impediram o uso de todos id_rsa.

Nenhuma mensagem de erro para indicar isso claramente. Eu descobri isso essencialmente por acidente, tentando colocar as diferentes máquinas em um estado idêntico.


3

Pela minha descoberta, a menor permissão do diretor da casa do alvo é 750. Se o pedaço do mundo não 0for, não funcionará.

Por exemplo. para o diretório raiz:

drwxr-x--- 3 root root 4096 Jul 20 11:57 root

Proximo é /root/.ssh

drwx------  2 root root  4096 Jul 17 03:28 .ssh

Então /root/.ssh/authorized_keys

-rw------- 1 root root 1179 Jul 17 03:28 authorized_keys

3

No meu caso, as permissões no diretório inicial eram em 775vez de 0755ou inferiores.

O caminho inteiro para o arquivo allowed_keys, ou seja, /home/user/.ssh/deve ser 0755ou menos.


OBRIGADO Isso acabou de ler uma dor de cabeça que tive por uma semana agora. Única a maioria das pessoas mencionar a pasta .ssh (700) e os authorized_keys (600)
Jonathan Komar

2

Depois de me preocupar muito, consegui a solução do problema:

O diretório inicial do usuário não deve ter permissão 777ou permissão de gravação no mundo. Se for o caso, a verificação da chave SSH falhará e você precisará colocar a senha para o login.


1

Apenas verifique se a conta para a qual você está tentando usar o ssh é um usuário com uma senha no servidor remoto. Eu apenas bati minha cabeça na parede por meia hora antes de encontrar esta resposta aqui: /programming//a/14421105/758174


1

Se a sua /etc/ssh/sshd_configlinha não estiver comentada, sua configuração do SSH permitirá apenas uma lista fixa de usuários ssh no sistema e você precisará adicionar novas contas à lista:

AllowUsers root user1 user2 user3

Quaisquer outros usuários, além dos listados acima, que tentam efetuar login via SSH receberiam essas mensagens de erro enigmáticas:

Roaming not allowed by server

0

Descobri que depois de alterar meu nome de usuário e grupo (mas não os IDs) /etc/passwde /etc/group, mas esquecendo-me de alterar de /etc/shadowacordo, recebi a mesma mensagem "Não é permitido roaming".

Ao utilizar nosso site, você reconhece que leu e compreendeu nossa Política de Cookies e nossa Política de Privacidade.
Licensed under cc by-sa 3.0 with attribution required.