SSH relação de confiança [Urgente]

degusto9
(usa Ubuntu)

Enviado em 19/10/2017 - 01:18h

Pessoal!
Quem puder me ajudar eu ficarei agradecido. Eu tenho os servidores Server 1, Server 2 e Server 3 e estou querendo manter a relação de confiança entres eles e um servidor XPTO. Então, eu peguei as chaves desses servidores chave1.pub do Server 1, chave2.pub do Server 2 e chave3.pub do Server 3 e coloco no arquivo authorized_keys do servidor XPTO. Depois de feito isso, eu faço o teste de conexão usando SSH dos meus três servidores para o servidor XPTO e só consigo conectar sem pedir senha, logo estabeleci a relação de confiança, do Server 2 para o servidor XPTO. O que poderá ter acontecido com o server 1 e server 2 para eles não se conectarem?
Espero a ajuda de vocês.

signout
(usa Slackware)

Enviado em 19/10/2017 - 18:21h

Boas,
Algumas sugestões:

Verifique no servidor XPTO se as configurações do sshd_config estão ok (PubkeyAuthentication yes, que é o valor default)
De uma olhada se ao copiar a chave a linha não foi truncada.
Uma outra coisa que pode te ajudar é fazer o ssh -v para o servidor XPTO e ver as mensagens de erro.

Espero que ajude
[]s

degusto9
(usa Ubuntu)

Enviado em 23/10/2017 - 13:44h

Obrigado meu caro. Mas o que eu não entendi é por quê o Server 2 conseguiu se conectar com o servidor XPTO, porém o Server 1 e Server 3 não. Sabendo que todas as chaves dos Server's estão no servidor XPTO. Entende?

signout
(usa Slackware)

Enviado em 23/10/2017 - 16:06h

Boas,

Então, um dos motivos seria que a chave do servidor 1 e 3 estão truncadas ou incorretas no servidor XPTO.
Se as chaves do servidor 1 e 3 funcionam em outros servidores, então as chaves estão com algum problema no arquivo authorized_keys no servidor XPTO

Espero que ajude.
[]s

degusto9
(usa Ubuntu)

Enviado em 26/10/2017 - 14:29h

Eu estou pedindo para o responsável não copiar na "mão". Eu estou pedindo para o responsável dar um cat id_server1.pub >> authorized_keys. Certo?

As chaves do server1 funciona em outro servidor, porém a chave do server3 não funciona na maioria das vezes. Vou te dar um exemplo da resposta quando tento estabelecer a conexão.
The authenticity of host 'x.x.x.x (x.x.x.x)' can't be established.
RSA key fingerprint is x:x:x:x:x:x:x:x:x:x:x:x:x:x:x:x.
Are you sure you want to continue connecting (yes/no)? yes
Warning: Permanently added 'x.x.x.x' (RSA) to the list of known hosts.

signout
(usa Slackware)

Enviado em 26/10/2017 - 19:10h

Boas...


Algumas considerações:

authorized_keys = autenticação do usuário na maquina utilizando chaves
known_hosts = autenticação do servidor(maquina) para o cliente(maquina)

A parte que voce mandou sobre id_server1.pub para o authorized_keys refere-se à autenticação do usuário no servidor.

A segunda parte refere-se à auntenticação de maquina para maquina...
Ao efetuar ssh pela primeira vez em um servidor, o servidor manda a chave publica para o cliente e prova que ele tem o respectivo par (e essa chave é adicionada ao arquivo .ssh/known_hosts (caso essa chave seja alterada no servidor ou a conexão não é efetuada ou ele exibira uma mensagem falando que a chave esta diferente).



(1)
Se a autenticação do usuário na maquina utilizando par de chaves esta apresentando problemas, pode ser que a chave copiada esteja truncada, seja a chave incorreta, ou que na geração do par (ssh-keygen) alguem tenha colocado um senha, ou o servidor de destino não permita esse tipo de autenticação (o que não deve ser o caso, já que pelo server1 para xpto funciona).

(2)
Se todas as vezes ao conectao ao servidor xpto ele pede para adicionar a chave no known_hosts, então pode ser que o arquivo known_hosts esteja sendo apagado/alterado/movido ou a chave do host (xpto) esteja sendo alterada de tempos em tempos (não sei te afirmar com certeza).


No caso (1), voce pode copiar a chave do servidor 3 (id_server.pub) para outro servidor que não seja o xpto e que tenha somente esta chave e fazer o teste, se funcionar, então a chave esta correta e o problema de truncar a linha é resolvido com o comando que voce mandou (cat id_server.pub >> authorized_keys ).

No caso (2), verifique se o arquivo known_hosts esta sendo modificado/apagado e em ultimo caso voce pode criar o arquivo config em .ssh e dentro dele colocar a opção "StricHostKeyChecking no" (de uma olhada no man 5 ssh_config e veja as implicações disto no seu ambiente), assim ele não apresentará a mensagem que voce postou.

cat config
StrictHostKeyChecking no


Espero que ajude.

[]s