Іноді нам потрібно передавати дані через сокет між різними машинами, такими як підключення Telnet, завантаження файлу FTP, запит SQL або будь-який інший тип передачі.
Ці дані передаються необробленими через мережу, отже невпевнено, що означає, що їх може перехопити будь-який вузол, що знаходиться на шляху між початком та пунктом призначення, тобто вкрадене.
Ми не можемо запобігти захопленню цих даних, але ми можемо запобігти тому, що вони інтерпретуються та розуміються третіми сторонами, шифруючи повідомлення.
SSH це інструмент, який дозволяє нам це робити безпечні з'єднання між машинами. Найбільш поширеним його використанням є віддалене підключення до інтерпретатора команд.
Однак він пропонує інші можливості, наприклад, створення зашифровані тунелі між різними машинами.
Припустимо, ми хочемо встановити telnet від host1 до host2:
host1$ telnet host2
Це спілкування є абсолютно відкритим і може бути перехоплений. Для його захисту ми перенаправляємо довільно вибраний порт (наприклад, 5000) на хості 1 на порт 23 (telnet) на хості2.
Таким чином, ми отримаємо всі дані, що надсилаються до порту 5000 хосту1 для подорожі, зашифровані через тунель, який ssh відкривається через порт 22 хоста2, а потім перенаправляються в порт 23 хосту2, таким чином досягаючи кінцевого пункту призначення.
Для цього нам потрібно знати ім’я користувача та пароль host2.
Щоб відкрити тунель, ми пишемо:
host1$ ssh -R 5000:localhost:23 usuariohost2@host2
Ну добре:
host1$ ssh -L 5000:host2:23 usuariohost2@host2
Обидва варіанти рівнозначні. Для встановлення з'єднання telnet ми більше не посилаємось на host2, а на порт, вибраний на host1:
host1$ telnet localhost 5000
Завдяки цьому ми робимо безпечним будь-яке спілкування, будь то телнет чи інше. Досліджуючи ще трохи, ми побачимо, що завдяки силі SSH Ці переадресації також можуть бути зроблені на треті машини, що дозволило б нам, що за допомогою однієї точки входу ми можемо безпечно отримати доступ із цілої локальної мережі до іншої локальної мережі.
Теорія виглядає надзвичайно цікавою, але було б ще цікавіше, якби ми побачили практичний випадок.
Але правда полягає в тому, що, хоч я і був невисоким, я дуже любив цю статтю.
можливо, дивлячись на вікі, ви отримуєте натхнення https://wiki.archlinux.org/index.php/Secure_Shell#Forwarding_other_ports
і те саме, але розділ автосш https://wiki.archlinux.org/index.php/Secure_Shell#Autossh_-_automatically_restarts_SSH_sessions_and_tunnels
Власне, все, що ви можете надіслати через ssh, будь то потокове передавання, підключення до хоста. тощо що з x причини ви хочете їх зашифрувати.
і правила securecrt
Я іноді використовую SSH на дуже базовому рівні. Порт за замовчуванням - 22, так?
Отже, якщо я правильно розумію, мій ПК - це хост 1, а той, який я хочу підключити, - це host2, цей тунель створить зв’язок між портом 5000 та портом 23, а потім опиниться в порту 22?
Чому причини перемикання портів? Чи можете ви створити тунель з портом 22?
Дуже цікава стаття. Як нано, я хочу ще!
SSH справді використовує порт 22 за замовчуванням (хоча його можна змінити). Цей порт використовується тим, який використовував би фактичний зв’язок між двома хостами. Це той, який ви повинні переконатись, що він відкритий і жоден брандмауер його не відключає. Але для користувача це абсолютно прозоро. Про це можна забути. У цьому прикладі переспрямування здійснюється між портами 5000 і 23. Ці два є єдиними, про що вам слід турбуватися. Користувач побачить, що все, що він надсилає на порт 5000 свого хоста, відображається на 23 хоста призначення.
Очевидно, кожен користувач може перенаправити порти, які він вважає доречними.
Дякуємо за ваші коментарі. Це мій перший допис, і ваші думки допоможуть зробити наступний кращим.
Чи можна це зробити також за допомогою VPS?
Гаразд, це мій випадок, PC1 має доступ до сервера, але PC2 не має, обидва підключаються через ssh, я хочу мати доступ до PC2, але на який порт PC1 мені перенаправити? якщо насправді те, що я хочу, - це дістатися до порту сервера з PC2 і щоб пакети мали PC1 як вихідний IP. я розумію?
Ви даєте зрозуміти. У цьому випадку вам потрібен PC1 для перенаправлення порту PC2 на порт 22 сервера:
PC2 $ ssh -L 5000: Сервер: 22 користувача PC1 @ PC1
і, тримаючи це з'єднання відкритим, з іншого терміналу:
PC2 $ ssh userServer @ localhost -p 5000
і ти вже всередині.
Нарешті функціональне рішення !! Дякую Getafix, Ви дали мені світ можливостей !!
Я радий!
Excelente artículo. Bienvenido a DesdeLinux 😀
А що робити, якщо у нас заблоковано 22? ЛОЛ..
Дякую elav.
Якщо у вас заблоковано порт 22, мммм, нам доведеться шукати альтернативу злому брандмауера XD
І найгірше (гіпотетичне): це заблоковано постачальником VPS.
Я щойно склав іспит кілька годин тому із запитаннями щодо нього 😛
Я б не сказав, що:
host1 $ ssh -R 5000: localhost: 23 userhost2 @ host2
це еквівалентно іншому командному рядку ... тому, що має -L.
Оскільки -R означає, що порт, який відкривається для нових з'єднань, знаходиться на віддаленій стороні, тобто на стороні вашого сервера ssh; в той час як -L відкриває порт на локальній стороні, на стороні клієнта для отримання нових з'єднань.
Переклад рядка:
host1 $ ssh -R 5000: localhost: 23 userhost2 @ host2
Це було б приблизно так: Перебуваючи на хості1, підключіться до сервера ssh (порт 22) хоста2 з моїм користувачем userhost2 і переадресуйте з'єднання, створені на віддаленому порту 5000 хосту2, до порту 23 на хості1 (мій localhost)
Якщо ні, виправте мене! 😉
-
З іншого боку ... якщо сервер заблокував вхід підключень до порту 22, тобто ми не можемо віддалено підключитися до сервера ssh; що можна зробити, це; що з сервера (друг sysadmin позаду брандмауера віддаленої системи host2) виконується командний рядок:
host2 $ nohup ssh -fN -R 6000: localhost: 22 userhost1 @ host1
-f переходить у фоновий режим
-N не виконує жодної команди на пульті дистанційного керування
nohup запобігає перериванню виконання команди під час виходу з системи
host1 $ ssh userhost2 @ localhost -p 6000
Таким чином, з host1 ми генеруємо з'єднання з localhost (тим самим хостом1) на порту 6000, який переадресовує з'єднання на порт 22 віддаленої системи host2, в якому ми будемо входити з користувачем host2.
Це дозволило б (я не пробував, але, схоже, це працює), входити на ssh-сервер, заблокований брандмауером, з невеликою допомогою всередині! 😀
Останнє я прочитав із пояснення, зробленого в журналі The Geek Stuff
http://www.thegeekstuff.com/2013/11/reverse-ssh-tunnel/
Мені дуже подобається ваша публікація; Я їх часто читаю!
Привіт.
Ти правий. У статті сталася помилка. Переспрямування не є рівнозначними. Команда host1 $ ssh -R 5000: localhost: 23 userhost2 @ host2 виконує зворотне перенаправлення, тобто перенаправляє віддалений порт 5000 на 23 локальний, протилежний тому, що робить команда з -L.
Дякую за виправлення.