Я изо всех сил пытался установить допустимую конфигурацию, чтобы открыть соединение со второй машиной, проходить через другую и использовать id_rsa (который запрашивает у меня пароль) для соединения с третьей машиной.

Я задал этот вопрос на другом форуме, но не получил ответа, который можно было бы считать очень полезным.

Проблема, лучше описанная, выглядит следующим образом:

Local machine: user1@localhost
Intermediary machine: user1@inter
Remote target: user2@final

Я могу сделать все соединение, используя псевдо-tty:

ssh -t inter ssh user2@final

(это спросит меня пароль для файла id_rsa, который я имею в машине "inter")

Однако, чтобы ускорить процесс, я бы хотел установить свой файл .ssh / config, чтобы я мог просто подключиться к машине "final", используя:

ssh final

То, что я получил до сих пор - что не работает, - в моем файле .ssh / config:

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

Файл id_rsa используется для подключения к промежуточному компьютеру (для этого не требуется ввод пароля), а файл id_rsa_2 используется для подключения к «окончательному» компьютеру (этот запрос пароля).

Я попытался смешать некоторые LocalForwardи / или RemoteForwardполя и поместить файлы id_rsa на первую и вторую машины, но я не смог добиться успеха без какой-либо конфигурации.

PS: поток, я пытался получить некоторую помощь от:

http://www.linuxquestions.org/questions/linux-general-1/proxycommand-on-ssh-config-file-4175433750/

СПОСОБ 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. Все, что отправлено на локальный порт 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там.

Я не видел никаких перечисленных ошибок или операторов ssh -v, которые помогли бы увидеть, где он зависает.

Эй, чувак, у тебя почти все в порядке - лучший и самый безопасный способ - использовать оба ключа на локальной машине. Затем вы будете использовать пересылку ssh-agent для соединения, а не оставлять ключи на промежуточных этапах. У вас также есть преимущество необходимости вводить ключевую фразу только один раз за вход в систему.

Если у вас есть современная / удобная для пользователя ОС, такая как Ubuntu (на вашем локальном компьютере), это не должно работать без каких-либо «массажей». Я специально удалил файл идентификации, он вам не понадобится.

Ваш конфигурационный файл будет выглядеть так:

Host inter
    User user1
    ForwardAgent yes
    HostName inter.com

Host final
    ForwardAgent yes
    User user2
    HostName final.com
    ProxyCommand ssh inter nc %h %p

Если этого не произойдет, выполните следующие шаги, чтобы убедиться, что ваш ssh-agent запущен:

'ssh-add -l' (lower case L) will list your private keys if any are loaded, or will be blank, or will say can’t connect to ssh-agent, if so, start ssh-agent.
'eval `ssh-agent`' (those are backticks) starts ssh agent
'ssh-add' will add your key… you can add a path argument if you have a key in a non-default area. At this point you will enter your passphrase.

Здесь есть хорошее руководство, объясняющее, как это работает .