Я намагався встановити правильну конфігурацію, щоб відкрити з'єднання з другою машиною, пройшовши через іншу, і використовуючи 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 використовується для підключення до машини "final" (цей запит пароля).

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

P.S .: потік, який я спробував отримати допомогу від:

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 порт 22. Все, що надіслано до локального порту 2000, буде перенаправлено до порта final.com 22 і навпаки.

У терміналі 2 ssh підключається до локального порту 2000, але насправді спілкується з final.com port 22, який є sshd.

З тунелювання, локальний клієнт SSH на кроці 2 пов'язаний з final.com sshd безпосередньо.

"Висновок" локальних портів 2000, є "сирим" трафіком демон ssh.

Загальним використанням такого тунелю є доступ до внутрішнього веб-сервера або сервера електронної пошти. Нижче наведено приклад для веб-сервера

local# ssh inter -L 2000:final.com:80

У браузері використовуйте наступну URL-адресу

http://localhost:2000

Дві кінцеві точки тунелю - локальний порт 2000, а final.com порт 80.

Трафік, що надходить і виходить з кінцевої точки тунелю "ЯК Є". Давайте назвемо це "сирим" трафіком.

ProxyCommand

Host final
    User user2
    Hostname <final.com / final IP Address>
    Port 22
    ForwardAgent yes
    ProxyCommand ssh inter nc %h %p

The 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 підключиться до порту final.com 22, роздрукує весь вхідний трафік до stdout і надішле всі stdin на іншу сторону. Це "тунель" між nc stdin / out та final.com port 22.

З nc виконується в сеансі ssh, весь його stdout передається назад до клієнта ssh, як "raw" трафік. А клієнт ssh може передати трафік в nc stdin, що закінчиться на final.com port 22.

Через вищезгаданий "тунель" локальний клієнт ssh почне сеанс ssh з final.com безпосередньо.

Наступна команда

ssh -t inter ssh user2@final.com

не працює ProxyCommand тому що вихід з нього не є "сирим" трафіком від демона ssh. Це вихідний сигнал a 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.

Перевірте nc

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

Є хороший довідник, що пояснює, як це працює тут.