Resumo:<\/p>\n
Servidor A acessar o servidor B sem que (b) solicite senha.<\/p>\n
Sendo a chave ja criada no servidor A (id_rsa.pub) copia-la para o servidor B colocando-a em .ssh\/authorized_keys
\nDar a permiss\u00e3o chmod 640 authorized_keys<\/p>\n
Lembrando que o usu\u00e1rio de acesso tem que ser o usu\u00e1rio no qual contem a chave.<\/p>\n
——————————————<\/p>\n
Creditos: Angelo – http:\/\/blogdonerd.com.br\/2010\/09\/estabelecendo-relacao-de-confianca-ssh-entre-servidores-linux\/#passo1<\/p>\n
Caso nao consiga visualizar o link acima:<\/p>\n
Quando se realiza backup de um servidor linux para outro atrav\u00e9s de scripts via SSH, \u00e9 extremamente importante a utiliza\u00e7\u00e3o de rela\u00e7\u00e3o de confian\u00e7a entre os servidores. A rela\u00e7\u00e3o de confian\u00e7a permite que um usu\u00e1rio de um servidor linux se conecte via ssh em outro servidor linux sem precisar digitar senha alguma.<\/p>\n
Isto pode soar estranho num primeiro momento, mas \u00e9 algo extremamente importante e seguro quando implementado corretamente.<\/p>\n
\u00c9 muito melhor ter a rela\u00e7\u00e3o de confian\u00e7a via SSH do que configurar senhas em texto puro em scripts de automatiza\u00e7\u00e3o de backup e outras atividades. Ali\u00e1s, n\u00e3o \u00e9 s\u00f3 para backup que a rela\u00e7\u00e3o de confian\u00e7a pode ser utilizada. J\u00e1 configurei este tipo de confian\u00e7a para melhorar a seguran\u00e7a de conex\u00f5es inseguras como MySQL e permitir uma conex\u00e3o permanente de um servidor a outro na Internet. Tamb\u00e9m j\u00e1 utilizei este tipo de rela\u00e7\u00e3o para acesso remoto a servidores, por\u00e9m neste caso adicionando uma senha extra no certificado de autentica\u00e7\u00e3o da rela\u00e7\u00e3o de confian\u00e7a.<\/p>\n
Este pequeno tutorial descreve os passos para estabelecer rela\u00e7\u00e3o de confian\u00e7a entre servidores Linux Ubuntu, por\u00e9m pode ser aplicado para outras distribui\u00e7\u00f5es tamb\u00e9m, inclusive para outros sistemas operacionais. Ele faz parte da s\u00e9rie de tutoriais sobre Backup de servidores Linux.<\/p>\n
Pr\u00e9-Requisitos
\nVoc\u00ea vai precisar de dois servidores Linux Ubuntu com o servi\u00e7o de SSH instalado e habilitado e tamb\u00e9m do utilit\u00e1rio ssh-keygen, que normalmente j\u00e1 vem instalado junto com o SSH. Se voc\u00ea n\u00e3o tiver o SSH instalado execute:<\/p>\n
$ sudo apt-get install ssh
\nAl\u00e9m disso voc\u00ea vai precisar das credencias de acesso de duas contas de usu\u00e1rio, uma em cada servidor onde ser\u00e1 configurada a rela\u00e7\u00e3o de confian\u00e7a.<\/p>\n
Tutorial
\nIremos utilizar dois servidores: Servidor1 e Servidor2 e dois usu\u00e1rios: usu\u00e1rio1 e usu\u00e1rio2, onde usu\u00e1rio1 \u00e9 uma conta de usu\u00e1rio do Servidor1 e usu\u00e1rio2 uma conta de usu\u00e1rio do Servidor2.<\/p>\n
A id\u00e9ia \u00e9 configurar uma rela\u00e7\u00e3o de confian\u00e7a de modo que o usu\u00e1rio1 consiga, a partir de uma sess\u00e3o no Servidor1, acessar o Servidor2 utilizando as credenciais do usu\u00e1rio2, sem digitar nenhuma senha. Em outras palavras, o usu\u00e1rio2 do Servidor2 confia no usu\u00e1rio1 do Servidor1, e por isso n\u00e3o pede senha.<\/p>\n
Isto \u00e9 feito baseado em criptografia assim\u00e9trica, onde o usu\u00e1rio1 possui duas chaves: uma p\u00fablica e uma privada. O conceito \u00e9 simples: tudo o que for criptografado com a chave p\u00fablica s\u00f3 pode ser descriptografado com a chave privada e vice-versa (o que for criptografado com a chave privada s\u00f3 pode ser descriptografado com a chave p\u00fablica).<\/p>\n
A chave p\u00fablica do usu\u00e1rio1 \u00e9 colocada em um lugar espec\u00edfico da conta do usu\u00e1rio2, de forma que o servi\u00e7o de SSH do Servidor2 consiga verificar a autenticidade do usu\u00e1rio1 atrav\u00e9s da criptografia e descriptografia de mensagens utilizando o par de chaves p\u00fablica e privada do usu\u00e1rio1.<\/p>\n
O que vamos fazer \u00e9:<\/p>\n
Gerar o par de chaves (p\u00fablica\/privada) do usu\u00e1rio1
\nCopiar a chave p\u00fablica do usu\u00e1rio1 para o Servidor2
\nATEN\u00c7\u00c2O: Jamais configure rela\u00e7\u00e3o de confian\u00e7a onde o usu\u00e1rio2 possua privil\u00e9gios administrativos ou pior ainda se ele for o root do Servidor2. Se algu\u00e9m conseguir comprometer o Servidor1, poder\u00e1 facilmente acessar o Servidor2 atrav\u00e9s da rela\u00e7\u00e3o de confian\u00e7a. \u00c9 claro que o atacante precisa saber que esta rela\u00e7\u00e3o existe, mas isso n\u00e3o \u00e9 muito dif\u00edcil de se descobrir pesquisando em logs de execu\u00e7\u00e3o, agendamento de scripts e outros arquivos. Tamb\u00e9m n\u00e3o recomendo que o usu\u00e1rio2 tenha privil\u00e9gios para executar comandos como root (sudo). Apesar de ainda ser necess\u00e1rio digitar a senha do usu\u00e1rio2 para permitir a execu\u00e7\u00e3o de comandos como root, um outro tipo de falha com o sudo poderia comprometer o servidor.<\/p>\n
A figura abaixo ilustra as rela\u00e7\u00f5es de confian\u00e7a que podem e as que n\u00e3o devem ser feitas:<\/p>\n
1. Gerar o par de chaves (p\u00fablica\/privada) do usu\u00e1rio1
\nAbra uma janela do shell ou se conecte via SSH ou console no Servidor1 com as credenciais do usu\u00e1rio1 e digite o seguinte comando:<\/p>\n
$ ssh-keygen -t rsa
\nO ssh-keygen ir\u00e1 solicitar um caminho para armazenar a chave privada. Pressione enter para deixar o padr\u00e3o. Ir\u00e1 solicitar tamb\u00e9m uma senha (passphrase) para proteger o par de chaves. Deixe em branco simplesmente pressionando enter. \u00c9 importante que a passphase seja em branco pois sen\u00e3o teriamos que digit\u00e1-la toda vez que nos conectarmos ao Servidor2, e \u00e9 justamente o que n\u00e3o queremos. Seu par de chaves ser\u00e1 gerado e a sa\u00edda (para o Ubuntu 10.04) ser\u00e1 a seguinte:<\/p>\n
$ ssh-keygen -t rsa
\nGenerating public\/private rsa key pair.
\nEnter file in which to save the key (\/home\/usu\u00e1rio1\/.ssh\/id_rsa):
\nCreated directory ‘\/home\/usu\u00e1rio1\/.ssh’.
\nEnter passphrase (empty for no passphrase):
\nEnter same passphrase again:
\nYour identification has been saved in \/home\/usu\u00e1rio1\/.ssh\/id_rsa.
\nYour public key has been saved in \/home\/usu\u00e1rio1\/.ssh\/id_rsa.pub.
\nThe key fingerprint is:
\nef:55:a6:8c:dc:21:02:78:e4:d5:b0:45:42:a9:ae:c4 usu\u00e1rio1@Servidor1
\nThe key’s randomart image is:
\n+–[ RSA 2048]—-+
\n| … oo |
\n| ..+ . .. |
\n| .o = o |
\n| . o + |
\n|.. S . . o |
\n| A. + = = |
\n|.. + = |
\n|. . . |
\n| . |
\n+—————–+
\nDois arquivos s\u00e3o gerados:<\/p>\n
\/home\/usu\u00e1rio1\/.ssh\/id_rsa: Cont\u00e9m a chave privada e deve ser mantido em segredo.
\n\/home\/usu\u00e1rio1\/.ssh\/id_rsa.pub: Cont\u00e9m a chave p\u00fablica e dever\u00e1 ser exportado para onde precisarmos da rela\u00e7\u00e3o de confian\u00e7a.
\n2. Copiar a chave p\u00fablica do usu\u00e1rio1 para o Servidor2
\nNo Servidor2 crie a pasta \/home\/usu\u00e1rio2\/.ssh, caso ela ainda n\u00e3o exista, e configure permiss\u00e3o 700. Para fazer isso, digite, no Servidor2:<\/p>\n
$ mkdir \/home\/usu\u00e1rio2\/.ssh
\n$ chmod 700 \/home\/usu\u00e1rio2\/.ssh
\nCopie o conte\u00fado do arquivo id_rsa.pub do usu\u00e1rio1 para o arquivo \/home\/usu\u00e1rio2\/.ssh\/authorized_keys. Voc\u00ea pode fazer isso digitando, no Servidor1, o seguinte comando:<\/p>\n
$ cat \/home\/usu\u00e1rio1\/.ssh\/id_rsa.pub | ssh usu\u00e1rio2@Servidor2 ‘cat – >> ~\/.ssh\/authorized_keys’
\nAgora \u00e9 s\u00f3 logar no Servidor2 a partir do Servidor1, sem precisar de senha:<\/p>\n
$ ssh usu\u00e1rio2@Servidor2
\nA primeira vez que se conectar no Servidor2 uma mensagem informando que a autenticidade do host n\u00e3o pode ser estabelecida ser\u00e1 mostrada. Voc\u00ea ter\u00e1 que responder yes para prosseguir. Isso ir\u00e1 guardar uma c\u00f3pia da chave p\u00fablica do Servidor2 no arquivo \/home\/usu\u00e1rio1\/.ssh\/know_hosts do Servidor1. Uma vez armazenada esta chave a pergunta de autenticidade nunca mais ser\u00e1 solicitada, a n\u00e3o ser que o servidor ou seu hostname sejam alterados.<\/p>\n
Para copiar um arquivo do Servidor1 para o Servidor2 voc\u00ea pode utilizar o scp:<\/p>\n
$ scp arquivo_de_origem usu\u00e1rio2@Servidor2:caminho_de_destino
\nPor exemplo, para copiar o arquivo \/etc\/issue do Servidor1 para a pasta \/tmp do Servidor2 digite:<\/p>\n
$ scp \/etc\/issue usu\u00e1rio2@Servidor2:\/tmp
\nObserva\u00e7\u00f5es
\nEm caso de falhas de autentica\u00e7\u00e3o, verifique o final do arquivo \/var\/log\/auth.log no Servidor2:<\/p>\n
$ tail \/var\/log\/auth.log
\nAs falhas mais comuns est\u00e3o relacionadas \u00e0 permiss\u00e3o e propriedade das pastas. A pasta home do usu\u00e1rio tem que pertencer a ele mesmo e n\u00e3o pode ter permiss\u00e3o de escrita para grupos e outros. A pasta .ssh n\u00e3o pode ter permiss\u00e3o alguma para grupos e outros.<\/p>\n
Voc\u00ea pode criar rela\u00e7\u00f5es de confian\u00e7a de v\u00e1rios servidores para um \u00fanico, bastando para isso adicionar mais chaves p\u00fablicas no arquivo authorized_keys utilizando o mesmo comando mostrado no passo 2.<\/p>\n
Espero que o artigo tenha sido \u00fatil. Qualquer d\u00favida, sugest\u00e3o ou relato de erros \u00e9 s\u00f3 postar nos coment\u00e1rios.<\/p>\n","protected":false},"excerpt":{"rendered":"
Resumo: Servidor A acessar o servidor B sem que (b) solicite senha. Sendo a chave ja criada no servidor A (id_rsa.pub) copia-la para o servidor B colocando-a em .ssh\/authorized_keys Dar a permiss\u00e3o chmod 640 authorized_keys Lembrando que o usu\u00e1rio de acesso tem que ser o…<\/p>\n","protected":false},"author":1,"featured_media":0,"comment_status":"open","ping_status":"open","sticky":false,"template":"","format":"standard","meta":[],"categories":[2],"tags":[],"_links":{"self":[{"href":"https:\/\/blog.abratel.com.br\/index.php?rest_route=\/wp\/v2\/posts\/412"}],"collection":[{"href":"https:\/\/blog.abratel.com.br\/index.php?rest_route=\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/blog.abratel.com.br\/index.php?rest_route=\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/blog.abratel.com.br\/index.php?rest_route=\/wp\/v2\/users\/1"}],"replies":[{"embeddable":true,"href":"https:\/\/blog.abratel.com.br\/index.php?rest_route=%2Fwp%2Fv2%2Fcomments&post=412"}],"version-history":[{"count":0,"href":"https:\/\/blog.abratel.com.br\/index.php?rest_route=\/wp\/v2\/posts\/412\/revisions"}],"wp:attachment":[{"href":"https:\/\/blog.abratel.com.br\/index.php?rest_route=%2Fwp%2Fv2%2Fmedia&parent=412"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/blog.abratel.com.br\/index.php?rest_route=%2Fwp%2Fv2%2Fcategories&post=412"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/blog.abratel.com.br\/index.php?rest_route=%2Fwp%2Fv2%2Ftags&post=412"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}