Estou criando um script de uma configuração remota de rsync e preciso adicionar um servidor remoto ao arquivo local known_hosts para evitar ser questionado sobre o que está abaixo quando o script é executado pela primeira vez:
A autenticidade do host '[hostname] ([IP address])' não pode ser estabelecida. A impressão digital da chave RSA é [impressão digital da chave]. Tem certeza de que deseja continuar conectando (sim / não)?
De acordo com Posso adicionar automaticamente um novo host para known_hosts? Eu tentei (com um novo arquivo known_hosts):
ssh-keyscan -H [hostname],[ip_address] >> ~/.ssh/known_hosts
ssh-keyscan -H [ip_address] >> ~/.ssh/known_hosts
ssh-keyscan -H [hostname] >> ~/.ssh/known_hosts
Mas isso não funciona, sempre sou solicitado a aceitar a impressão digital.
Quando deixo o ssh adicionar isso para mim, o hash da chave é muito diferente no arquivo know_hosts.
O que mais devo fazer para solucionar esse problema?
Tente isto:
ssh-keyscan -t rsa [ip_address]
Pegue a saída e cole-a em .ssh / known_hosts. Agora, se você quiser hash known_hosts, faça isso:
ssh-keygen -H
editar: Aqui está a solução de um comando. Ele usa o nome do host e os endereços IP e os hashes.
ssh-keyscan -Ht rsa [hostname],[IP address] >> known_hosts
A resposta do kschurig funcionará, mas não é necessariamente a mais segura. Ele ganha pontos de bônus por ir a milha extra para permitir que você identifique o servidor por mais de um URI - ou seja, nome do host e endereço IP. Ou seja, você pode continuar adicionando URIs válidos desse host estendendo a lista delimitada por vírgulas.
No entanto, eu estava procurando uma maneira mundana de contornar a interação manual do host desconhecido de clonar um repositório git como mostrado abaixo e isso deve ajudar a explicar o que está acontecendo e como você pode evitar essa parte do script relacionado a SSH. :
brad@computer:~$ git clone [email protected]:viperks/viperks-api.git
Cloning into 'viperks-api'...
The authenticity of host 'bitbucket.org (104.192.143.3)' can't be established.
RSA key fingerprint is 97:8c:1b:f2:6f:14:6b:5c:3b:ec:aa:46:46:74:7c:40.
Are you sure you want to continue connecting (yes/no)?
Observe a impressão digital da chave RSA ...
Então, isso é uma coisa do SSH, isso funcionará para o git sobre o SSH e apenas coisas relacionadas ao SSH em geral ...
brad@computer:~$ nmap bitbucket.org --script ssh-hostkey
Starting Nmap 7.01 ( https://nmap.org ) at 2016-10-05 10:21 EDT
Nmap scan report for bitbucket.org (104.192.143.3)
Host is up (0.032s latency).
Other addresses for bitbucket.org (not scanned): 104.192.143.2 104.192.143.1 2401:1d80:1010::150
Not shown: 997 filtered ports
PORT STATE SERVICE
22/tcp open ssh
| ssh-hostkey:
| 1024 35:ee:d7:b8:ef:d7:79:e2:c6:43:9e:ab:40:6f:50:74 (DSA)
|_ 2048 97:8c:1b:f2:6f:14:6b:5c:3b:ec:aa:46:46:74:7c:40 (RSA)
80/tcp open http
443/tcp open https
Nmap done: 1 IP address (1 host up) scanned in 42.42 seconds
Primeiro, instale o nmap no seu driver diário. O nmap é altamente útil para certas coisas, como detectar portas abertas e isso - verificando manualmente as impressões digitais do SSH. Mas voltemos ao que estamos fazendo.
Bom. Estou comprometido em vários lugares e máquinas que verifiquei - ou a explicação mais plausível de que tudo é ótimo é o que está acontecendo.
Essa "impressão digital" é apenas uma string encurtada com um algoritmo unidirecional para a nossa conveniência humana, com o risco de mais de uma string se resolver na mesma impressão digital. Acontece, eles são chamados de colisões.
Independentemente, voltemos à string original que podemos ver no contexto abaixo.
brad@computer:~$ ssh-keyscan bitbucket.org
# bitbucket.org SSH-2.0-conker_1.0.257-ce87fba app-128
no hostkey alg
# bitbucket.org SSH-2.0-conker_1.0.257-ce87fba app-129
bitbucket.org ssh-rsa AAAAB3NzaC1yc2EAAAABIwAAAQEAubiN81eDcafrgMeLzaFPsw2kNvEcqTKl/VqLat/MaB33pZy0y3rJZtnqwR2qOOvbwKZYKiEO1O6VqNEBxKvJJelCq0dTXWT5pbO2gDXC6h6QDXCaHo6pOHGPUy+YBaGQRGuSusMEASYiWunYN0vCAI8QaXnWMXNMdFP3jHAJH0eDsoiGnLPBlBp4TNm6rYI74nMzgz3B9IikW4WVK+dc8KZJZWYjAuORU3jc1c/NPskD2ASinf8v3xnfXeukU0sJ5N6m5E8VLjObPEO+mN2t/FZTMZLiFqPWc/ALSqnMnnhwrNi2rbfg/rd/IpL8Le3pSBne8+seeFVBoGqzHM9yXw==
# bitbucket.org SSH-2.0-conker_1.0.257-ce87fba app-123
no hostkey alg
Portanto, antecipadamente, temos uma maneira de solicitar uma forma de identificação do host original.
Neste ponto, estamos manualmente tão vulneráveis quanto automaticamente - as sequências de caracteres correspondem, temos os dados de base que criam a impressão digital e poderíamos solicitar esses dados de base (evitando colisões) no futuro.
Agora, use essa string de uma forma que evite perguntar sobre a autenticidade de um host ...
O arquivo known_hosts, neste caso, não usa entradas de texto sem formatação. Você saberá entradas com hash quando as vir, elas parecerão hashes com caracteres aleatórios em vez de xyz.com ou 123.45.67.89.
brad@computer:~$ ssh-keyscan -t rsa -H bitbucket.org
# bitbucket.org SSH-2.0-conker_1.0.257-ce87fba app-128
|1|yr6p7i8doyLhDtrrnWDk7m9QVXk=|LuKNg9gypeDhfRo/AvLTAlxnyQw= ssh-rsa AAAAB3NzaC1yc2EAAAABIwAAAQEAubiN81eDcafrgMeLzaFPsw2kNvEcqTKl/VqLat/MaB33pZy0y3rJZtnqwR2qOOvbwKZYKiEO1O6VqNEBxKvJJelCq0dTXWT5pbO2gDXC6h6QDXCaHo6pOHGPUy+YBaGQRGuSusMEASYiWunYN0vCAI8QaXnWMXNMdFP3jHAJH0eDsoiGnLPBlBp4TNm6rYI74nMzgz3B9IikW4WVK+dc8KZJZWYjAuORU3jc1c/NPskD2ASinf8v3xnfXeukU0sJ5N6m5E8VLjObPEO+mN2t/FZTMZLiFqPWc/ALSqnMnnhwrNi2rbfg/rd/IpL8Le3pSBne8+seeFVBoGqzHM9yXw==
A primeira linha de comentários aparece de maneira irritante - mas você pode se livrar dela com um simples redirecionamento por meio do ">" ou "> >" convenção.
Como eu fiz o meu melhor para obter dados não contaminados para serem usados para identificar um "host" e confiança, eu adicionarei essa identificação ao meu arquivo known_hosts no meu diretório ~ / .ssh. Uma vez que agora será identificado como um host conhecido, não receberei o prompt mencionado acima quando você era um jovem.
Obrigado por ficar comigo, aqui vai você. Estou adicionando a chave bitbucket RSA para que eu possa interagir com meus repositórios git de uma maneira não interativa como parte de um fluxo de trabalho de IC, mas faça o que você quiser.
#!/bin/bash
cp ~/.ssh/known_hosts ~/.ssh/known_hosts.old && echo "|1|yr6p7i8doyLhDtrrnWDk7m9QVXk=|LuKNg9gypeDhfRo/AvLTAlxnyQw= ssh-rsa AAAAB3NzaC1yc2EAAAABIwAAAQEAubiN81eDcafrgMeLzaFPsw2kNvEcqTKl/VqLat/MaB33pZy0y3rJZtnqwR2qOOvbwKZYKiEO1O6VqNEBxKvJJelCq0dTXWT5pbO2gDXC6h6QDXCaHo6pOHGPUy+YBaGQRGuSusMEASYiWunYN0vCAI8QaXnWMXNMdFP3jHAJH0eDsoiGnLPBlBp4TNm6rYI74nMzgz3B9IikW4WVK+dc8KZJZWYjAuORU3jc1c/NPskD2ASinf8v3xnfXeukU0sJ5N6m5E8VLjObPEO+mN2t/FZTMZLiFqPWc/ALSqnMnnhwrNi2rbfg/rd/IpL8Le3pSBne8+seeFVBoGqzHM9yXw==" >> ~/.ssh/known_hosts
Então, é assim que você fica virgem por hoje. Você pode fazer o mesmo com o github seguindo instruções semelhantes em seu próprio tempo.
Eu vi muitos posts de estouro de pilha dizendo para que você programaticamente adicione a chave às cegas sem qualquer tipo de verificação. Quanto mais você verificar a chave de diferentes máquinas em diferentes redes, mais confiança você pode ter de que o host é aquele que diz que é - e é o melhor que você pode esperar dessa camada de segurança.
ERRADO
ssh -oStrictHostKeyChecking = nenhum nome de host [comando]
ERRADO
ssh-keyscan -t rsa -H nome do host > > ~ / .ssh / known_hosts
Não faça nenhuma das coisas acima, por favor. Você tem a oportunidade de aumentar suas chances de evitar que alguém escute suas transferências de dados através de um homem no meio do ataque - aproveite essa oportunidade. A diferença é, literalmente, verificar se a chave RSA que você possui é a do servidor legítimo e agora você sabe como obter essas informações para compará-las, para poder confiar na conexão. Basta lembrar mais comparações de diferentes computadores & as redes geralmente aumentam sua capacidade de confiar na conexão.