СПОСОБ 1 (используйте ssh-ключ на интерфейсе)
Если вы хотите сохранить поток аутентификации
local -- authenticate --> inter -- authenticate (ask password) --> final
Это не может быть сделано с .ssh/config proxyhost.
Вам нужен псевдоним оболочки bash (надеюсь, вы используете bash).
В ~/.bashrc добавьте следующую строку
alias ssh-final='ssh -t inter ssh user2@final.com'
В командной строке просто введите следующее
ssh-final
final раздел в ~/.ssh/config не используется.
Детали подключения (1)
ssh -t inter ssh user2@final.com можно посмотреть следующим образом
local# ssh inter
inter# ssh user2@final.com
local только "разговаривают" с inter . Нет прямой или косвенной связи ssh между local и final . local просто отображает вывод ssh user2@final.com .
МЕТОД 2 (используйте ssh-ключ на локальном)
Аутентификация с помощью того же ssh-ключа
Host inter
User user1
HostName inter.example.com
Host final
User user2
Hostname <final.com / final IP Address>
Port 22
ForwardAgent yes
ProxyCommand ssh inter nc %h %p
Скопируйте локальный ~/.ssh/id_ras.pub в
/home/user1/.ssh/authorized_keys in `inter`
/home/user2/.ssh/authorized_keys in `final`
Детали подключения (2)
SSH туннелирование
Прежде чем мы углубимся в детали ProxyCommand , давайте рассмотрим следующий пример
Шаг 1, в окне терминала 1
local# ssh inter -L 2000:final.com:22
Шаг 2, в окне терминала 2
local# ssh localhost -p 2000
В терминале 1 туннель настроен между локальным портом 2000 и портом final.com 22. Все, что отправлено на локальный порт 2000, будет перенаправлено на порт final.com 22 и наоборот.
В терминале 2 ssh подключается к локальному порту 2000, но на самом деле связывается с портом 22 final.com, который является sshd.
При туннелировании локальный ssh-клиент на шаге 2 напрямую связан с sshd final.com.
"Выход" локального порта 2000 - это "сырой" трафик демона ssh.
Обычно такой туннель используется для доступа к внутреннему веб-серверу или серверу электронной почты. Ниже приведен пример для веб-сервера
local# ssh inter -L 2000:final.com:80
В браузере используйте следующий URL
http://localhost:2000
Две конечные точки туннеля - это локальный порт 2000 и порт final.com.
Трафик, поступающий и выходящий из конечной точки туннеля "КАК ЕСТЬ". Давайте назовем этот "сырой" трафик.
ProxyCommand
Host final
User user2
Hostname <final.com / final IP Address>
Port 22
ForwardAgent yes
ProxyCommand ssh inter nc %h %p
ProxyCommand делает еще один шаг вперед. Он пропускает этап создания локального порта и подключается к нему.
Клиент ssh выполнит любую команду, заданную в ProxyCommand , и обработает вывод этой команды как "необработанный" трафик. Он удерживает локальную конечную точку, а затем запускает ssh-соединение с ним.
Почему одна работа другой нет?
Следующая команда
ssh inter nc final.com 22
в основном означает (1) подключиться к inter , затем (2) к inter , выполнить команду nc final.com 22 .
nc - arbitrary TCP and UDP connections and listens
Таким образом, nc final.com 22 подключится к порту 22 final.com, распечатает весь входящий трафик на стандартный вывод и отправит весь ввод на другую сторону. Это "туннель" между nc stdin/out и портом final.com 22.
Поскольку nc в сеансе ssh, весь его стандартный вывод передается обратно клиенту ssh как "сырой" трафик. А ssh-клиент может передавать трафик в nc stdin, который в конечном итоге будет находиться на порте 22 final.com.
Через вышеупомянутый "туннель" локальный клиент ssh начнет сеанс ssh напрямую с final.com .
Следующая команда
ssh -t inter ssh user2@final.com
не работает с ProxyCommand потому что он не является "необработанным" трафиком от демона ssh. Это стандартный вывод ssh-клиента. Общение клиента с клиентом означает отсутствие бизнеса.
Аутентификация с использованием другого ssh-ключа (OP оригинального конфига)
Host inter
User user1
HostName inter.com
IdentityFile ~/.ssh/id_rsa
Host final
User user2
HostName final.com
IdentityFile ~/.ssh/id_rsa_2
ProxyCommand ssh inter nc %h %p
Скопируйте локальный ~/.ssh/id_ras.pub в
/home/user1/.ssh/authorized_keys in `inter`
Скопируйте локальный ~/.ssh/id_ras_2.pub в
/home/user2/.ssh/authorized_keys in `final`
Оба из вышеупомянутого позволят следующее использование
local# ssh final
Дополнительная проверка
Используйте многословно
local# ssh -v final
Это должно помочь выявить проблему SSH.
Проверьте нк
ProxcyCommand выполняет nc на inter . Проверьте, действительно ли nc доступен на inter .
local# ssh inter
inter# nc final.com 22
Проверьте правильность настройки ключа RSA
Если разные ключи должны использоваться для inter и final , следующие файлы должны существовать на локальном компьютере
local# ls ~/.ssh
id_rsa id_rsa_2 id_rsa.pub id_rsa_2.pub
Так как вы можете SSH в inter уже, проверьте настройки ключа на final С вашей локальной машины
local# ssh -t inter ssh user2@final
final# cat .ssh/authorized_keys
Вы должны увидеть содержимое id_rsa_2.pub там.
