Понякога имаме нужда предавайте данни през гнездо между различни машини, като Telnet връзка, изтегляне на FTP файл, SQL заявка или друг вид предаване.
Тези данни пътуват сурови през мрежата, така че аз несигурен, което означава, че те биха могли да бъдат прихванати от всеки възел, който е по пътя между началото и дестинацията, т.е. откраднат.
Не можем да предотвратим заснемането на тези данни, но това, което можем да предотвратим, е, че те се интерпретират и разбират от трети страни, като криптират комуникацията.
SSH е инструментът, който ни позволява да правим сигурни връзки между машините. Най-честото му използване е да се свързва дистанционно с интерпретатор на команди.
Той обаче предлага и други възможности, като създаване криптирани тунели между различни машини.
Да предположим, че искаме да telnet от host1 до host2:
host1$ telnet host2
Тази комуникация е напълно отворена и може да бъде пресича. За да го защитим, ще пренасочим произволно избран порт (например 5000) на хост 1 към порт 23 (telnet) на хост2.
По този начин ще получим всички данни, изпратени до порт 5000 на host1, за да пътуват криптирани през тунела, който ssh се отваря през порт 22 на host2 и след това да бъдат пренасочени към порт 23 на host2, като по този начин ще достигнат крайната си дестинация.
За да направим това, трябва да знаем потребителското име и паролата на host2.
За да отворим тунела, пишем:
host1$ ssh -R 5000:localhost:23 usuariohost2@host2
О, добре:
host1$ ssh -L 5000:host2:23 usuariohost2@host2
И двата варианта са еквивалентни. За да установим telnet връзката, ние вече не се позоваваме на host2, а на порта, избран на host1:
host1$ telnet localhost 5000
С това правим всяка комуникация сигурна, била тя telnet или по друг начин. Разследвайки малко повече, ще видим, че благодарение на силата на SSH Тези пренасочвания могат да бъдат направени и към трети машини, което би ни позволило, че с една входна точка можем безопасно да осъществим достъп от цяла LAN към различна LAN.
Теорията изглежда изключително интересна, но би било още повече, ако видим практически случай.
Но истината е, че макар да бях нисък, харесах статията.
може би гледайки уикито, което се вдъхновява https://wiki.archlinux.org/index.php/Secure_Shell#Forwarding_other_ports
и същото, но раздела autossh 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, дадохте ми свят от възможности !!
Радвам се!
Отлична статия. добре дошли в DesdeLinux ????
И какво да направим, ако имаме 22 блокирани? LOL ..
Благодаря 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) на host2 с моя потребител userhost2 и препратете връзките, генерирани на отдалечен порт 5000 на host2 към порт 23 на host1 (моя 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.
Благодаря ви за корекцията.