Невозможно подключиться по ssh с помощью ProxyJump, но работает с ssh -J

Невозможно подключиться по ssh с помощью ProxyJump, но работает с ssh -J

Мой вопрос:Как настроить хост-бастион для SSH на AWS с использованием экземпляра Ubuntu?

Я могу с успехом сделать следующее:

root@e183d80cdabc# ssh -J [email protected] [email protected]
Last login: Sat Sep  4 13:14:17 2021 from 10.240.0.30
==> SUCCESS! ==> ubuntu@ip-10-240-0-20:~$

Но он терпит неудачу, когда я пробую подход с файлом ~/.ssh/config. Используемые команды:

# ssh 10.240.0.20
# ssh [email protected]
# ssh -i ~/.ssh/id_rsa [email protected]

ssh: connect to host 10.240.0.20 port 22: Connection refused

Мой ~/.ssh/config выглядит так:

root@e183d80cdabc# cat $HOME/.ssh/config
Host bastion
  HostName 54.170.186.144
Host remote
  HostName 10.240.0.20
  ProxyJump bastion

Я запускаю Ubuntu на AWS следующим образом:

ubuntu@ip-10-240-0-30:~$ cat /etc/os-release
NAME="Ubuntu"
VERSION="20.04.2 LTS (Focal Fossa)"
ID=ubuntu
ID_LIKE=debian
PRETTY_NAME="Ubuntu 20.04.2 LTS"
VERSION_ID="20.04"
HOME_URL="https://www.ubuntu.com/"
SUPPORT_URL="https://help.ubuntu.com/"
BUG_REPORT_URL="https://bugs.launchpad.net/ubuntu/"
PRIVACY_POLICY_URL="https://www.ubuntu.com/legal/terms-and-policies/privacy-policy"
VERSION_CODENAME=focal
UBUNTU_CODENAME=focal

Я пробовал добавить User ubuntuполе, но это не помогло.

У меня /etc/ssh/ssh_configна сервере это выглядит так:

Host *
    ForwardX11Trusted yes
    IdentityFile ~/.ssh/id_rsa
    Port 22
    SendEnv LANG LC_*
    HashKnownHosts yes
    GSSAPIAuthentication yes

ОБНОВЛЯТЬ Теперь я использую подробный вариант, т.е.

root@e183d80cdabc# ssh -vvv 10.240.0.20
OpenSSH_8.2p1 Ubuntu-4ubuntu0.3, OpenSSL 1.1.1f  31 Mar 2020
debug1: Reading configuration data /root/.ssh/config
debug1: /root/.ssh/config line 2: Applying options for *
debug1: Reading configuration data /etc/ssh/ssh_config
debug1: /etc/ssh/ssh_config line 19: include /etc/ssh/ssh_config.d/*.conf matched no files
debug1: /etc/ssh/ssh_config line 21: Applying options for *
debug2: resolve_canonicalize: hostname 10.240.0.20 is address
debug2: ssh_connect_direct
debug1: Connecting to 10.240.0.20 [10.240.0.20] port 22.
debug1: connect to address 10.240.0.20 port 22: Connection refused
ssh: connect to host 10.240.0.20 port 22: Connection refused

Похоже, что он не использует хост прыжка (т.е. пропускает бастион), а идет напрямую и ПРОИСХОДИТ СБОИ.

Любые идеи приветствуются! Спасибо

=========================================================

ОБНОВЛЕНИЕ: 2021-09-04-15-44 - с РЕШЕНИЕМ Спасибо всем, я отметил как ответ ниже.

Правильная конфигурация не использует HostName, так как сопоставление выполняется поХозяин. Мне также удалось включить подстановочный знак в IP-адрес, что мне и было нужно.

Конфигурация ssh

root@e183d80cdabc# cat $HOME/.ssh/config
Host bastion
  HostName 63.33.206.201
  User ubuntu
Host 10.240.0.*
  ProxyJump bastion
  User ubuntu

Ивуаля!

# ssh 10.240.0.20
...
ubuntu@ip-10-240-0-20:~$

решение1

Сопоставление производится по Hostстрофе, а не по HostName.

Пытаться:

ssh ubuntu@remote

решение2

Разница между вашей командной строкой

ssh -J [email protected] [email protected]

и что я рекомендую вам сделать, чтобы сослаться на вашу конфигурацию

ssh remote

заключается в том, что последний не имеет ни IP-адресов, нипользователь, под которым нужно войти на оба компьютерав командной строке - вам нужно отредактировать конфигурацию ssh, включив в неевсеинформация, которую вы больше не передаете в командной строке:

# $HOME/.ssh/config
### The Bastion Host
Host bastion
  HostName 54.170.186.144
  User ubuntu

### The Remote Host
Host remote
  HostName 10.240.0.20
  User ubuntu
  ProxyJump bastion

Обновление: Хотя да, в теории выможетнастройте ваши Hostстрофы так, чтобы они соответствовали IP-адресам, я рекомендуюпротивделать это.

Если хост не доступен напрямую по определенному IP-адресу, то на него следует ссылаться поимя- только представьте, что произойдет, если одно и то же (частное) IP-пространство будет назначено нескольким хостам, и вы не сможете назначить каждому из них правильную конфигурацию ProxyJump.

Еще одна причина, по которой использование адресов для обозначения хостов невыгодно, — хосты, доступные через несколько семейств адресов: если хост доступен через IPv4 и IPv6, вы, вероятно, захотите, чтобы ваше ssh-соединение оставалось независимым от протокола и добавляло флаг только тогда, когда вы действительно хотите ограничить (автоматический) выбор.

Связанный контент