Puis-je ajouter automatiquement un nouvel hôte aux hôtes connus?
Voici ma situation: je suis en train de configurer un faisceau de test qui, à partir d'un client central, lancera un certain nombre d'instances de machine virtuelle, puis exécutera des commandes sur celles-ci via ssh. Les machines virtuelles auront des noms d'hôte et des adresses IP précédemment inutilisés, elles ne seront donc pas dans le ~/.ssh/known_hosts fichier sur le client central.
Le problème que j'ai est que la première commande ssh exécutée sur une nouvelle instance virtuelle arrive toujours avec une invite interactive:
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-t-il un moyen de contourner cela et de faire en sorte que le nouvel hôte soit déjà connu de la machine cliente, peut-être en utilisant une clé publique déjà intégrée dans l'image de la machine virtuelle? J'aimerais vraiment éviter d'avoir à utiliser Expect ou quoi que ce soit pour répondre à l'invite interactive si je le peux.
Définissez l'option StrictHostKeyChecking sur no, soit dans le fichier de configuration, soit via -o:
ssh -o StrictHostKeyChecking=no [email protected]
OMI, la meilleure façon de procéder est la suivante:
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
Cela garantira qu'il n'y a pas d'entrées en double, que vous êtes couvert à la fois pour le nom d'hôte et l'adresse IP, et hachera également la sortie, une mesure de sécurité supplémentaire.
Pour les paresseux:
ssh-keyscan -H <Host> >> ~/.ssh/known_hosts
-H hache le nom d'hôte/l'adresse IP
Comme mentionné, l'utilisation de la numérisation par clé serait la bonne façon et discrète de le faire.
ssh-keyscan -t rsa,dsa Host 2>&1 | sort -u - ~/.ssh/known_hosts > ~/.ssh/tmp_hosts
mv ~/.ssh/tmp_hosts ~/.ssh/known_hosts
Ce qui précède fera l'affaire pour ajouter un hôte, UNIQUEMENT s'il n'a pas encore été ajouté. Il n'est pas non plus sûr de la concurrence; vous ne devez pas exécuter l'extrait de code sur la même machine d'origine plus d'une fois en même temps, car le fichier tmp_hosts peut être bouché, ce qui finit par faire gonfler le fichier known_hosts ...
Vous pouvez utiliser ssh-keyscan commande pour saisir la clé publique et l'ajouter à votre known_hosts fichier.
Voici comment vous pouvez intégrer ssh-keyscan dans votre jeu:
---
# 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 }}'
Je fais un script à une ligne, un peu long mais utile pour faire cette tâche pour les hôtes avec plusieurs IP, en utilisant Dig et 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
ce serait une solution complète, n'acceptant la clé d'hôte que pour la première fois
#!/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([]) }}'
J'ai eu un problème similaire et j'ai constaté que certaines des réponses fournies ne m'avaient permis qu'à mi-chemin d'une solution automatisée. Voici ce que j'ai fini par utiliser, j'espère que cela aide:
ssh -o "StrictHostKeyChecking no" -o PasswordAuthentication=no 10.x.x.x
Il ajoute la clé à known_hosts et ne demande pas le mot de passe.
Les éléments suivants évitent les entrées en double dans ~/.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
Pour faire cela correctement, ce que vous voulez vraiment faire, c'est collecter les clés publiques de l'hôte des machines virtuelles lorsque vous les créez et les déposer dans un fichier dans known_hosts format. Vous pouvez ensuite utiliser le -o GlobalKnownHostsFile=..., pointant vers ce fichier, pour vous assurer que vous vous connectez à l'hôte auquel vous pensez que vous devriez vous connecter. La façon dont vous procédez dépend toutefois de la façon dont vous configurez les machines virtuelles, mais si vous le lisez sur le système de fichiers virtuel, si possible, ou même que l'hôte imprime le contenu de /etc/ssh/ssh_Host_rsa_key.pub pendant la configuration peut faire l'affaire.
Cela dit, cela peut ne pas valoir la peine, selon le type d'environnement dans lequel vous travaillez et qui sont vos adversaires prévus. Faire un simple "stockage lors de la première connexion" (via une analyse ou simplement lors de la première "vraie" connexion) comme décrit dans plusieurs autres réponses ci-dessus peut être considérablement plus facile et fournir encore un minimum de sécurité. Cependant, si vous faites cela, je vous suggère fortement de modifier le fichier des hôtes connus de l'utilisateur (-o UserKnownHostsFile=...) vers un fichier spécifique à cette installation de test particulière; cela évitera de polluer votre fichier d'hôtes connu personnel avec des informations de test et facilitera le nettoyage des clés publiques désormais inutiles lorsque vous supprimez vos machines virtuelles.
Comment construisez-vous ces machines? pouvez-vous exécuter un script de mise à jour DNS? pouvez-vous rejoindre un domaine IPA?
FreeIPA le fait automatiquement, mais essentiellement tout ce dont vous avez besoin est SSHFP enregistrements DNS et DNSSEC sur votre zone (freeipa fournit des options configurables (dnssec désactivé par défaut)).
Vous pouvez obtenir les enregistrements SSHFP existants de votre hôte en exécutant.
ssh-keygen -r jersey.jacobdevans.com
jersey.jacobdevans.com IN SSHFP 1 1 4d8589de6b1a48e148d8fc9fbb967f1b29f53ebc jersey.jacobdevans.com IN SSHFP 1 2 6503272a11ba6d7fec2518c02dfed88f3d455ac7786ee5dbd72df63307209d55 jersey.jacobdevans.com IN SSHFP 3 1 5a7a1e8ab8f25b86b63c377b303659289b895736> jersey.jacobdevans.com IN SSHFP 3 2 1f50f790117dfedd329dbcf622a7d47551e12ff5913902c66a7da28e47de4f4b
puis une fois publié, vous ajouteriez VerifyHostKeyDNS yes à votre ssh_config ou ~/.ssh/config
Si/Quand google décide de basculer sur DNSSEC, vous pouvez vous connecter sans invite de clé d'hôte.
ssh jersey.jacobdevans.com
MAIS mon domaine n'est pas encore signé, donc pour l'instant vous verriez ....
debug1: clé d'hôte du serveur: ecdsa-sha2-nistp256 SHA256: H1D3kBF9/t0ynbz2IqfUdVHhL/WROQLGan2ijkfeT0s
debug1: a trouvé 4 empreintes digitales non sécurisées dans DNS
debug1: correspondance de l'empreinte digitale de la clé hôte
trouvé dans DNS L'authenticité de l'hôte 'jersey.jacobdevans.com (2605: 6400: 10: 434 :: 10)' ne peut pas être établie. L'empreinte digitale de la clé ECDSA est SHA256: H1D3kBF9/t0ynbz2IqfUdVHhL/WROQLGan2ijkfeT0s. Empreinte digitale de la clé hôte correspondante trouvée dans DNS. Voulez-vous vraiment continuer à vous connecter (oui/non)? non
Ce tout
- ssh-key-scan
- ssh-copy-id
- Avertissement clé ECSDA
les affaires me gênaient donc j'ai opté pour
Un script pour les gouverner tous
Ceci est une variante du script à https://askubuntu.com/a/949731/129227 avec la réponse d'Amadu Bah https://serverfault.com/a/858957/16269 dans une boucle.
exemple d'appel
./sshcheck somedomain site1 site2 site3
Le script bouclera sur les sites de noms et modifiera les fichiers .ssh/config et .ssh/known_hosts et fera ssh-copy-id sur demande - pour la dernière fonctionnalité, laissez les appels de test ssh échouer, par exemple en appuyant sur entrer 3 fois sur la demande de mot de passe.
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
Donc, je cherchais un moyen banal de contourner l'interaction manuelle inconnue de l'hôte de clonage d'un dépôt git comme indiqué ci-dessous:
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)?
Notez l'empreinte digitale de la clé RSA ...
Donc, c'est une chose SSH, cela fonctionnera pour git sur SSH et seulement les choses liées à SSH en général ...
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
Tout d'abord, installez nmap sur votre pilote quotidien. nmap est très utile pour certaines choses, comme la détection de ports ouverts et cela - la vérification manuelle des empreintes digitales SSH. Mais revenons à ce que nous faisons.
Bien. Soit je suis compromis aux multiples endroits et machines que j'ai vérifiés - soit l'explication la plus plausible de tout ce qui est un dory hunky est ce qui se passe.
Cette "empreinte digitale" n'est qu'une chaîne raccourcie avec un algorithme unidirectionnel pour notre commodité humaine, au risque que plus d'une chaîne se résout en la même empreinte digitale. Ça arrive, on les appelle des collisions.
Quoi qu'il en soit, revenons à la chaîne d'origine que nous pouvons voir dans le contexte ci-dessous.
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
Donc, à l'avance, nous avons un moyen de demander une forme d'identification à l'hôte d'origine.
À ce stade, nous sommes manuellement aussi vulnérables qu'automatiquement - les chaînes correspondent, nous avons les données de base qui créent l'empreinte digitale, et nous pourrions demander ces données de base (prévenir les collisions) à l'avenir.
Maintenant, pour utiliser cette chaîne d'une manière qui empêche de poser des questions sur l'authenticité des hôtes ...
Dans ce cas, le fichier known_hosts n'utilise pas d'entrées en texte brut. Vous saurez les entrées hachées lorsque vous les voyez, elles ressemblent à des hachages avec des caractères aléatoires au lieu 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==
La première ligne de commentaires apparaît de manière exaspérante - mais vous pouvez vous en débarrasser avec une simple redirection via la convention ">" ou ">>".
Comme j'ai fait de mon mieux pour obtenir des données intactes à utiliser pour identifier un "hôte" et faire confiance, je vais ajouter cette identification à mon fichier known_hosts dans mon répertoire ~/.ssh. Puisqu'il sera désormais identifié comme un hôte connu, je ne recevrai pas l'invite mentionnée ci-dessus lorsque vous étiez un jeune.
Merci d'être resté avec moi, c'est parti. J'ajoute la clé bitbucket RSA afin de pouvoir interagir avec mes référentiels git de manière non interactive dans le cadre d'un flux de travail CI, mais quoi que vous fassiez ce que vous voulez.
#!/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
C'est ainsi que vous restez vierge pour aujourd'hui. Vous pouvez faire de même avec github en suivant des instructions similaires à votre rythme.
J'ai vu tellement de messages de débordement de pile vous disant d'ajouter par programmation la clé en aveugle sans aucune vérification. Plus vous vérifiez la clé de différentes machines sur différents réseaux, plus vous pouvez avoir confiance que l'hôte est celui qu'il dit être - et c'est le mieux que vous puissiez espérer de cette couche de sécurité.
FAUX ssh -oStrictHostKeyChecking = pas de nom d'hôte [commande]
FAUX ssh-keyscan -t rsa -H hostname >> ~/.ssh/known_hosts
Ne faites aucune des choses ci-dessus, s'il vous plaît. Vous avez la possibilité d'augmenter vos chances d'éviter que quelqu'un n'écoute vos transferts de données via un homme au milieu de l'attaque - profitez-en. La différence est de vérifier littéralement que la clé RSA que vous avez est celle du serveur de bonne foi et maintenant vous savez comment obtenir ces informations pour les comparer afin que vous puissiez faire confiance à la connexion. N'oubliez pas que plus de comparaisons de différents ordinateurs et réseaux augmenteront généralement votre capacité à faire confiance à la connexion.
Vérifiez l'empreinte digitale de chaque nouveau serveur/hôte. C'est le seul moyen d'authentifier le serveur. Sans cela, votre connexion SSH peut être soumise à une attaque man-in-the-middle .
N'utilisez pas l'ancienne valeur StrictHostKeyChecking=no qui jamais vérifie l'authenticité du serveur. Bien que le sens de StrictHostKeyChecking=no sera retourné plus tard.
La deuxième option, mais moins sécurisée, consiste à utiliser StrictHostKeyChecking=accept-new, qui était introduit dans la version 7.6 (2017-10-03) d'OpenSSH :
Le premier "accept-new" acceptera automatiquement les clés jusque-là invisibles mais refusera les connexions pour les clés hôtes modifiées ou invalides.
Voici comment faire une collection d'hôtes
définir une collection d'hôtes
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
Définissez ensuite deux tâches pour ajouter les clés aux hôtes connus:
- 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}}"
Si vous souhaitez vérifier la clé avant de l'ajouter à l'aveugle, vous pouvez utiliser ce code:
# 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
Les clés GitHub et GitLab peuvent changer si elles sont compromises. Dans ce cas, vérifiez les plus récents ici et là
Remarque : Vous devrez peut-être vous assurer que la clé n'est pas ajoutée deux fois. Pour cela, reportez-vous à d'autres réponses.
J'avais rencontré un problème similaire où malgré l'utilisation de la solution vérifiée mentionnée ci-dessus, mon ssh ne fonctionnait pas et c'était parce que le fichier known_hosts manquait dans le répertoire ~/.ssh/et que le système de fichiers était en lecture seule. SO pendant l'exécution également, je n'ai pas pu créer le fichier ~/.ssh/known_hosts.
Si vous rencontrez le même problème, voyez si vous pouvez écrire le fichier known_hosts à l'emplacement/tmp. Ceci est principalement activé en écriture, même dans un système de fichiers en lecture seule.
Plus loin dans la commande ssh, vous pouvez spécifier le ssh pour lire le fichier known_hosts à partir de l'emplacement/tmp.
ssh -o UserKnownHostsFile =/tmp/known_hosts -o StrictHostKeyChecking = no user_name @ destination_server_ip