Журнал LinuxFormat - перейти на главную

LXF168:Уда­лен­ный доступ Shellinabox

Материал из Linuxformat
Перейти к: навигация, поиск

Содержание

За­щи­щен­ный дос­туп че­рез web-брау­зер

Крис Нот­ли по­ка­жет, как упот­ре­бить Shellinabox с об­рат­ным про­кси Apache для обес­пе­че­ния за­щи­щен­но­го дос­ту­па к Linux-ком­пь­ю­те­ру толь­ко че­рез брау­зер.

(thumbnail)
Наш эксперт Крис Нот­ли поль­зу­ет­ся Linux и ра­бо­та­ет с ним бо­лее 12 лет, но ре­аль­но под­сел на не­го, от­крыв пре­лес­ти Asterisk и MythTV.

Уда­лен­ный доступ к обо­лоч­ке до­машнего сер­ве­ра стал для ме­ня нор­мой жизни, и без него мне бы­ло бы труд­но обой­тись. Нуж­но ли про­ве­рить воз­мож­ность под­клю­чения к уда­лен­но­му сай­ту, из­менить скрипт монито­рин­га или про­сто пе­ре­за­пустить сер­вис – мне боль­ше неза­чем мчать­ся для это­го до­мой.

Пол­но­цен­ные VPN-ре­шения с ис­поль­зо­ванием IPSEC или PPTP да­ют гиб­кий доступ ко всей се­ти, но для их безо­пас­ной на­строй­ки при­дет­ся по­тру­дить­ся, а в кор­по­ра­тив­ных се­тях та­кой тра­фик обыч­но за­пре­щен бранд­мау­эра­ми.

На дру­гом кон­це шка­лы – SSH-под­клю­чение на­пря­мую к сер­ве­ру че­рез ро­утер или бранд­мау­эр яв­ля­ет­ся и за­щи­щен­ным, и от­но­си­тель­но про­стым, но SSH-доступ во мно­гих се­тях бы­ва­ет невоз­мо­жен. Са­мая час­тая при­чи­на про­блем – стан­дарт­ный порт SSH (TCP/22) за­пре­щен бранд­мау­эром (так неред­ко бы­ва­ет в кор­по­ра­тив­ных се­тях и в точ­ках пуб­лич­но­го досту­па к Ин­тернету). Иногда про­бле­му мож­но ре­шить, пе­ре­на­стро­ив SSH-сер­вер так, что­бы он слу­шал порт, свя­зан­ный с web-сер­ви­са­ми (на­при­мер, TCP/80 или TCP/443). Од­на­ко ниче­го не по­лу­чит­ся, ес­ли на том же хосте дол­жен ра­бо­тать web-сер­вер. Это ре­шение так­же встре­ча­ет бо­лее серь­ез­ные пре­пят­ст­вия в боль­ших кор­по­ра­тив­ных се­тях, где доступ к web-пор­там обыч­но осу­ще­ст­в­ля­ет­ся че­рез про­кси.

Еще од­но по­тен­ци­аль­ное ог­раничение мо­жет возник­нуть, ес­ли вы поль­зуе­тесь чу­жим ком­пь­ю­те­ром для досту­па. На за­бло­ки­ро­ван­ных тер­ми­на­лах – на­при­мер, на ог­раничен­ных в пра­вах кор­по­ра­тив­ных ком­пь­ю­те­рах или киосках – мо­жет не быть SSH-кли­ен­та, и уста­но­вить его нель­зя. Про­грам­мы для досту­па к обо­лоч­ке или к тер­ми­на­лу че­рез web-брау­зер су­ще­ст­ву­ют до­воль­но дол­го, но обыч­но ис­поль­зу­ют Java со все­ми про­бле­ма­ми со­вмес­ти­мо­сти, ко­то­рые мы нау­чи­лись лю­бить! С ростом воз­мож­но­стей со­вре­мен­ных брау­зе­ров (в ча­ст­но­сти, с раз­ви­ти­ем движ­ков JavaScript в этих брау­зе­рах) ста­ло воз­мож­ным най­ти ре­шение, не ис­поль­зую­щее пла­ги­ны вро­де Java.

Shellinabox

Shellinabox – web-эму­ля­тор тер­ми­на­ла на Ajax, со­вмес­ти­мый с боль­шин­ст­вом со­вре­мен­ных web-брау­зе­ров, под­дер­жи­ваю­щих CSS и JavaScript. Сер­вер­ная часть про­грам­мы пред­став­ля­ет со­бой вы­де­лен­ный web-сер­вер, ко­то­рый при под­клю­чении кли­ен­та по умол­чанию за­пуска­ет /bin/login, вы­во­дя при­гла­шение для вво­да ло­ги­на/па­ро­ля, и по­сле успеш­ной ау­тен­ти­фи­ка­ции за­пускает обо­лоч­ку кли­ен­та по умол­чанию.

Shellinabox за­пуска­ет­ся как де­мон и по умол­чанию слу­ша­ет за­щи­щен­ные со­единения на пор­ту TCP/4200. Порт мож­но за­менить на TCP/443, то есть порт, за­ре­зер­ви­ро­ван­ный для за­щи­щен­ных HTTP-со­единений, но это при­во­дит к двум боль­шим про­бле­мам. Пер­вая – в том, что во мно­гих слу­ча­ях вы мо­же­те за­хо­теть за­пустить дру­гие web-сер­ви­сы че­рез за­щи­щен­ные со­единения с то­го же ком­пь­ю­те­ра. Вто­рая – встро­ен­ный web-сер­вер пре­достав­ля­ет ма­ло воз­мож­но­стей для тон­ко­го кон­тро­ля досту­па, по­это­му ка­ж­дый, кто под­клю­чит­ся к сер­ве­ру че­рез web-брау­зер, уви­дит при­гла­шение для вхо­да в сис­те­му. Внешний вид Shellinabox лег­ко из­менить, и для это­го не по­на­до­бит­ся ниче­го, кро­ме CSS.

В от­ли­чие от неко­то­рых аль­тер­на­тив, Shellinabox пре­достав­ляет пол­но­цен­ный эму­ля­тор тер­ми­на­ла на JavaScript, а зна­чит, в нем мож­но вы­пол­нять са­мые раз­но­об­раз­ные дей­ст­вия, обыч­но вы­пол­няе­мые в тер­ми­на­ле. Пре­крас­ный при­мер это­го – до­маш­няя страница Shellinabox (http://code.google.com/p/shellinabox/).

Web-про­кси

Web-про­кси – это сер­вис, ко­то­рый си­дит ме­ж­ду web-кли­ен­том и сер­ве­ром и су­ще­ст­ву­ет в двух ва­ри­ан­тах. Пер­вый – пря­мой про­кси, и его кли­ен­ты обыч­но долж­ны знать о нем (как зна­ют боль­шин­ст­во брау­зе­ров). При возник­но­вении за­про­са (на­при­мер, при вво­де ад­ре­са в брау­зер, в ко­то­ром на­стро­ен про­кси), кли­ент от­прав­ля­ет за­прос про­кси, ко­то­рый, в свою оче­редь, за­пра­ши­ва­ет со­дер­жи­мое непо­сред­ст­вен­но у за­пра­ши­вае­мо­го web-сер­ве­ра. За­тем про­кси воз­вра­ща­ет это со­дер­жи­мое кли­ен­ту. Пря­мой про­кси так­же мож­но на­стро­ить в про­зрач­ном ре­жи­ме, тогда кли­ен­там не нуж­но знать о про­кси. В пря­мых про­кси обыч­но есть некая фор­ма для управ­ления со­дер­жи­мым, на ко­то­рой мож­но за­бло­ки­ро­вать доступ к неже­ла­тель­ным сай­том. Они так­же обыч­но кэ­ши­ру­ют ста­ти­че­­ское со­дер­жи­мое, на­при­мер, изо­бра­жения, по­это­му у мно­гих про­вай­де­ров на­строе­ны про­зрач­ные пря­мые про­кси для эко­но­мии ка­на­ла.

Вто­рой ва­ри­ант – об­рат­ный про­кси, и на на­шем уро­ке мы им и восполь­зу­ем­ся. Ос­нов­ное раз­ли­чие ме­ж­ду об­рат­ным и пря­мым про­кси в том, что об­рат­ный при­кры­ва­ет оп­ре­де­лен­ные сай­ты или со­дер­жи­мое на сто­роне сер­ве­ра, а пря­мой про­кси обыч­но воз­вра­ща­ет лю­бое за­про­шен­ное со­дер­жи­мое. Web-кли­ен­там не нуж­но знать, что сайт об­слу­жи­ва­ет­ся об­рат­ным про­кси, ад­рес бу­дет ука­зы­вать пря­мо на про­кси, а кли­ент про­сто уви­дит от­вет на свой за­прос. С по­мо­щью об­рат­но­го про­кси мож­но при­менить к на­бо­ру сер­ве­ров по­сто­ян­ную кон­фи­гу­ра­цию безо­пас­но­сти вме­сто то­го, что­бы вы­пол­нять одни и те же на­строй­ки на ка­ж­дом из них.

Apache

Су­ще­ст­ву­ет нема­ло об­рат­ных про­кси для Linux, но мы возь­мем Apache. В мо­ду­ле про­кси Apache мож­но на­стро­ить пу­ти (на­при­мер, http://webserver/path1), ссы­лаю­щие­ся на дру­гой сер­вер, а не на HTML-фай­лы на локаль­ном дис­ке. Это не обя­за­тель­но фи­зи­че­­ски от­дель­ный сер­вер, это мо­жет быть и дру­гой де­мон web-сер­ве­ра на том же ком­пь­ю­те­ре. Пре­иму­ще­ст­во Apache здесь в том, что в нем лег­ко управ­лять досту­пом к сер­ви­сам. На­при­мер, мож­но вклю­чить ка­кую-ли­бо фор­му ау­тен­ти­фи­ка­ции и/или яв­но раз­ре­шить или за­пре­тить под­клю­чение с определен­ных IP-ад­ре­сов и т. д.

Не­ко­то­рые web-при­ло­жения нуж­но немно­го до­ра­бо­тать, пре­ж­де чем по­ме­щать их за об­рат­ный про­кси. В ча­ст­но­сти, из­менить аб­со­лют­ные ссыл­ки на от­но­си­тель­ные (на­при­мер, <link rel=“stylesheet” type=“text/css” href= “/css/default.css”> вме­сто <link rel=“stylesheet” type=“text/css” href= “../css/default.css”> – за­меть­те две точ­ки во вто­ром при­ме­ре). Что­бы обой­ти про­бле­му, мо­жет по­тре­бо­вать­ся спо­соб­ность Apache пе­ре­пи­сы­вать со­дер­жи­мое. К сча­стью для нас, Shellinabox лег­ко ин­тег­ри­ру­ет­ся с обыч­ным про­кси, и ме­нять ниче­го не при­дет­ся.

Еще од­но боль­шое пре­иму­ще­ст­во Apache как об­рат­но­го про­кси в том, что мож­но про­дол­жать об­ра­ба­ты­вать дру­гие web-за­про­сы с его по­мо­щью. В мо­ем слу­чае Apache об­слу­жи­ва­ет Shellinabox вме­сте с MythWeb, phpMyAdmin и еще несколь­ки­ми до­мо­дель­ны­ми web-при­ло­жения­ми.

Со­единив воз­мож­но­сти Shellinabox с об­рат­ным про­кси Apache, мож­но по­лу­чить еще один ме­тод уда­лен­но­го досту­па, со­вмес­ти­мый поч­ти со все­ми опе­ра­ци­он­ны­ми сис­те­ма­ми и кон­фи­гу­ра­ция­ми бранд­мау­эра, а так­же до­воль­но эф­фект­ный при де­мон­ст­ра­ции дру­гим поль­зо­ва­те­лям! И Shellinabox, и Apache есть в стан­дарт­ных ре­по­зи­то­ри­ях мно­гих со­вре­мен­ных ди­ст­ри­бу­ти­вов Linux, и за­ста­вить обо­их ра­бо­тать не так уж слож­но. На на­шем уро­ке мы уста­но­вим Shellinabox и на­стро­им его для ра­бо­ты с Apache на чис­той уста­нов­ке Ubuntu 12.10 Server. Мы так­же рас­смот­рим два пре­ды­ду­щих ре­ли­за Ubuntu LTS (12.04 и 10.04). В дру­гих ди­ст­ри­бу­ти­вов ме­сто­по­ло­жение фай­ла на­строй­ки мо­жет быть дру­гим. Од­на­ко боль­шая часть это­го ру­ко­во­дства все рав­но по­дой­дет.

По­гру­жа­ем­ся

Пер­вый этап – уста­нов­ка чис­той сис­те­мы Ubuntu Server (12.10). Ес­ли вы хо­ти­те сде­лать это в VirtualBox, мож­но ска­чать го­то­вый об­раз у от­лич­ных ре­бят из VirtualBoxImages (http://bit.ly/T0CDjH). При уста­нов­ке Ubuntu Server с ну­ля, един­ст­вен­ное ре­ко­мен­дуе­мое из­менение в кон­фи­гу­ра­ции – вклю­чить сер­вер OpenSSH на эта­пе вы­бо­ра про­грамм [Software Selection] во вре­мя уста­нов­ки.

В слу­чае го­то­во­го об­раза с VirtualBoxImages на­до учесть несколь­ко мо­мен­тов. Вир­ту­аль­ная ма­ши­на по­пы­та­ет­ся вклю­чить ин­тер­фейс WLAN1, по­это­му обя­за­тель­но за­дай­те пра­виль­ный ин­тер­фейс в на­строй­ках. По умол­чанию на­строе­но по­лу­чение IP-ад­ре­са по DHCP – мож­но ли­бо из­менить его на ста­ти­че­­ский ад­рес, ли­бо за­пи­сать на­зна­чен­ный ад­рес (и да­лее до кон­ца урока за­ме­нять SERVER_IP на этот ад­рес).

(thumbnail)
> Ти­пич­ный об­рат­ный про­кси в дей­ст­вии.

В об­ра­зе VirtualBox, на ко­то­рый мы ссы­ла­лись вы­ше, по умол­чанию уста­нов­ле­на италь­ян­ская рас­клад­ка кла­виа­ту­ры; ес­ли вам нуж­на дру­гая, ско­ман­дуй­те

sudo dpkg-reconfigure keyboard-configuration

Вам пред­ло­жат из­менить несколь­ко па­ра­мет­ров, вклю­чая стра­ну – за­дай­те их со­от­вет­ст­вую­щим об­ра­зом. Ес­ли вы но­ви­чок в ра­бо­те с сер­ви­са­ми, от­кры­ты­ми для досту­па из­вне, то неве­ро­ят­но по­лез­ной станет при­выч­ка ре­гу­ляр­но об­нов­лять сис­те­му. Сер­ви­сы вро­де Apache об­нов­ля­ют­ся ре­гу­ляр­но, и это по­зво­лит вам миними­зи­ро­вать уяз­ви­мость ком­пь­ю­те­ра для внешних воз­дей­ст­вий.

Сер­вер мож­но об­но­вить с команд­ной стро­ки, за­пустив сле­дую­щие ко­ман­ды:

sudo apt-get update

sudo apt-get -y dist-upgrade

sudo shutdown -r now

По­сле пе­ре­за­груз­ки сер­ве­ра ус­та­но­ви­те Apache, ко­ман­дой

sudo apt-get install -y apache2

За­тем нуж­но уста­но­вить Shellinabox, и спо­соб уста­нов­ки за­ви­сит от ва­шей вер­сии Ubuntu. В ре­по­зи­то­ри­ях Ubuntu 12.10 уже есть Shellinabox, и ее мож­но уста­но­вить ко­ман­дой

sudo apt-get install -y shellinabox

В ре­по­зи­то­ри­ях Ubuntu 12.04 и ранее ее нет, и ее нуж­но за­гру­зить и уста­но­вить. Вер­сия фай­ла за­ви­сит от то­го, 32- или 64-раз­ряд­ной вер­си­ей Ubuntu вы поль­зуе­тесь:

32-бит­ная:

wget http://shellinabox.googlecode.com/files/shellinabox_2.10-1_i386.deb

sudo dpkg -i shellinabox_2.10-1_i386.deb

64-бит­ная:

wget http://shellinabox.googlecode.com/files/shellinabox_2.10-1_amd64.deb

sudo dpkg -i shellinabox_2.10-1_amd64.deb

Те­перь мож­но про­ве­рить ба­зо­вую функ­цио­наль­ность Shell­inabox, от­крыв брау­зер и на­брав https://SERVER_IP:4200. Брау­зер по­жа­лу­ет­ся на сер­ти­фи­кат SSL, ко­то­рый яв­ля­ет­ся само­под­пи­сан­ным. На­жав «Про­дол­жить», вы уви­ди­те ин­тер­фейс Shellinabox по умол­чанию со стро­кой вхо­да в сис­те­му. Ос­мот­ри­те ин­тер­фейс. По­про­буй­те все ко­ман­ды и ме­ню, ко­то­ры­ми обыч­но поль­зуе­тесь, пе­ред тем, как мы на­стро­им Shellinabox для ра­бо­ты с Apache.

Что­бы поль­зо­вать­ся Shellinabox че­рез Apache, в на­строй­ки по умол­чанию нуж­но внести несколь­ко из­менений. От­крой­те файл /etc/default/shellinabox в лю­би­мом тек­сто­вом ре­дак­то­ре и вы­полните сле­дую­щие из­менения:

До:

SHELLINABOX_ARGS=”--no-beep”

По­сле:

SHELLINABOX_ARGS=”--no-beep --localhost-only --disablessl”

Пер­вый ар­гу­мент (--localhost-only) ве­лит Shellinabox слу­шать со­единения толь­ко с соб­ст­вен­но­го се­те­во­го адап­те­ра. Эта важ­ная ме­ра пре­досто­рож­но­сти га­ран­ти­ру­ет, что под­клю­чать­ся к Shellinabox смо­гут толь­ко про­цес­сы, за­пу­щен­ные локаль­но на сер­ве­ре, и не по­зво­лит под­клю­чать­ся на­пря­мую к сер­ви­су из-за непра­виль­но на­стро­ен­но­го бранд­мау­эра или некор­рект­ного пра­ви­ла NAT.

Вто­рой ар­гу­мент (--disable-ssl) раз­ре­ша­ет Shellinabox принимать толь­ко неза­шиф­ро­ван­ные под­клю­чения. Сна­ча­ла это мо­жет по­ка­зать­ся непо­нят­ным, так как мы стро­им за­щи­щен­ную сис­те­му. Од­на­ко под­клю­чения к де­мо­ну Shellinabox всегда бу­дут вы­пол­нять­ся толь­ко Apache че­рез се­те­вую кар­ту сер­ве­ра. Со­единение долж­но быть неза­щи­щен­ным, по­то­му что Shellinabox ис­поль­зу­ет са­мо­под­пи­сан­ный сер­ти­фи­кат, ко­то­ро­му Apache до­ве­рять не бу­дет.

Сле­дую­щий шаг – пе­ре­за­гру­зить де­мон Shellinabox, что­бы он пе­ре­чи­тал кон­фи­гу­ра­цию. Сде­лать это мож­но ко­ман­дой

sudo service shellinabox restart

Shellinabox на­стро­ен – мож­но пе­рей­ти к Apache, и сна­ча­ла на­стро­им его на про­слу­ши­вание за­щи­щен­ных со­единений.

sudo a2ensite default-ssl

sudo a2enmod ssl

sudo service apache2 restart

Ес­ли Apache не ис­поль­зу­ет­ся для пре­достав­ления дру­гих web-сер­ви­сов, мож­но на­стро­ить его так, что­бы он принимал толь­ко за­щи­щен­ные со­единения.

sudo a2dissite default

Так­же от­крой­те файл /etc/apache2/ports.conf в сво­ем лю­би­мом ре­дак­то­ре и из­мените сле­дую­щее:

До:

NameVirtualHost *:80

Listen 80

По­сле:

#NameVirtualHost *:80
#Listen 80

Сле­дую­щий шаг – вклю­чить об­рат­ный про­кси в Apache, что­бы он смог ра­бо­тать с Shellinabox. Это сде­ла­ет ко­ман­да

sudo a2enmod proxy proxy_http

sudo service apache2 restart

Те­перь нуж­но раз­ре­шить доступ к Shellinabox в фай­ле на­строй­ки Apache. На­строй­ки мож­но по­мес­тить в кон­фи­гу­ра­ции вир­ту­аль­но­го хоста или гло­баль­но. Пер­вый под­ход удо­бен в том слу­чае, ес­ли на од­ном и том же ком­пь­ю­те­ре бу­дут на­хо­дить­ся и за­щи­щен­ные, и неза­щи­щен­ные web-сер­ви­сы, но об­рат­ный про­кси бу­дет ра­бо­тать толь­ко с за­щи­щен­ны­ми со­единения­ми. В этом слу­чае нуж­но из­менить файл сай­та SSL по умол­чанию, в Ubuntu это /etc/apache2/sites-enabled/default-ssl. Здесь мы уже от­клю­чили неза­шиф­ро­ван­ный доступ к Apache, по­это­му на­строй­ки безо­пас­но по­мес­тить в гло­баль­ный раз­дел.

От­крой­те файл /etc/apache2/mods-enabled/proxy.conf в лю­би­мом тек­сто­вом ре­дак­то­ре и за­мените его со­дер­жи­мое на сле­дую­щее:

<IfModule mod_proxy.c>

ProxyRequests Off

<Proxy *>

AuthType Basic

AuthName “The computer says no!”

AuthUserFile /etc/apache2/htpasswd.default

Require valid-user

Order allow,deny

Satisfy any

</Proxy>

ProxyPass /siab http://127.0.0.1:4200/

</IfModule>

Ди­рек­ти­ва ProxyRequests оп­ре­де­ля­ет, бу­дет ли Apache вы­сту­пать в ка­че­­ст­ве пря­мо­го web-про­кси. У нас Apache бу­дет толь­ко об­рат­ным про­кси, и ее мож­но безо­пас­но от­клю­чить. Ес­ли вы хо­ти­те по­экс­пе­ри­мен­ти­ро­вать с ней, не вклю­чай­те пря­мой про­кси без ав­то­ри­за­ции, ина­че ваш сер­вер мо­гут момен­тально оби­деть!

Сле­дую­щий раз­дел оп­ре­де­ля­ет то, как пре­достав­ля­ет­ся доступ для за­про­сов про­кси, и в дан­ном слу­чае мы поль­зу­емся ба­зо­вой ау­тен­ти­фи­ка­ци­ей HTTP. Ди­рек­ти­ва AuthName за­да­ет со­об­щение, ко­то­рые уви­дят поль­зо­ва­те­ли, под­клю­чив­шие­ся к сер­ве­ру, и здесь по-на­стоя­ще­му важ­но не по­ка­зы­вать, что на­хо­дит­ся за при­гла­шением о вхо­де в сис­те­му. Со­об­щение «Вход в обо­лоч­ку!! [Login for shell access!!]» – исключительно неудач­ный вы­бор!

Ди­рек­ти­ва AuthUserFile ссы­ла­ет­ся на внешний файл с име­на­ми и па­ро­ля­ми поль­зо­ва­те­лей, имею­щих доступ к фай­лу. Этот файл мы соз­да­дим на сле­дую­щем эта­пе. Ос­таль­ные ди­рек­ти­вы го­во­рят Apache, что для досту­па к сер­ви­су поль­зо­ва­тель дол­жен успеш­но ау­тен­ти­фи­ци­ро­вать­ся.

Те­перь надо соз­дать файл с па­ро­лем, за­дан­ный в пре­ды­ду­щем фай­ле на­строй­ки, с по­мо­щью ути­ли­ты htpasswd, ко­ман­дой

sudo htpasswd -c /etc/apache2/htpasswd.default siab

Ути­ли­та htpasswd соз­даст файл па­ро­лей и по­про­сит вве­сти и под­твер­дить па­роль для но­во­го поль­зо­ва­те­ля – в при­ме­ре вы­ше это поль­зо­ва­тель siab. Имя это­го поль­зо­ва­те­ля долж­но обя­за­тель­но от­ли­чать­ся от имени поль­зо­ва­те­ля, ис­поль­зуе­мо­го для вхо­да на сер­вер (че­рез кон­соль, по SSH и т. д.). Па­роль то­же дол­жен быть до­воль­но на­деж­ным, так как с его по­мо­щью мож­но лег­ко, но эф­фек­тив­но скрыть факт на­ли­чия досту­па к обо­лоч­ке.

Те­перь мы го­то­вы про­ве­рить под­клю­чение к сер­ве­ру, но нуж­но в по­следний раз пе­ре­за­пустить Apache, что­бы он за­гру­зил на­строй­ки об­рат­но­го про­кси:

sudo service apache2

restart

Те­перь мож­но за­пустить брау­зер и от­крыть в нем ад­рес https://SERVER_IP/siab. Сайт SSL по умол­чанию ис­поль­зу­ет са­мо­под­пи­сан­ный сер­ти­фи­кат, по­это­му поя­вит­ся пре­ду­пре­ж­дение, но его мож­но спо­кой­но иг­но­ри­ро­вать. За­тем вам пред­ло­жат вве­сти имя поль­зо­ва­те­ля и па­роль, соз­дан­ные ути­ли­той htpasswd. Дол­жен поя­вить­ся эк­ран вхо­да в сис­те­му Shellinabox, из ко­то­ро­го мож­но вой­ти в сис­те­му с обыч­ны­ми именем поль­зо­ва­те­ля/па­ро­лем обо­лоч­ки.

Те­перь все ра­бо­та­ет, и мож­но спо­кой­но вклю­чить пе­ре­на­прав­ление пор­тов на ро­уте­ре и уда­лен­но под­клю­чить­ся к обо­лоч­ке!


Персональные инструменты
купить
подписаться
Яндекс.Метрика