Могу ли я автоматически добавлять новый хост в known_hosts?

ИМО, лучший способ сделать это:

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-адреса, а также будет хешировать вывод, что является дополнительной мерой безопасности.

Установить StrictHostKeyChecking возможность no, либо в файле конфигурации, либо через -o :

ssh -o StrictHostKeyChecking=no username@hostname.com

Для ленивых:

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

-H хеширует имя хоста / IP-адрес

Как уже упоминалось, сканирование клавиш было бы правильным и ненавязчивым способом сделать это.

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

Вышеупомянутый трюк поможет добавить хост, ТОЛЬКО если он еще не был добавлен. Это также небезопасно для параллелизма; ты не должен выполнить фрагмент на одной и той же исходной машине более одного раза одновременно, так как файл tmp_hosts может засориться, что в конечном итоге приведет к раздуванию файла known_hosts ...

Вы могли бы использовать ssh-keyscan команда, чтобы получить открытый ключ и добавить его в свой known_hosts файл.

Вот как вы можете включить 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 }}'

это было бы полное решение, принимающее ключ хоста только в первый раз

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

Я делаю однострочный сценарий, немного длинный, но полезный для выполнения этой задачи для хостов с несколькими IP-адресами, используя dig и 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

У меня была аналогичная проблема, и я обнаружил, что некоторые из предоставленных ответов привели меня лишь частично к автоматизированному решению. Вот что я в итоге использовал, надеюсь, это поможет:

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

Он добавляет ключ к known_hosts и не запрашивает пароль.

Как вы строите эти машины? можно запустить скрипт обновления DNS? вы можете присоединиться к домену IPA?

FreeIPA делает это автоматически, но все, что вам нужно, это SSHFP записи DNS и DNSSEC в вашей зоне (freeipa предоставляет настраиваемые параметры (по умолчанию dnssec отключен)).

Вы можете получить существующие записи SSHFP со своего хоста, запустив.

ssh-keygen -r jersey.jacobdevans.com

jersey.jacobdevans.com В SSHFP-1 4d8589de6b1a48e148d8fc9fbb967f1b29f53ebc jersey.jacobdevans.com В SSHFP-2 6503272a11ba6d7fec2518c02dfed88f3d455ac7786ee5dbd72df63307209d55 jersey.jacobdevans.com В SSHFP-1 5a7a1e8ab8f25b86b63c377b303659289b895736> jersey.jacobdevans.com В SSHFP-2 1f50f790117dfedd329dbcf622a7d47551e12ff5913902c66a7da28e47de4f4b

затем после публикации вы должны добавить VerifyHostKeyDNS yes в ваш ssh_config или ~ / .ssh / config

Если / когда Google решит включить DNSSEC, вы сможете использовать ssh без приглашения hostkey.

ssh jersey.jacobdevans.com

НО мой домен еще не подписан, так что пока вы увидите ....

debug1: ключ хоста сервера: ecdsa-sha2-nistp256 SHA256: H1D3kBF9 / t0ynbz2IqfUdVHhL / WROQLGan2ijkfeT0s

debug1: обнаружено 4 небезопасных отпечатка в DNS

debug1: соответствующий отпечаток ключа хоста

найдено в DNS. Подлинность хоста jersey.jacobdevans.com (2605: 6400: 10: 434 :: 10) не может быть установлена. Отпечаток ключа ECDSA - SHA256: H1D3kBF9 / t0ynbz2IqfUdVHhL / WROQLGan2ijkfeT0s. Соответствующий отпечаток ключа хоста обнаружен в DNS. Вы уверены, что хотите продолжить подключение (да / нет)? нет

Следующее позволяет избежать дублирования записей в ~ / .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

Чтобы сделать это правильно, вы действительно хотите собрать открытые ключи хоста виртуальных машин по мере их создания и поместить их в файл в known_hosts формат. Затем вы можете использовать -o GlobalKnownHostsFile=..., указывая на этот файл, чтобы убедиться, что вы подключаетесь к хосту, к которому, по вашему мнению, следует подключаться. Однако то, как вы это делаете, зависит от того, как вы настраиваете виртуальные машины, но считывая это из виртуальной файловой системы, если возможно, или даже заставляя хост распечатать содержимое /etc/ssh/ssh_host_rsa_key.pub во время настройки может сделать свое дело.

Тем не менее, это может не иметь смысла, в зависимости от того, в какой среде вы работаете и кто ваши ожидаемые противники. Выполнение простого «сохранения при первом подключении» (через сканирование или просто во время первого «реального» соединения), как описано в нескольких других ответах выше, может быть значительно проще и все же обеспечить некоторую минимальную безопасность. Однако, если вы это сделаете, я настоятельно рекомендую вам изменить файл известных пользователю хостов (-o UserKnownHostsFile=...) в файл, специфичный для данной тестовой установки; это позволит избежать загрязнения вашего личного файла известных хостов тестовой информацией и упростит очистку теперь бесполезных открытых ключей при удалении виртуальных машин.

Все это

• ssh-key-scan
• ssh-copy-id
• Предупреждение о ключе ECSDA

бизнес продолжал меня раздражать, поэтому я выбрал

Один сценарий, чтобы управлять ими всеми

Это вариант сценария по адресу https://askubuntu.com/a/949731/129227 с ответом Амаду Баха https://serverfault.com/a/858957/162693 в петле.

пример вызова

./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

Итак, я искал обыденный способ обойти неизвестное ручное взаимодействие хоста с клонированием репозитория git, как показано ниже:

brad@computer:~$ git clone git@bitbucket.org: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, это будет работать для git через SSH и просто для вещей, связанных с 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==

Появляется первая строка комментария, вызывающая раздражение, но вы можете избавиться от нее с помощью простого перенаправления, используя соглашение ">" или ">>".

Поскольку я сделал все возможное, чтобы получить незапятнанные данные, которые будут использоваться для идентификации "хоста" и доверия, я добавлю эту идентификацию в свой файл known_hosts в моем каталоге ~ / .ssh. Поскольку теперь он будет идентифицирован как известный хозяин, я не получу упомянутого выше запроса, когда вы были молодым человеком.

Спасибо, что оставались со мной, готово. Я добавляю RSA-ключ bitbucket, чтобы я мог взаимодействовать с моими репозиториями git в неинтерактивном режиме как часть рабочего процесса CI, но все, что вы делаете, что хотите.

#!/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 = без имени хоста [команда]

НЕПРАВИЛЬНО ssh-keyscan -t rsa -H имя хоста >> ~ / .ssh / known_hosts

Пожалуйста, не делайте ничего из вышеперечисленного. Вам предоставляется возможность повысить свои шансы избежать подслушивания ваших передач данных через человека, находящегося в центре атаки - воспользуйтесь этой возможностью. Разница заключается в том, чтобы буквально подтвердить, что ключ RSA, который у вас есть, является ключом добросовестного сервера, и теперь вы знаете, как получить эту информацию, чтобы сравнить их, чтобы вы могли доверять соединению. Просто помните, что больше сравнений с разных компьютеров и сетей обычно повышают вашу способность доверять соединению.

Проверьте отпечаток пальца каждого нового сервера / хоста. Это единственный способ аутентифицировать сервер. Без него ваше SSH-соединение может быть подвергнуто атака "человек посередине".

Не использовать старое значение StrictHostKeyChecking=no который никогда проверяет подлинность сервера вообще. Хотя значение StrictHostKeyChecking=no будет перевернут потом.

Второй вариант, но менее безопасный - использовать StrictHostKeyChecking=accept-new, который был представлен в версии 7.6 (2017-10-03) OpenSSH:

Первый «accept-new» автоматически примет ранее невидимые ключи, но откажется от соединений для измененных или недействительных ключей хоста.

Вот как сделать сбор хостов

определить набор хостов

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

Затем определите две задачи для добавления ключей к известным хостам:

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

Если вы хотите проверить ключ перед добавлением вслепую, вы можете использовать этот код:

# 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 могут измениться в случае их взлома. В этом случае проверьте самые свежие Вот и там

Замечание: Возможно, вам потребуется убедиться, что ключ не добавляется дважды. Для этого обратитесь к другим ответам.

Я столкнулся с аналогичной проблемой, когда, несмотря на использование вышеупомянутого проверенного решения, мой ssh ​​не работал, потому что файл known_hosts отсутствовал в каталоге ~ / .ssh /, а файловая система была доступна только для чтения. ТАК, во время выполнения я также не смог создать файл ~ / .ssh / known_hosts.

Если вы столкнулись с подобной проблемой, посмотрите, можете ли вы записать файл known_hosts в папку / tmp. В большинстве случаев запись разрешена даже в файловой системе, доступной только для чтения.

Позже в команде ssh вы можете указать ssh для чтения файла known_hosts из / tmp.

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