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

Подписка на печатную версию Весь 2015 год (12 номеров) Первое полугодие (6 номеров) Второе полугодие (6 номеров)

Подписка на электронную версию Весь 2015 год (12 номеров) Первое полугодие (6 номеров) Второе полугодие (6 номеров)

Подшивки старых номеров журнала (печатные версии) Весь 2014 год (12 номеров) Первое полугодие (6 номеров) Второе полугодие (6 номеров)

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

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

Наш эксперт Крис Нот­ли поль­зу­ет­ся 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 лег­ко ин­тег­ри­ру­ет­ся с обыч­ным про­кси, и ме­нять ниче­го не при­дет­ся.

Скорая помощь

Ко­гда у вас бу­дет ра­бо­чий об­рат­ный про­кси, примени­те его для безо­пас­но­го уда­лен­но­го web-дос­ту­па к та­ко­му обо­ру­до­ва­нию, как циф­ро­вые ре­си­ве­ры, сер­ве­ры NAS и т. д.

Еще од­но боль­шое пре­иму­ще­ст­во 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 на этот ад­рес).

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

В об­ра­зе 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.

А ну­жен ли бранд­мау­эр?

В Ubuntu бранд­мау­эр по умол­ча­нию не вклю­чен ни в на­столь­ной, ни в сер­вер­ной вер­сии. Для боль­шин­ст­ва до­маш­них ком­пь­ю­те­ров это ред­ко яв­ля­ет­ся про­бле­мой, так как ши­ро­ко­по­лос­ные ро­уте­ры обыч­но по умол­ча­нию не пе­ре­на­прав­ля­ют вхо­дя­щие со­еди­не­ния к внут­рен­ним ком­пь­ю­те­рам.

Са­мый про­стой и безо­пас­ный спо­соб раз­вер­нуть со­че­та­ние Shellinabox/Apache – пе­ре­на­прав­лять на сер­вер че­рез ро­утер толь­ко за­щи­щен­ные web-за­про­сы (TCP/443). Не­ко­то­рые ши­ро­ко­по­лос­ные ро­уте­ры спо­соб­ны пе­ре­на­пра­вить все вхо­дя­щие со­еди­не­ния на ука­зан­ный внут­рен­ний ком­пь­ю­тер (это час­то на­зы­ва­ет­ся «ре­жим (или хост) де­ми­ли­та­ри­зо­ван­ной зо­ны, DMZ»). Это удоб­но, ес­ли на сер­ве­ре есть на­бор раз­ных сер­ви­сов, од­на­ко в этом слу­чае я на­стоя­тель­но ре­ко­мен­до­вал бы за­пус­тить бранд­мау­эр.

На сер­ве­ре Ubuntu про­ще все­го вос­поль­зо­вать­ся UFW (Uncomplicated Firewall – не­слож­ный бранд­мау­эр). Сле­дую­щий скрипт ак­ти­ви­ру­ет UFW и раз­ре­ша­ет со­еди­не­ния по SSH и за­щи­щен­ные web-соеди­не­ния ото­всю­ду:

sudo ufw enable

sudo ufw allow ssh

sudo ufw allow https

Что­бы поль­зо­вать­ся 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, что для досту­па к сер­ви­су поль­зо­ва­тель дол­жен успеш­но ау­тен­ти­фи­ци­ро­вать­ся.

Скорая помощь

С са­мо­под­пи­сан­ным сер­ти­фи­ка­том вы при­вык­нете иг­но­ри­ро­вать ошиб­ки брау­зе­ра и с мень­шей ве­ро­ят­но­стью об­на­ру­жи­те на­стоя­щую ата­ку. Что­бы это­го из­бе­жать, бес­плат­но за­гру­зи­те сер­ти­фи­кат, ко­то­ро­му до­ве­ря­ют боль­шин­ст­во брау­зе­ров, с сай­та startssl.com.

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

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

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

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

sudo service apache2

restart

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

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

По­сто­ян­ные се­ан­сы обо­лоч­ки

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

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

За­пустить но­вый се­анс Screen очень про­сто – на­бе­ри­те screen, и, на­жав про­бел, что­бы уб­рать ин­фор­ма­ци­он­ное ок­но, вы по­па­де­те в свою обо­лоч­ку по умол­чанию.

Ко­ман­ды в Screen от­прав­ля­ют­ся по на­жа­тию Ctrl + A, а ес­ли за­тем на­жать ?, вы уви­ди­те спи­сок всех команд. Нам наи­бо­лее ин­те­рес­на ко­ман­да от­клю­чения (Ctrl + A, d), ко­то­рая от­клю­чит вас от се­ан­са Screen, оста­вив его ра­бо­тать в фоне. По­втор­но под­клю­чить­ся к это­му се­ан­су мож­но, на­брав screen -r. Ес­ли связь обор­вет­ся и Screen ска­жет, что вы уже под­клю­че­ны к се­ан­су, про­сто на­бе­ри­те screen -d –r, и под­клю­чи­тесь к се­ан­су при­ну­ди­тель­но.

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

|