ti-enxame.com

Posso adicionar automaticamente um novo host ao known_hosts?

Aqui está minha situação: estou configurando um equipamento de teste que, a partir de um cliente central, inicia várias instâncias de máquina virtual e executa comandos nelas via ssh. As máquinas virtuais terão nomes de host e endereços IP anteriormente não utilizados, portanto, eles não estarão no ~/.ssh/known_hosts arquivo no cliente central.

O problema que estou tendo é que o primeiro comando ssh executado em uma nova instância virtual sempre aparece com um prompt interativo:

The authenticity of Host '[hostname] ([IP address])' can't be established.
RSA key fingerprint is [key fingerprint].
Are you sure you want to continue connecting (yes/no)?

Existe uma maneira de contornar isso e fazer com que o novo host já seja conhecido pela máquina cliente, talvez usando uma chave pública que já esteja inserida na imagem da máquina virtual? Eu realmente gostaria de evitar ter que usar o Expect ou o que quer que seja para responder ao Prompt interativo, se puder.

265
gareth_bowles

Defina a opção StrictHostKeyChecking como no, no arquivo de configuração ou via -o:

ssh -o StrictHostKeyChecking=no [email protected]

152
Ignacio Vazquez-Abrams

Na IMO, a melhor maneira de fazer isso é o seguinte:

ssh-keygen -R [hostname]
ssh-keygen -R [ip_address]
ssh-keygen -R [hostname],[ip_address]
ssh-keyscan -H [hostname],[ip_address] >> ~/.ssh/known_hosts
ssh-keyscan -H [ip_address] >> ~/.ssh/known_hosts
ssh-keyscan -H [hostname] >> ~/.ssh/known_hosts

Isso garantirá que não haja entradas duplicadas, que você esteja coberto tanto pelo nome do host quanto pelo endereço IP, e também fará o hash da saída, uma medida extra de segurança.

235
yardena

Para os preguiçosos:

ssh-keyscan -H <Host> >> ~/.ssh/known_hosts

-H faz hash no nome do host/endereço IP

97
fivef

Como mencionado, o uso da digitalização de teclas seria a maneira correta e discreta de fazer isso.

ssh-keyscan -t rsa,dsa Host 2>&1 | sort -u - ~/.ssh/known_hosts > ~/.ssh/tmp_hosts
mv ~/.ssh/tmp_hosts ~/.ssh/known_hosts

O acima será o truque para adicionar um host, SOMENTE se ele ainda não tiver sido adicionado. Também não é seguro para simultaneidade; você não deve executar o snippet na mesma máquina Origin mais de uma vez ao mesmo tempo, pois o arquivo tmp_hosts pode ser derrotado, resultando no inchaço do arquivo known_hosts ...

44
ysawej

Você poderia usar ssh-keyscan comando para pegar a chave pública e anexá-la ao seu known_hosts Arquivo.

19
Alex

É assim que você pode incorporar ssh-keyscan em seu jogo:

---
# ansible playbook that adds ssh fingerprints to known_hosts
- hosts: all
  connection: local
  gather_facts: no
  tasks:
  - command: /usr/bin/ssh-keyscan -T 10 {{ ansible_Host }}
    register: keyscan
  - lineinfile: name=~/.ssh/known_hosts create=yes line={{ item }}
    with_items: '{{ keyscan.results | map(attribute='stdout_lines') | list }}'
8
Zart

Eu faço um script de uma linha, um pouco longo, mas útil para fazer essa tarefa para hosts com vários IPs, usando Dig e bash

(Host=github.com; ssh-keyscan -H $Host; for ip in $(Dig @8.8.8.8 github.com +short); do ssh-keyscan -H $Host,$ip; ssh-keyscan -H $ip; done) 2> /dev/null >> .ssh/known_hosts
7
Felipe Alcacibar

essa seria uma solução completa, aceitando a chave Host pela primeira vez apenas

#!/usr/bin/env ansible-playbook
---
- name: accept ssh fingerprint automatically for the first time
  hosts: all
  connection: local
  gather_facts: False

  tasks:
    - name: "check if known_hosts contains server's fingerprint"
      command: ssh-keygen -F {{ inventory_hostname }}
      register: keygen
      failed_when: keygen.stderr != ''
      changed_when: False

    - name: fetch remote ssh key
      command: ssh-keyscan -T5 {{ inventory_hostname }}
      register: keyscan
      failed_when: keyscan.rc != 0 or keyscan.stdout == ''
      changed_when: False
      when: keygen.rc == 1

    - name: add ssh-key to local known_hosts
      lineinfile:
        name: ~/.ssh/known_hosts
        create: yes
        line: "{{ item }}"
      when: keygen.rc == 1
      with_items: '{{ keyscan.stdout_lines|default([]) }}'
7
mazac

Eu tive um problema semelhante e descobri que algumas das respostas fornecidas me levaram apenas a um caminho para uma solução automatizada. A seguir, o que acabei usando, espero que ajude:

ssh -o "StrictHostKeyChecking no" -o PasswordAuthentication=no 10.x.x.x

Ele adiciona a chave a known_hosts e não solicita a senha.

6
VenomFangs

A seguir, evite entradas duplicadas em ~/.ssh/known_hosts:

if ! grep "$(ssh-keyscan github.com 2>/dev/null)" ~/.ssh/known_hosts > /dev/null; then
    ssh-keyscan github.com >> ~/.ssh/known_hosts
fi
5
Amadu Bah

Para fazer isso corretamente, o que você realmente deseja fazer é coletar as chaves públicas do host das VMs conforme você as cria e soltá-las em um arquivo em known_hosts formato. Você pode usar o -o GlobalKnownHostsFile=..., apontando para esse arquivo, para garantir que você esteja se conectando ao Host em que acredita estar conectado. Entretanto, como você faz isso depende de como você está configurando as máquinas virtuais, mas lendo-o no sistema de arquivos virtual, se possível, ou até fazendo com que o Host imprima o conteúdo de /etc/ssh/ssh_Host_rsa_key.pub durante a configuração pode fazer o truque.

Dito isto, pode não valer a pena, dependendo do tipo de ambiente em que você está trabalhando e de quem são seus adversários esperados. Fazer um simples "armazenamento na primeira conexão" (por meio de uma varredura ou simplesmente durante a primeira conexão "real"), conforme descrito em várias outras respostas acima, pode ser consideravelmente mais fácil e ainda fornecer um pouco de segurança. No entanto, se você fizer isso, sugiro fortemente que altere o arquivo de hosts conhecidos do usuário (-o UserKnownHostsFile=...) para um arquivo específico para esta instalação de teste específica; isso evitará poluir seu arquivo de hosts conhecidos pessoais com informações de teste e facilitará a limpeza das chaves públicas agora inúteis quando você excluir suas VMs.

5
cjs

Como você está construindo essas máquinas? você pode executar um script de atualização de DNS? você pode participar de um domínio IPA?

O FreeIPA faz isso automaticamente, mas basicamente tudo o que você precisa é SSHFP registros DNS e DNSSEC na sua zona (o freeipa fornece como opções configuráveis ​​(dnssec desativado por padrão)).

Você pode obter os registros SSHFP existentes do seu host executando.

ssh-keygen -r jersey.jacobdevans.com

jersey.jacobdevans.com EM SSHFP 1 1 4d8589de6b1a48e148d8fc9fbb967f1b29f53ebc jersey.jacobdevans.com EM SSHFP 1 2 6503272a11ba6d7fec2518c02dfed88f3d455ac7786ee5dbd72df63307209d55 jersey.jacobdevans.com EM SSHFP 3 1 5a7a1e8ab8f25b86b63c377b303659289b895736> jersey.jacobdevans.com EM SSHFP 3 2 1f50f790117dfedd329dbcf622a7d47551e12ff5913902c66a7da28e47de4f4b

depois de publicado, você adicionaria VerifyHostKeyDNS yes para o seu ssh_config ou ~/.ssh/config

Se/quando o google decidir ativar o DNSSEC, você poderá fazer o ssh sem o prompt da tecla host.

ssh jersey.jacobdevans.com

MAS meu domínio ainda não está assinado, então por enquanto você veria ....

debug1: Chave do host do servidor: ecdsa-sha2-nistp256 SHA256: H1D3kBF9/t0ynbz2IqfUdVHhL/WROQLGan2ijkfeT0s

debug1: encontrou 4 impressões digitais inseguras no DNS

debug1: impressão digital da chave do host correspondente

encontrado no DNS A autenticidade do host 'jersey.jacobdevans.com (2605: 6400: 10: 434 :: 10)' não pode ser estabelecida. A impressão digital da chave ECDSA é SHA256: H1D3kBF9/t0ynbz2IqfUdVHhL/WROQLGan2ijkfeT0s. Impressão digital da chave do host correspondente encontrada no DNS. Tem certeza de que deseja continuar se conectando (sim/não)? não

5
Jacob Evans

Esse todo

  • verificação de chave ssh
  • ssh-copy-id
  • Aviso de chave ECSDA

os negócios continuaram me irritando, então optei por

Um script para governar todos eles

Esta é uma variante do script em https://askubuntu.com/a/949731/129227 com a resposta de Amadu Bah https://serverfault.com/a/858957/16269 em um loop.

chamada de exemplo

./schcheck somedomain site1 site2 site3

O script fará um loop nos sites de nomes e modificará o arquivo .ssh/config e .ssh/known_hosts e executará ssh-copy-id mediante solicitação - para o último recurso, deixe as chamadas de teste ssh falharem, por exemplo. pressionando, digite 3 vezes na solicitação de senha.

script sshcheck

#!/bin/bash
# WF 2017-08-25
# check ssh access to bitplan servers

#ansi colors
#http://www.csc.uvic.ca/~sae/seng265/fall04/tips/s265s047-tips/bash-using-colors.html
blue='\033[0;34m'  
red='\033[0;31m'  
green='\033[0;32m' # '\e[1;32m' is too bright for white bg.
endColor='\033[0m'

#
# a colored message 
#   params:
#     1: l_color - the color of the message
#     2: l_msg - the message to display
#
color_msg() {
  local l_color="$1"
  local l_msg="$2"
  echo -e "${l_color}$l_msg${endColor}"
}

#
# error
#
#   show an error message and exit
#
#   params:
#     1: l_msg - the message to display
error() {
  local l_msg="$1"
  # use ansi red for error
  color_msg $red "Error: $l_msg" 1>&2
  exit 1
}

#
# show the usage
#
usage() {
  echo "usage: $0 domain sites"
  exit 1 
}

#
# check known_hosts entry for server
#
checkknown() {
  local l_server="$1"
  #echo $l_server
  local l_sid="$(ssh-keyscan $l_server 2>/dev/null)" 
  #echo $l_sid
  if (! grep "$l_sid" $sknown) > /dev/null 
  then
    color_msg $blue "adding $l_server to $sknown"
    ssh-keyscan $l_server >> $sknown 2>&1
  fi
}

#
# check the given server
#
checkserver() {
  local l_server="$1"
  grep $l_server $sconfig > /dev/null
  if [ $? -eq 1 ]
  then
    color_msg $blue "adding $l_server to $sconfig"
    today=$(date "+%Y-%m-%d")
    echo "# added $today by $0"  >> $sconfig
    echo "Host $l_server" >> $sconfig
    echo "   StrictHostKeyChecking no" >> $sconfig
    echo "   userKnownHostsFile=/dev/null" >> $sconfig
    echo "" >> $sconfig
    checkknown $l_server
  else
    color_msg $green "$l_server found in $sconfig"
  fi
  ssh -q $l_server id > /dev/null
  if [ $? -eq 0 ]
  then
    color_msg $green "$l_server accessible via ssh"
  else
    color_msg $red "ssh to $l_server failed" 
    color_msg $blue "shall I ssh-copy-id credentials to $l_server?"
    read answer
    case $answer in
      y|yes) ssh-copy-id $l_server
    esac
  fi
}

#
# check all servers
#
checkservers() {
me=$(hostname -f)
for server in $(echo $* | sort)
do
  os=`uname`
  case $os in
   # Mac OS X
   Darwin*)
     pingoption=" -t1";;
    *) ;;
  esac

  pingresult=$(ping $pingoption -i0.2 -c1 $server)
  echo $pingresult | grep 100 > /dev/null
  if [ $? -eq 1 ]
  then 
    checkserver $server
    checkserver $server.$domain
  else
    color_msg $red "ping to $server failed"
  fi
done
}

#
# check configuration
#
checkconfig() {
#https://askubuntu.com/questions/87449/how-to-disable-strict-Host-key-checking-in-ssh
  if [ -f $sconfig ]
  then
    color_msg $green "$sconfig exists"
    ls -l $sconfig
  fi
}

sconfig=~/.ssh/config
sknown=~/.ssh/known_hosts

case  $# in
  0) usage ;;
  1) usage ;;
  *) 
    domain=$1 
    shift 
    color_msg $blue "checking ssh configuration for domain $domain sites $*"
    checkconfig
    checkservers $* 
    #for server in $(echo $* | sort)
    ##do
    #  checkknown $server 
    #done
    ;;
esac
4
Wolfgang Fahl

Então, eu estava procurando uma maneira mundana de ignorar a interação manual desconhecida do host de clonar um repositório git, como mostrado abaixo:

[email protected]:~$ 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 git sobre SSH e apenas coisas relacionadas ao SSH em geral ...

[email protected]:~$ 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 - verificar manualmente as impressões digitais SSH. Mas, voltando ao que estamos fazendo.

Boa. Ou estou comprometida nos vários lugares e máquinas em que verifiquei - ou a explicação mais plausível de tudo o que está acontecendo é o que está acontecendo.

Essa 'impressão digital' é apenas uma string reduzida com um algoritmo unidirecional para nossa conveniência humana, com o risco de mais de uma string ser resolvida na mesma impressão digital. Acontece, eles são chamados de colisões.

Independentemente disso, de volta à string original que podemos ver no contexto abaixo.

[email protected]:~$ 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, com antecedência, temos uma maneira de solicitar uma forma de identificação ao host original.

Nesse ponto, nós somos manualmente tão vulneráveis ​​quanto automaticamente - as seqüências correspondem, temos os dados básicos que criam a impressão digital e poderíamos solicitar esses dados básicos (evitando colisões) no futuro.

Agora, para usar essa string de uma maneira que impeça a autenticidade de um host ...

O arquivo known_hosts nesse caso não usa entradas de texto sem formatação. Você saberá entradas de hash quando as vir; elas se parecem com hashes com caracteres aleatórios em vez de xyz.com ou 123.45.67.89.

[email protected]:~$ 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ário aparece irritantemente - mas você pode se livrar dela com um redirecionamento simples através da convenção ">" ou ">>".

Como eu fiz o meu melhor para obter dados não contaminados para serem usados ​​para identificar um "Host" e confiar, adicionarei essa identificação ao meu arquivo known_hosts no meu diretório ~/.ssh. Como agora ele será identificado como um host conhecido, não receberei o prompt mencionado acima quando você era jovem.

Obrigado por ficar comigo, aqui está. Estou adicionando a chave RSA do bitbucket para que eu possa interagir com meus repositórios git lá de maneira não interativa como parte de um fluxo de trabalho de IC, mas faça o que 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ê permanece virgem por hoje. Você pode fazer o mesmo com o github seguindo instruções semelhantes no seu próprio tempo.

Vi tantas mensagens de estouro de pilha dizendo para adicionar programaticamente a chave às cegas sem nenhum tipo de verificação. Quanto mais você checa a chave de máquinas diferentes em redes diferentes, mais confiança você tem que o host é o que ele diz ser - e isso é o melhor que você pode esperar dessa camada de segurança.

ERRADO ssh -oStrictHostKeyChecking = sem 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 alguém bisbilhotando 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 de boa-fé e agora você sabe como obter essas informações para compará-las, para que possa confiar na conexão. Lembre-se de que mais comparações de diferentes computadores e redes geralmente aumentam sua capacidade de confiar na conexão.

4
BradChesney79

Verifique a impressão digital de cada novo servidor/host. Essa é a única maneira de autenticar o servidor. Sem ele, sua conexão SSH pode estar sujeita a um ataque man-in-the-middle .

Não use o valor antigo StrictHostKeyChecking=no what nunca verifica a autenticidade do servidor. Embora o significado de StrictHostKeyChecking=no será invertido mais tarde.

A segunda opção, mas menos segura, é usar StrictHostKeyChecking=accept-new, que foi introduzido na versão 7.6 (03/10/2017) do OpenSSH :

O primeiro "accept-new" aceitará automaticamente chaves até então não vistas, mas recusará conexões para chaves de host alteradas ou inválidas.

2
Dominik

Aqui está como fazer uma coleção de hosts

definir uma coleção de hosts

ssh_hosts:
  - server1.domain.com
  - server2.domain.com
  - server3.domain.com
  - server4.domain.com
  - server5.domain.com
  - server6.domain.com
  - server7.domain.com
  - server8.domain.com
  - server9.domain.com

Em seguida, defina duas tarefas para adicionar as chaves aos hosts conhecidos:

- command: "ssh-keyscan {{item}}"
   register: known_Host_keys
   with_items: "{{ssh_hosts}}"
   tags:
     - "ssh"

 - name: Add ssh keys to know hosts
   known_hosts:
     name: "{{item.item}}"
     key: "{{item.stdout}}"
     path: ~/.ssh/known_hosts
   with_items: "{{known_Host_keys.results}}"
2
Vackar Afzal

Se você deseja verificar a chave antes de adicioná-la às cegas, pode usar este código:

# verify github and gitlab key
# GitHub
github=SHA256:nThbg6kXUpJWGl7E1IGOCspRomTxdCARLviKw6E5SY8
ssh-keyscan github.com >> githubKey
read bit githubkey Host <<< $(ssh-keygen -lf githubKey)
if [ "$githubkey" != "$github" ]
then
  echo "The GitHub fingerprint is incorrect"
  exit 1
fi
echo "github.com ssh-rsa AAAAB3NzaC1yc2EAAAABIwAAAQEAq2A7hRGmdnm9tUDbO9IDSwBK6TbQa+PXYPCPy6rbTrTtw7PHkccKrpp0yVhp5HdEIcKr6pLlVDBfOLX9QUsyCOV0wzfjIJNlGEYsdlLJizHhbn2mUjvSAHQqZETYP81eFzLQNnPHt4EVVUh7VfDESU84KezmD5QlWpXLmvU31/yMf+Se8xhHTvKSCZIFImWwoG6mbUoWf9nzpIoaSjB+weqqUUmpaaasXVal72J+UX2B+2RPW3RcT0eOzQgqlJL3RKrTJvdsjE3JEAvGq3lGHSZXy28G3skua2SmVi/w4yCE6gbODqnTWlg7+wC604ydGXA8VJiS5ap43JXiUFFAaQ==" | Sudo tee -a /etc/ssh/ssh_known_hosts

# GitLab
gitlab=SHA256:ROQFvPThGrW4RuWLoL9tq9I9zJ42fK4XywyRtbOz/EQ
ssh-keyscan gitlab.com >> gitlabKey
read bit gitlabkey Host <<< $(ssh-keygen -lf gitlabKey)
if [ "$githubkey" != "$github" ]
then
  echo "The GitLab fingerprint is incorrect"
  exit 1
fi
echo "gitlab.com ssh-rsa AAAAB3NzaC1yc2EAAAADAQABAAABAQCsj2bNKTBSpIYDEGk9KxsGh3mySTRgMtXL583qmBpzeQ+jqCMRgBqB98u3z++J1sKlXHWfM9dyhSevkMwSbhoR8XIq/U0tCNyokEi/ueaBMCvbcTHhO7FcwzY92WK4Yt0aGROY5qX2UKSeOvuP4D6TPqKF1onrSzH9bx9XUf2lEdWT/ia1NEKjunUqu1xOB/StKDHMoX4/OKyIzuS0q/T1zOATthvasJFoPrAjkohTyaDUz2LN5JoH839hViyEG82yB+MjcFV5MU3N1l1QL3cVUCh93xSaua1N85qivl+siMkPGbO5xR/En4iEY6K2XPASUEMaieWVNTRCtJ4S8H+9" | Sudo tee -a /etc/ssh/ssh_known_hosts

As chaves GitHub e GitLab podem mudar se forem comprometidas. Nesse caso, verifique os mais recentes aqui e

Observação : pode ser necessário garantir que a chave não seja adicionada duas vezes. Para isso, consulte outras respostas.

1
Sharcoux

Eu havia enfrentado um problema semelhante no qual, apesar de usar a solução verificada acima mencionada, meu ssh não estava funcionando e era porque o arquivo known_hosts estava ausente no diretório ~/.ssh/e o sistema de arquivos era somente leitura. SO durante o tempo de execução também não consegui criar o arquivo ~/.ssh/known_hosts.

Se você enfrentar um problema semelhante, verifique se é possível gravar o arquivo known_hosts no local/tmp. Isso é ativado principalmente para gravação, mesmo em um sistema de arquivos somente leitura.

Posteriormente no comando ssh, você pode especificar o ssh para ler o arquivo known_hosts no local/tmp.

ssh -o UserKnownHostsFile =/tmp/known_hosts -o StrictHostKeyChecking = nenhum nome de usuário @ destination_server_ip

0
Rohit Agrawal