新しいホストをknown_hostsに自動的に追加できますか？

Question

これが私の状況です。中央のクライアントからいくつかの仮想マシンインスタンスを起動し、sshを介してそれらのコマンドを実行するテストハーネスをセットアップしています。仮想マシンには以前に使用されていないホスト名とIPアドレスがあるため、中央クライアントの~/.ssh/known_hostsファイルには含まれません。

私が抱えている問題は、新しい仮想インスタンスに対して実行された最初のsshコマンドが常に対話型のプロンプトを表示することです。

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)?

これをバイパスして、クライアントマシンが新しいホストを認識できるようにする方法はありますか。おそらく、仮想マシンイメージにすでにベイクされている公開鍵を使用しますか？可能であれば、対話型プロンプトに応答するためにExpectなどを使用する必要がないようにしたいのですが。

Answer 1

StrictHostKeyCheckingオプションをnoに設定ファイルまたは-oで設定します。

ssh -o StrictHostKeyChecking=no [email protected]

Answer 2

IMO、これを行う最善の方法は次のとおりです。

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

これにより、重複するエントリがないこと、ホスト名とIPアドレスの両方がカバーされていること、および追加のセキュリティ対策である出力をハッシュすることが保証されます。

Answer 3

怠惰な人のために：

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

-Hはホスト名/ IPアドレスをハッシュします

Answer 4

前述のように、キースキャンを使用することは、それを行うための適切で目立たない方法です。

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

上記は、まだ追加されていない場合にのみ、ホストを追加するトリックを実行します。また、同時実行も安全ではありません。あなた必須ではない同一のOriginマシンで同時に複数回スニペットを実行します。tmp_hostsファイルが破損し、最終的にknown_hostsファイルが肥大化する可能性があるためです...

Answer 5

ssh-keyscanコマンドを使用して公開鍵を取得し、known_hostsファイルに追加できます。

Answer 6

これがssh-keyscanをプレイに組み込む方法です：

---
# 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 }}'

Answer 7

Digとbashを使用して、複数のIPを持つホストでこのタスクを実行するには少し長いですが、便利なワンライナースクリプトを実行します

(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

Answer 8

これは完全な解決策であり、初めてホストキーを受け入れるだけです

#!/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([]) }}'

Answer 9

私は同様の問題を抱えていて、提供された回答の一部が自動化されたソリューションへの道を進んでいるだけであることがわかりました。以下は私が最終的に使用したものです、それが役に立てば幸いです：

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

known_hostsにキーを追加し、パスワードの入力を求めません。

Answer 10

以下は〜/ .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

Answer 11

これを適切に行うには、VMの作成時にホストの公開鍵を収集し、それらをknown_hosts形式のファイルにドロップすることで、実際に実行する必要があります。次に、そのファイルを指す-o GlobalKnownHostsFile=...を使用して、接続する必要があると思われるホストに接続していることを確認できます。これを行う方法は、仮想マシンの設定方法によって異なりますが、可能であれば、仮想ファイルシステムから読み取るか、構成中にホストに/etc/ssh/ssh_Host_rsa_key.pubの内容を印刷させることでうまくいく場合があります。 。

そうは言っても、あなたが働いている環境の種類や、予想される敵が誰であるかによっては、これは価値がないかもしれません。上記のいくつかの他の回答で説明されているように、単純な「最初の接続で保存」を（スキャンを介して、または単に最初の「実際の」接続中に）行うと、かなり簡単になり、多少のセキュリティが提供されます。ただし、これを行う場合は、ユーザーの既知のホストファイル（-o UserKnownHostsFile=...）を、この特定のテストインストールに固有のファイルに変更することを強くお勧めします。これにより、個人の既知のhostsファイルがテスト情報で汚染されるのを防ぎ、VMを削除するときに不要になった公開鍵を簡単にクリーンアップできます。

Answer 12

これらの機械をどのように構築していますか？ DNS更新スクリプトを実行できますか？ IPAドメインに参加できますか？

FreeIPAはこれを自動的に行いますが、基本的に必要なのは [〜＃〜] sshfp [〜＃〜] dns recordsと [〜＃〜] dnssec [〜＃〜] だけです。ゾーンで（freeipaは構成可能なオプションとして提供されます（dnssecはデフォルトで無効になっています））。

を実行すると、ホストから既存のSSHFPレコードを取得できます。

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 SSHFP IN 3 2 1f50f790117dfedd329dbcf622a7d47551e12ff5913902c66a7da28e47de4f4b

公開したら、VerifyHostKeyDNS yesをssh_configまたは〜/ .ssh/configに追加します

GoogleがDNSSECをオンにすることを決定した場合、ホストキープロンプトなしでsshでログインできます。

ssh jersey.jacobdevans.com

しかし、私のドメインはまだ署名されていないので、今のところ表示されます...

debug1：サーバーホストキー：ecdsa-sha2-nistp256 SHA256：H1D3kBF9/t0ynbz2IqfUdVHhL/WROQLGan2ijkfeT0s

debug1：DNSで4つの安全でないフィンガープリントが見つかりました

debug1：一致するホストキーフィンガープリント

dNSで見つかりましたホスト 'jersey.jacobdevans.com（2605：6400：10：434 :: 10）'の信頼性を確立できません。 ECDSAキーフィンガープリントはSHA256：H1D3kBF9/t0ynbz2IqfUdVHhL/WROQLGan2ijkfeT0sです。 DNSで見つかった一致するホストキーのフィンガープリント。接続を続行してもよろしいですか（はい/いいえ）？番号

Answer 13

この全体

• ssh-key-scan
• ssh-copy-id
• ECSDAキー警告

ビジネスは私を悩ませ続けたので私は選びました

それらすべてを支配する1つのスクリプト

これは https://askubuntu.com/a/949731/129227 のスクリプトの変形で、Amadu Bahの回答 https://serverfault.com/a/858957/16269 ループ中。

呼び出し例

./sshcheck somedomain site1 site2 site3

スクリプトは名前サイトをループし、.ssh/configファイルと.ssh/known_hostsファイルを変更し、リクエストに応じてssh-copy-idを実行します。最後の機能では、sshテストコールを失敗させます。パスワードリクエストでEnterキーを3回押す。

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

Answer 14

そのため、以下に示すように、gitリポジトリのクローンを作成するという未知のホストの手動操作をバイパスする平凡な方法を探していました。

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)?

RSAキーのフィンガープリントに注意してください...

したがって、これはSSHのものであり、SSHを介したgitで機能し、SSH関連のものだけで一般的に機能します...

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

まず、日常のドライバーにnmapをインストールします。 nmapは、開いているポートの検出や、SSHフィンガープリントの手動検証など、特定の状況で非常に役立ちます。しかし、私たちがやっていることに戻ります。

良い。私はそれをチェックした複数の場所とマシンで妥協しているか、またはすべてがおかしいドーリーであるというよりもっともらしい説明は何が起こっているのかです。

その「指紋」は、複数の文字列が同じ指紋に解決されるリスクがあるという、人間の便宜のために一方向アルゴリズムで短縮された文字列です。起こります、それらは衝突と呼ばれます。

とにかく、以下のコンテキストで確認できる元の文字列に戻ります。

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

したがって、事前に、元のホストからの識別形式を要求する方法があります。

この時点では、手動と自動の両方で脆弱性があります。文字列は一致し、フィンガープリントを作成するベースデータがあり、将来、そのベースデータ（衝突を防止する）を要求できます。

次に、ホストの信頼性について尋ねないようにその文字列を使用します...

この場合、known_hostsファイルはプレーンテキストエントリを使用しません。ハッシュ化されたエントリは、xyz.comまたは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==

最初のコメント行は腹立たしいように表示されますが、 ">"または ">>"規則を使用して単純なリダイレクトを行うことで、コメント行を取り除くことができます。

「ホスト」と信頼を識別するために使用する汚染されていないデータを取得するために最善を尽くしたので、この識別を〜/ .sshディレクトリのknown_hostsファイルに追加します。これは既知のホストとして識別されるため、若者の場合は上記のプロンプトは表示されません。

私に固執してくれてありがとう、ここに行きます。 CIワークフローの一部として非インタラクティブな方法でgitリポジトリとやり取りできるように、bitbucket RSAキーを追加しますが、やりたいことは何でもできます。

#!/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

だから、今日は処女のままです。自分の時間に同様の指示に従うことで、githubでも同じことができます。

スタックオーバーフローの投稿がたくさんあるので、プログラムを使わずにキーを盲目的に追加するように言われました。さまざまなネットワーク上のさまざまなマシンからのキーをチェックすればするほど、ホストがそのホストであるという信頼が高まります。これが、このセキュリティ層から期待できる最高のものです。

違う ssh -oStrictHostKeyChecking = no hostname [コマンド]

違う ssh-keyscan -t rsa -Hホスト名>>〜/ .ssh/known_hosts

上記のいずれも行わないでください。中間者攻撃によるデータ転送の盗聴を回避する機会を増やす機会が与えられます。その機会を利用してください。違いは、お持ちのRSAキーが正規のサーバーの1つであることを文字通り確認することであり、接続を信頼できるようにそれらを比較するためにその情報を取得する方法がわかりました。異なるコンピュータやネットワークからの比較を増やすと、通常、接続を信頼する能力が高まります。

Answer 15

各新しいサーバー/ホストのフィンガープリントを確認します。これがサーバーを認証する唯一の方法です。これがなければ、SSH接続は man-in-the-middle攻撃 の影響を受ける可能性があります。

しないでください古い値StrictHostKeyChecking=noを使用しますneverでサーバーの信頼性をチェックしますすべて。 StrictHostKeyChecking=noの意味は反転されます の後で。

2番目のオプションですが、安全性は低くなりますが、StrictHostKeyChecking=accept-newを使用することです-これは OpenSSHのバージョン7.6（2017-10-03）で導入されました ：

最初の「accept-new」は、これまでにないキーを自動的に受け入れますが、変更された、または無効なホストキーの接続を拒否します。

Answer 16

ホストの収集を行う方法は次のとおりです

ホストのコレクションを定義する

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

次に、既知のホストにキーを追加する2つのタスクを定義します。

- 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}}"

Answer 17

盲目的に追加する前にキーをチェックしたい場合は、次のコードを使用できます。

# 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

GitHubおよびGitLabキーは、侵害された場合に変更される可能性があります。この場合、最新のもの here および there を確認してください

備考：キーが2回追加されないようにする必要がある場合があります。これについては、他の回答を参照してください。

Answer 18

上記の検証済みソリューションを使用しているにもかかわらずsshが機能せず、known_hostsファイルが〜/ .ssh /ディレクトリになく、ファイルシステムが読み取り専用であったため、同様の問題に直面していました。 SO実行時にも、〜/ .ssh/known_hostsファイルを作成できませんでした。

同様の問題が発生した場合は、known_hostsファイルを/ tmpの場所に書き込むことができるかどうかを確認してください。これは、読み取り専用のファイルシステムでも、ほとんどの場合書き込み可能です。

後でsshコマンドで、/ tmpの場所からknown_hostsファイルを読み取るようにsshを指定できます。

ssh -o UserKnownHostsFile =/tmp/known_hosts -o StrictHostKeyChecking = no user_name @ destination_server_ip