Проверка ключа хоста SSH не может быть отключена при использовании прокси-перехода

Я пытаюсь подключиться через SSH через Jumpbox, но SSH, похоже, намеревается проверить ключи хоста для Jumpbox, хотя я говорю это не с помощью обычного -o StrictHostKeyChecking=no -o UserKnownHostsFile=no параметры командной строки.

Если я подключаю SSH напрямую к Jumpbox, я могу заставить SSH игнорировать ошибку, как и ожидалось:

ssh -o StrictHostKeyChecking=no -o UserKnownHostsFile=/dev/null -i ~/.ssh/id_jumpuser_rsa jumpuser@jumpbox

Однако, если я добавлю опцию перехода через прокси, я внезапно получу ошибку. Ошибка НЕ ​​исходит из Jumpbox. В любом каталоге.ssh на Jumpbox отсутствуют файлы known_hosts, и я не захожу в систему как jumpuser:

ssh -o StrictHostKeyChecking=no -o UserKnownHostsFile=/dev/null -i ~/.ssh/id_jumpuser_rsa -J jumpuser@jumpbox jumpuser@10.10.0.5

Сообщение об ошибке:

@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@
@    WARNING: REMOTE HOST IDENTIFICATION HAS CHANGED!     @
@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@
IT IS POSSIBLE THAT SOMEONE IS DOING SOMETHING NASTY!
Someone could be eavesdropping on you right now (man-in-the-middle attack)!
It is also possible that a host key has just been changed.
The fingerprint for the ECDSA key sent by the remote host is
<redacted>.
Please contact your system administrator.
Add correct host key in /home/user/.ssh/known_hosts to get rid of this message.
Offending ECDSA key in /home/user/.ssh/known_hosts:10
  remove with:
  ssh-keygen -f "/home/user/.ssh/known_hosts" -R jumpbox
ECDSA host key for jumpbox has changed and you have requested strict checking.
Host key verification failed.
ssh_exchange_identification: Connection closed by remote host

куда user мой обычный пользователь, а не пользователь, я пытаюсь SSH как.

Я понятия не имею, что здесь происходит. Есть ли в SSH специальное переопределение, заставляющее проверку хост-ключа на ситуации прокси-перехода? Если это так, то это сильно раздражает, поскольку создание локальной виртуальной машины создает реальную боль.

Источник

3 ответа

Решение

ProxyJump выдает другой ssh процесс, который не наследует аргументы командной строки, которые вы указываете в командной строке первого ssh команда. Есть два возможных выхода:

  • Используйте эти параметры в файле конфигурации в ~/.ssh/config - это может сэкономить вам много печатать тоже!

    Host jumpbox
  User jumpuser
  StrictHostKeyChecking=no
  UserKnownHostsFile=/dev/null
  IdentityFile ~/.ssh/id_jumpuser_rsa

    и тогда вы можете подключиться так же, как ssh -J jumpbox jumpuser@10.10.0.5,

  • использование ProxyCommand опция вместо - она ​​делает ту же работу, но более прозрачно, чтобы вы могли видеть, что на самом деле там происходит:

    ssh -o ProxyCommand="ssh -o StrictHostKeyChecking=no -o UserKnownHostsFile=/dev/null -i ~/.ssh/id_jumpuser_rsa -W %h:%p jumpuser@jumpbox" -i ~/.ssh/id_jumpuser_rsa jumpuser@10.10.0.5

Источник

Из превосходного ответа @Jakuje, я сделал этот скрипт для общего поиска файлов через бастионный хост:

#!/usr/bin/env bash
set -e

ME=$(basename $0)
log_() { echo "[$ME] $@"; }

PRIVATE_IP=$1
BASTION=$2
SOURCE=$3
TARGET=$4
USER=${5:-ubuntu}
BASTION_USER=${6:-$USER}

log_ Copying ${USER}@${PRIVATE_IP}:${SOURCE} to ${TARGET} via ${BASTION_USER}@${BASTION}

scp -o StrictHostKeyChecking=no -o UserKnownHostsFile=/dev/null \
    -o ProxyCommand="ssh -o StrictHostKeyChecking=no -o UserKnownHostsFile=/dev/null -l ${BASTION_USER} -W ${PRIVATE_IP}:22 ${BASTION}" \
    ${USER}@${PRIVATE_IP}:${SOURCE} ${TARGET}

Это полезно, если вы предоставляете частный хост внутри центра обработки данных.

Источник

Быть заядлым Google'ером, и это мой первый результат для stackoverflow.

Для ssh через jumpbox/ бастион без всяких хлопот, без системных модификаций и т. Д. Тогда вы должны использовать StrictHostKeyChecking=no оба для сеанса прокси, перемычка. Также вы должны использовать StrictHostKeyChecking=no в вашей команде proxy_command.

Кроме того, не становитесь слишком умными для себя и попробуйте использовать UserKnownHostsFile=/dev/null либо для сессии, либо для proxy_command, потому что ваша оболочка потеряет контекст при передаче и просто потерпит неудачу. Я не устранял проблемы дальше.

Эта команда была обнаружена при чистой загрузке файла с недавно созданного экземпляра на мою локальную рабочую станцию ​​через Terraform.local-exec Provisioner

ssh -i ssh_server_key.pem -o StrictHostKeyChecking=no -o ProxyCommand="ssh -o StrictHostKeyChecking=no -i ssh_server_key.pem ec2-user@<BASTION_IP> nc <INTERNAL_IP> 22" ubuntu@<INTERNAL_IP>
Источник
Другие вопросы по тегам