(Посвещавам този запис на всички любители на подслушването. 🙂 )
От Windows XP насам споделянето на екран е популярна опция. Но не съвсем безопасна – твърде лесно е стриймът данни да бъде подслушан, и някой да разглежда какво правите отдалечено. Надали е желана опция. Особено пък ако си запише паролата, и се включи по някое време и активно…
По-предпазливите хора ползват програми като VNC, които позволяват някаква степен на шифроване на пренасяната информация. За съжаление тя е недостатъчна – атака тип “груба сила” може лесно да отгатне по подслушания стрийм паролата. Пак надали е желана опция.
Различните UNIX системи, включително Линукс, имат доста сериозни инструменти за подобна задача, вградени направо в основния софтуер. Работата с тях не е трудна дори за начинаещи, а дават великолепно ниво на сигурност. Затова е полезно да се познават. Искат мъничко работа на командния ред, но както често е под Линукс, простичка и лесна.
И така, имате локален компютър и отдалечен компютър. И двата, за ваше щастие, с Линукс. Бихте искали да посвършите малко работа на отдалечения, но така, че злонамерени любопитници по линията да не могат да научат какво вършите. Какво ще направите?
Графичната среда на Линукс, така наречената X11, е предвидена за тази задача. Тя дава възможност да стартирате програма на отдалечения компютър, а да виждате нейния прозорец, и да можете да работите с него, на локалния. А програмата за шифрована връзка SSH използва тази й възможност, и пренася обмена на информация между двата компютъра през тежко шифрован канал. Съчетанието от двете ви дава възможност да си свършите работата при сигурност далеч над тази на коя да е друга програма за отдалечена връзка. И двете са стандартна част от всяка Линукс дистрибуция, която има графична среда.
Ако отдалеченият компютър не е подготвен за такава връзка, се налага първо да го подготвите. Свържете се с SSH към него, вземете root права, и отворете за редактиране файла /etc/ssh/sshd_config. Някъде вътре ще намерите следния ред:
X11Forwarding no
Сменете “no” с “yes“. Запишете файла и рестартирайте SSH сървъра на отдалечения компютър. (Това няма да прекъсне връзката ви.) Ако случайно там вече е записано “yes“, тази процедура отпада.
След това просто стартирайте нужната ви програма на отдалечения компютър. (Например за OpenOffice.org Writer стартирайте oowriter, за Calc – oocalc, и т.н.) Прозорецът на програмата ще изскочи на локалния компютър, и ще можете да работите с него, все едно седите на отдалечения компютър.
(Дребен трик: Ако искате да стартирате повече от една програма, добавяйте пауза и амперсанд след името на всяка стартирана – например “oowriter &“. Така SSH няма да изчака програмата да свърши, а ще ви върне контрола веднага.)
Понякога е по-удобно да виждаш целия екран на отдалечения компютър. За тази цел чудесна работа върши комбинацията от VNC сървър/клиент и X11 среда (и разбира се, SSH шифрован тунел).
Като първа стъпка, инсталирайте на локалния компютър някакъв VNC клиент. Изпробван е и добре работи с описаната по-долу процедура TightVNC. Пакетът му в Дебиан се нарича xtightvncviewer, и се инсталира (през root акаунт) лесно:
aptitude install xtightvncviewer
След това, когато се свържете през SSH с отдалечения компютър и го подготвите за връзка, инсталирайте на него и сървърната програмка X11VNC. Пакетът й в Дебиан се нарича x11vnc, и се инсталира, както се сещате:
aptitude install x11vnc
След това спокойно можете да излезете от SSH връзката – не ви е нужна вече. 🙂
Когато решите да се свържете към отдалечения екран, трябва първо да стартирате на отдалечената машина X11VNC. За целта не е нужно дори да се логвате там – достатъчно е да напишете на локалната си машина следната команда:
ssh -t -L 5900:localhost:5900 [user@]host 'x11vnc -localhost -display :0'
където [user@]host са името или IP адресът на отдалечената машина, и евентуално потребителят, като който ще се свържете. Например
ssh -t -L 5900:localhost:5900 gatchev.info 'x11vnc -localhost -display :0'
или
ssh -t -L 5900:localhost:5900 grigor@grigor.gatchev.info 'x11vnc -localhost -display :0'
В типичния случай ще видите въпрос за паролата на съответния потребител. Въвеждате я, и готово. Конзолата, в която работите, ще остане блокирана, докато не привършите работа – за да продължите, отворете нова конзола.
(Много сложно ли изглежда въвеждането на подобни команди? Използвайте великата хакерска хватка Copy&Paste. По-опитните дори могат да си направят елементарно скриптче с този ред – ако някой има нужда от инструкции как става, пишете ми – и само да цъкват на него в графичната среда. А още по-опитните могат да погледнат ръководството на x11vnc, и ще открият, че там има опции как да го направиш да е стартирано постоянно, и да няма нужда от тази еквилибристика.)
След като стартирате на отдалечената машина сървъра, трябва да стартирате на локалната машина VNC клиента. Това става със следния команден ред:
vncviewer -encodings 'copyrect tight zrle hextile' localhost:0
Може да ви се скара, че не поддържа един или друг енкодинг, но ще работи. Voila! 🙂
Допълнителни дребни трикове:
Не е трудно да обедините двете скриптчета в едно, на което просто да цъквате във файловия мениджър, и на екрана да изскача отдалечената машина. Впечатляващо е за пред не толкова компютърни колеги. 😉 Скриптчето трябва да изглежда примерно така:
ssh -t -L 5900:localhost:5900 grigor@grigor.gatchev.info 'x11vnc -localhost -display :0' &
vncviewer -encodings 'copyrect tight zrle hextile' localhost:0
Забележете амперсанда след първата команда. Без него скриптът ще чака при отварянето на сървъра, и няма да пусне клиента. Той обаче създава и един дребен проблем – SSH няма да може да ви попита за паролата на потребителя, и сесията няма да се осъществи.
За да го избегнете, ще трябва да си направите логване без парола. (Много удобно нещо е.) Намерете в потребителската си директория на локалната машина поддиректорията “.ssh” (забележете точката в началото). Тази директория е скрита – може да се наложи да включите показването на скрити файлове, за да я видите.
В нея ще намерите няколко файла. Един от тях се нарича id_rsa.pub и съдържа един дълъг ред със странни символи – ключът за връзка, който използва вашият SSH. Откопирайте този файл (като tempfile.pub) на отдалечената машина, например с scp, която е част от пакета SSH:
scp ~/.ssh/id_rsa.pub [user@]host:.ssh/tempfile.pub
(Не забравяйте вместо [user@]host да впишете подходящите хост и евентуално потребител.)
След това се свържете през SSH с отдалечената машина, и влезте в директорията “.ssh” на тамошния потребител. Потърсете там файл на име authorized_keys. Ако няма такъв, просто прекръстете tempfile.pub с това име:
mv tempfile.pub authorized_keys
Ако го има, добавете съдържанието на tempfile.pub към него:
cat tempfile.pub >> authorized_keys
и изтрийте tempfile.pub.
От този момент нататък вашият потребител на локалната машина ще може да се свързва като използвания от вас потребител на отдалечената машина, без да се налага да въвежда парола. 🙂
Ако идеята за команден ред ви плаши, се засрамете. Щом сте се доцъкали до този блог и запис, значи няма да имате никакъв проблем да се справите по толкова подробно описание. Пробвайте се! Ако не успеете, в Линукс общността има достатъчно свестни хора, за да ви помогнат с удоволствие.
Приятна отдалечена работа! 🙂
Хубав текст, поучителен :). Само да изгладим една неточност: remote desktop при Windows има опция “Remote Desktop with Network Level Authentication” (по подразбиране – включена!). Сравка: Wikipedia!
В този смисъл, от Windows Server 2003 споделянето на екрани си е безопасно. Поне дотолкова безопасно, колкото и с SSH encryption.
Да добавя (като човек, който е гледал демонстрация на man-in-the-middle атака с/у Майкрософтския RDP 5.2 в ХР) – не е достатъчна “паролата”, трябва да прихванеш обмяната на ключове, и поне тогава не работеше в реално време, т.е. трябва да запишеш трафика и след това да го “гледаш”.
Както и да е, абсолютно непрофесионално е да не се използва rdp6, дори и с ХР..
@Дончо: Server 2003 е сериозно нещо. Има ми уважението.
@Сашо: Паролата е разбиваема с възможно количество brute force. Имаш ли я, обмяната на ключове е разгадаема. Оттам нататък, при следващото свързване просто гледаш (или участваш)… В шестицата, признавам, нещата са други.
този начин го ползвах с голям успех преди да се появи shadow в nomachine
просто пощата, rss четеца, icq, skype и тн са ми в къши и ми е по-удобно да си ги ползвам от там вместо от там където се намирам ако не съм в къщи
ако се ползва windows към x11vnc има един проект за enhanced vnc viewer който предлага всичко накуп откъм клиентската част
@Григор:
Доколкото знам, Remote Desktop при WinXP Pro SP3 е не по-малко сигурен от този на Windows Server 2003. Може и да греша, но така съм чувал от по-добри специалисти от мен. И връзката е криптирана, също, при това съвсем на ниво.
Remote Desktop 6.x е наличен за WinXP SP2/3:
http://www.microsoft.com/downloads/details.aspx?FamilyId=26F11F0C-0D18-4306-ABCF-D4F18C8F5DF9&displaylang=en
За brute force атаките, смятам, че една достатъчно дълга и сложна парола е напълно достатъчна да бъде предотвратена такава атака. Плюс това, всеизвестен факт е, че в наши дни няма никакъв проблем да ползваш ключ/парола, които да изискват една атака да продължи 5 x 10 на 30-40 степен години, при това ползвайки high-end хардуер… Надали си струва, за да се занимаваш само с един remote desktop… Все пак, вероятно е Вселената да спре да съществува, преди да си намерил ключа, де…
Аз исках да допълня Григор относно споделянето на X сесиите. Освен пускането на отдалечени програми към локалния X сървър, може локалния да пусне сесия на отдалечена машина. Преди време така си работех от локалната машина с Дебиан към Солариса, на който трябваше да се върши работа. За съжаление съм забравил точно какви параметри се подаваха на X – бях си запомнил някъде цялата команда. GDM също може да се настрои да може потребителя да си пуска отдалечени сесии, но по подразбиране естествено е забранено. Естествено, трафика е добре да минава през ssh тунел.
Уфф, с цялата тази несвързана купчина думи се опитвам да кажа, че освен VNC, има и native начин за отдалечени сесии в X.
@Гонзо
“Уфф, с цялата тази несвързана купчина думи се опитвам да кажа, че освен VNC, има и native начин за отдалечени сесии в X.”
1) бавно е
2) мисля че в случая ставаше дума за ползване на текущия работещ X иначе ще се полва vnc сървър
не мога да разбера защо всеки линухар пишещ статия с инструкции как нещо да бъде направено под линукс се чуства длъжен да започне статията си с оплювка (понякога основателна, по-често не) колко смотано е направено това под виндовс.
не съм виждал статии с инструкции за виндовс, обясняващи колко по-добре е реализирано това или онова отколкото в линукс.
Разгледай командата ssh-copy-id, полезна е за разпространение на ключове.
@Michel: Въпрос на протокол е. На RDP 5.x трябва да напишеш ега ти паролата, за да е сигурна срещу brute force атака (има методи, които сериозно съкращават пробването на всички възможни комбинации, но няма да се разпростирам сега). Още повече че съм подочувал, че има и прилично бързи криптоаналитични способи за разбиването му… RDP 6 не съм го разглеждал, но съм чувал от приятели, че шифровката му е доста по-прилична. А и целта на статията е не да покаже колко е зян Уиндоус, пък колко добре Линукс, а как да си свърши човек под Линукс работата. (XP го споменавам само като отправна дата за масовото навлизане на remote desktop; самият тип връзка, както и протоколът VNC, ги има под всяка уважаваща се платформа.)
@~!@#$%^&*()_+: Че напиши, де.
@Христо Еринин: Чукча простичък, простичко обяснява 🙂
когато опитах да стартирам нещо на отдалечената машина ми дава “Error: no display specified”
От скоро използвам NX Server на nomachine – работи безотакзно, за Linux-Linux десктоп – работи изключително и само върху SSL тунел
@Mike: Провери дали си откопирал цялата команда точно (и особено ” display :0″ частта накрая). Най-често този проблем е от това. 🙂 Ако то е наред, са възможни следните причини:
– Нямаш X среда на някоя от двете машини. 🙂
– Ако пускаш Firefox / Iceweasel, той е малко шантав при такава комбинация. Случвало се е да откаже и да изплюе точно тази грешка (не се стартира на която машина трябва).
– Ако работиш под Fedora, а и някои други дистрота (било на локалната, било на отдалечената машина), е възможно дисплеят ти да не е 0. Възможно е и да е променен ръчно, по една или друга причина. Провери какво има в променливата DISPLAY и на двете машини, и промени командата съобразно (първата – според отдалечената, втората – според локалната).
@Сви: Наистина е много добър (аз не съм го пробвал, но познати твърдят така). В записа исках да покажа как се прави с максимално стандартни средства. 🙂
@григор
какво да напиша? статия за виндовс, която да започва с плювни по линукс?
не благодаря, не съм линухар.
ох, не е за моя мозък тази статия. много обичам да чета от време на време писанията в блога на Григор, но за съжаление, съм компютърен инвалид. сигурна съм, че пише нещо важно и интересно, но какво да се прави – в случая с мен, все едно статията се е блъснала в стена. случват се и такива катастрофи 🙂
@~!@#$%^&*()_+: Чукча не писател, чукча критик?
@мече през борда: Важното е да не му се боиш. Останалото става някак. 🙂
@григор
що ти колко критици познаваш дето да са писатели?
или викаш, те са чукчи 🙂
Единият май е. Или по-точно е трол.
Всякакво RDP с нивото сигурност SSH2 е много лесно достижима при Уиндоус.
(Достатъчно е човек да има права на отдалчения Уиндоус да инсталира софтуер, което очевидно се предполага в контекста, описан от Григор.)
1) Инсталирте SSH-сървър на отдалечения Уиндоус.
Много лек и супер-лесен за инсталация е copSSH – безплатен OpenSSH сървър за Уиндоус. Работи перфектно на Win XP (всички SP), Vista всички разновидности (32 и 64 бит).
2) На “повикващия” Уиндоус слагате Putty SSH (или който искаш друг ssh-клиент) и го конфигурирате да пренасочва повикванията за порт 3390 (RDP) до порт 22 (SSH) на отдалечения компютър (супер подробно описано тук: http://www.engfers.com/2008/08/21/how-to-use-http_radio_anything-behind-a-proxy-or-firewall )
3) оа повикващия компютър стартирате първо SSH до отдалечения компютър, след това правите RDP до localhost:3390
Това не само криптира RDP-то, но и позволява човек да прави RDP иззад корпоративен firewall, който позволява 22 навън, но не позволява 3390 (доста “стандартна” комбинация).
За още по-голяма сигурност, разбира се, SSH аутентикацията може да бъде направена с public/private key вместо с парола.
@Красимир Гаджоков: Под Уиндоус има и немалко комерсиални софтуери, които поддържат шифровка чрез SSH2, и имат доста опции. Много съм доволен от RAdmin (клиентското приложение дори е безплатно). А RDP6 като цяло няма нужда от допълнително криптиране. 🙂
@Григор: е, аз нарочно посочих решение само с безплатен софтуер, иначе някой веднага щеше да ревне “видяхте ли, за Уиндоус трябва да се плаща!” 🙂
@Красимир Гаджоков: Спокойно. Щом сме в България, каквото и както и да направиш, ще има кой да критикува.
За щастие, срещу това има лек. Каниш критика да свърши нещо, и той мигом се проваля вдън земя… 🙂
и като сме го подкарали да спомена и neatx – работи идеално