- Подписка на печатную версию:
- Подписка на электронную версию:
- Подшивки старых номеров журнала (печатные версии)
LXF119:ssh
Материал из Linuxformat.
- Сети Свяжем ваши Linux-ПК, и пускай они вас обслуживают
Содержание |
SSH и VNC: Работа издали
- Часть 6: Нужен доступ к домашнему компьютеру с работы? Нейл Ботвик покажет, как сделать это с SSH и VNC, сохранив все в безопасности.
В предыдущих статьях мы рассмотрели различные способы предоставления доступа к содержимому вашего компьютера, будь то web-страницы или медиа- файлы. Сейчас тема разговора будет несколько другой: как разрешить управление вашим компьютером с другой машины сети или даже через Интернет. Есть несколько причин, по которым у вас может возникнуть такое желание:
- чтобы администрировать web- или почтовый сервер, у которого нет мыши и клавиатуры;
- чтобы получить доступ к файлам или даже запускать программы на компьютере, когда вы находитесь вдали от дома или офиса;
- чтобы помочь кому-нибудь распознать и решить проблему на удаленном компьютере;
- чтобы организовать безопасное соединение по незащищенному каналу связи.
Сделать это можно разными способами, начиная с открытия терминальной сессии на удаленном компьютере и заканчивая полным воспроизведением его рабочего стола на вашем. Многие из этих технологий доказали свою эффективность на практике, а потому не ограничены только одной платформой. Иными словами, значительная часть того, что мы сегодня рассмотрим, позволит вам получить доступ к Windows-системе с Linux-компьютера, и наоборот.
Защитная оболочка
Простейший способ получить доступ к другому компьютеру по сети – это открыть удаленную оболочку. Довольно долго стандартной программой для этого была Rsh, но она небезопасна, потому что все данные, включая имя пользователя и пароль, передаются по сети в открытом виде. Альтернатива, и единственный вариант, используемый сегодня, это SSH (Secure Shell). SSH передает все данные по зашифрованному соединению. Во многих дистрибутивах пакет OpenSSH разделен на две части: клиент и сервер, и по умолчанию часто устанавливается только клиент, поэтому первым делом нужно убедиться, что сервер наличествует и настроен на запуск при загрузке системы. Потом нужно позаботиться о его безопасности. SSH – популярная мишень для взломщиков, потому что, хотя сам протокол безопасен, он использует стандартные методы аутентификации, и если у вас слабый пароль, то вы уязвимы для атаки по словарю. В принципе, все это общие меры по защите компьютера, но прежде чем запускать SSH, нужно дополнительно оградить его от физического доступа.
Для подключения к серверу SSH, выполните команду
ssh hostname
У вас спросят пароль – тот, что связан с вашим именем пользователя на сервере; он может отличаться от пароля того же пользователя на локальном компьютере. Не обязательно входить под одинаковыми именами; можно указать другое с помощью команды
ssh user@hostname
Держим SSH в безопасности
Для повышения защищенности можно кое-что изменить в конфигурационном файле сервера (/etc/ssh/sshd_config). Для начала запретим вход в систему под пользователем root, установив параметр
PermitRootLogin no
Если в удаленной сессии нужно запускать программы от имени суперпользователя- root, можно войти на удаленный компьютер как обычный пользователь, а потом получить права администратора с помощью команды su или sudo. Чтобы налетчик смог это повторить, ему нужно знать имя пользователя, его пароль и пароль root – в три раза больше информации, чем было бы нужно для непосредственного доступа от имени root.
Для ограничения доступа используются и другие директивы: DenyUsers, AllowUsers, DenyGroups и AllowGroups. Их назначение понятно из названия. Каждая из них принимает разделенный пробелами список имен пользователей или групп (не числовых идентификаторов), доступ для которых нужно разрешить или запретить. Директивы обрабатываются в приведенном порядке, до первого совпадения. Если ни одна директива не задана, попытаться войти может любой пользователь. Имена пользователей могут задаваться как просто имена или в виде user@host, тогда проверяются и имя пользователя, и хост. Учтите, имя пользователя сравнивается с именем пользователя, под которым вы входите в систему, а хост сравнивается с именем удаленного компьютера, с которого вы пытаетесь зарегистрироваться. Это позволяет разрешить доступ только с определенных компьютеров: скажем, заходить на домашний ПК с работы. Можно применять шаблоны: например, директива
AllowUsers jim@*.mywork.ru
позволит входить в систему под пользователем jim с любого компьютера в сети на работе. Эти директивы разрешают или запрещают только попытки входа, без пароля вам все равно не обойтись…
Храните копии ваших закрытых ключей в надежном месте подальше от компьютера. В противном случае при их утрате или повреждении вы, возможно, не сможете зайти в систему.
Если только вы не задали вход в систему без пароля! Да почему же, после стольких лекций по безопасности? Потому что на самом деле это безопаснее. Сложность пароля ограничена – ведь вы должны его помнить, а файл ключа может быть больше и иметь в миллиарды раз больше перестановок, чем пароль. Для начала создайте пару файлов ключей с помощью команды
ssh-keygen
У вас запросят парольную фразу. Она может быть пустой (тогда для входа достаточно просто иметь закрытый ключ), но для повышения безопасности можно задать и ее. Беспарольные ключи больше подходят для автоматизированных систем, но они довольно удобны и в остальных случаях. Теперь в каталоге ~/.ssh есть два файла: id_rsa (или id_dsa, если вы указали ssh-keygen создать ключ DSA) и id_rsa_pub. Первый файл – это закрытый ключ, и его нужно хранить в безопасном месте, а второй – открытый, его нужно добавить в файл ~/.ssh/authorized_keys на удаленном компьютере. Файл можно скопировать на флэшку, вставить ее в удаленный компьютер и добавить с помощью команды
cat id_rsa.pub >>~/.ssh/authorized_keys
или, если у вас еще включен удаленный вход по паролю, передайте его по сети командой
cat ~/.ssh.id_rsa.pub | ssh remote.computer tee -a ~/.ssh/authorized_keys
Теперь разрешите аутентификацию по ключу, установив параметр
PubkeyAuthentication yes
в файле /etc/ssh/ssh_config на удаленном компьютере, и перезапустите сервис SSH.
Как показано выше, вход в систему с паролем можно отключить совсем, требуя обязательного использования ключа (возможно, в сочетании с парольной фразой) – добавкой в файл sshd_config следующих строк:
PasswordAuthentication no
Обычно ключ хранится в каталоге ~/.ssh, и это хорошо, если вы подключаетесь со своего компьютера. Чтобы подключаться откуда угодно, закрытый ключ можно записать на флэшку и указать SSH, где его искать, опцией -i.
ssh -i /media/usbstick/id_rsa
В этом случае ключ нужно защитить с помощью парольной фразы, иначе потеря USB- брелка будет равносильна потере ключа от дома. Если вы хотите использовать парольную фразу только когда заходите извне, и не напрягаться с ней при работе на собственном компьютере, то для флэшки нужно создать собственную пару ключей.
Весь этот разговор о перезапуске службы может вызвать у вас вопрос: «А что будет, если я испорчу конфигурационный файл на удаленном компьютере и перезапущу службу?». Ну, плохая новость – вы не сможете войти до тех пор, пока не поправите его. А хорошая новость – существующие соединения не затрагиваются перезапуском. Так что, изменив конфигурационный файл и перезапустив sshd, не закрывайте текущую сессию и попробуйте открыть новую с другого терминала. Если сделать это не получится, у вас остается открытая сессия, в которой можно исправить ошибки.
SSH для Windows
Все эти разговоры о доступе к компьютеру извне предполагали, что «снаружи» установлен Linux (или некий вариант Unix). Как вы могли заметить, на многих компьютерах стоит эта странная проприетарная система по имени Windows. Не волнуйтесь, клиент SSH для Windows существует и даже не нуждается в установке. Он называется Putty, и запустить его можно прямо с USB-брелка. Зайдите на сайт http://www.chiark.greenend.org.uk/~sgtatham/putty, скачайте файл putty.zip и распакуйте его на флэшку. Там будет несколько файлов; из них нам интереснее всего putty.exe, SSH-клиент. Запустите его, введите имя хоста или IP-адрес сервера, и он должен запросить пароль для входа. Единственная хитрость здесь – когда имя пользователя не совпадает с именем пользователя на сервере, просто добавьте его к названию хоста, как обычно (user@hostname). Putty умеет работать с ключами, но в другом формате. Чтобы преобразовать в этот формат ключ OpenSSH, запустите Puttygen, импортируйте ключ RSA или DSA из SSH и сохраните секретный ключ там же, где находится Putty. Теперь ключ можно выбрать в меню SSH > Auth в основном окне Putty. Вам понадобится сделать это только для закрытого ключа, потому что открытый ключ, который вы уже добавили в файл authorized_keys, работает с OpenSSH и Putty. Приведенная выше рекомендация по использованию парольной фразыс любым переносимым ключом здесь также применима.
Прочь, малолетние хакеры!
Не используйте беспарольные ключи на ноутбуках или в любом другом мобильном носителе, если они не хранятся в зашифрованной файловой системе. Если это устройство украдут или вы забудете его в поезде, под угрозой окажется вся сеть.
Один из недостатков сервера SSH, открытого для входа через Интернет, в том, что это популярная мишень для атак «грубой силы». Пока у вас сильные пароли и запрещен вход в систему от имени root (или он происходит по ключу), вы находитесь в сравнительной безопасности. Впрочем, когда файлы журналов полны сообщений о неудавшихся попытках входа по SSH, иногда до нескольких тысяч в день, это раздражает. Есть пара способов, которые помогут избавиться от этого. Один из них – это запуск сервера на порте, отличном от стандартно атакуемого 22. Потом порт 22 можно закрыть на маршрутизаторе, и все попытки доступа к SSH будут бесплодны. В файле sshd_config установите следующий параметр:
Port 54321
и подключитесь по SSH командой:
ssh -p 54321 user@hostname
Также можно определить порты по умолчанию для каждого из хостов в файле /etc/ssh/ssh_config:
Host hostname Port 54321
Все, что следует за строкой Host до следующей строки Host, применяется только к этому хосту. Добавление приведенных строк в конце файла заставит клиентов подключаться к данному конкретному хосту через порт 54321.
Также можно запустить программу просмотра системного журнала на предмет повторяющихся неудачных попыток входа по SSH и добавить адрес источника в правила брандмауэра, застопорив все дальнейшие соединения с этого адреса на заданное вревремя. Одна из делающих это программ – Denyhosts (http://www.denyhosts.net); другая – Sshutout (http://www.techfinesse.com/sshutout/sshutout.html). Пакеты Sshutout существуют для большинства дистрибутивов; установите его и отредактируйте файл /etc/sshutout.conf в соответствии со своими настройками. Для начала можете сменить только местоположение журнала, оставив остальные параметры в покое. После настройки запуска программы при загрузке системы, повторные попытки регистрации будут автоматически заблокированы.
Как насчет моего GUI?
SSH хорош для терминальных сессий, но что делать, если вы хотите получить доступ к GUI удаленного компьютера? Есть пара способов сделать это, и один из них – снова SSH. Нужно разрешить X-проброс (X forwarding) в файле sshd_config:
X11Forwarding yes
Потом запустите сеанс SSH с ключом -X:
ssh -X user@host
Теперь вы увидите… а все то же: вы по-прежнему в терминале. Разница в том, что теперь из него можно запускать графические программы. Попробуйте запустить любое X-приложение, и его окно раскроется на вашем локальном рабочем столе. Программа по- прежнему выполняется на удаленном компьютере, но использует локальный монитор. Опция -Y вместо -X иногда ускоряет отклик.
Или всего рабочего стола?
X-проброс прекрасно работает, если на удаленном компьютере стоит Linux и вы запускаете только одно приложение. Если хотя бы одно из этих условий не верно, лучше попробовать VNC (Virtual Network Computing). VNC открывает в окне на вашем компьютере весь рабочий стол удаленной машины, и это кроссплатформенная технология, так что на компьютере с VNC может стоять Windows или MacOS. Существуют два варианта VNC: оригинальный с http://www.realvnc.com и TightVNC c http://www.tightvnc.com. TightVNC изначально разрабатывался ради большей производительности на более медленных соединениях, отсюда и название, но обладает и дополнительными возможностями. Обе программы используют стандарт VNC, и вы можете брать любую, включенную в состав вашего дистрибутива. Однако для получения дополнительных возможностей TightVNC ее надо использовать и на клиенте, и на сервере.
Ни одну из версий VNC настраивать не надо – просто установите ее и запускайте при загрузке системы. При первом старте у вас спросят пароль, и после этого все будет готово к использованию. Однако следует убедиться, что брандмауэр не блокирует трафик VNC, поэтому откройте порт 5900 или разрешите удаленный рабочий стол (Remote Desktop) в настройках брандмауэра Windows на вкладке Exceptions [Исключения].
В KDE имеется встроенная поддержка VNC и для сервера, и для клиента. Сервер настраивается в разделе Desktop Sharing [Разделение рабочего стола] в Control Center > System Settings [Центр управления > Параметры системы], а клиент скрывается в пункте меню Remote Desktop [Удаленный рабочий стол] раздела Internet [Интернет] меню KDE. В KDE в конец адреса нужно добавлять :0, для указания, что вы хотите подключиться к первому рабочему столу (родной VNC Viewer обрабатывает это автоматически).
VNC предоставляет большую гибкость, поскольку работает так, как будто вы сидите за компьютером. Он удобен для удаленной диагностики проблем с чужой машиной, хотя основной совет по безопасности справедлив и здесь: не открывайте порты в Интернет, не имея сильные пароли. Вам также потребуется настроить маршрутизатор на перенаправление порта VNC, обычно это 5900, на ваш компьютер.
VNC – отличная штука, когда ваша мама звонит по поводу проблемы на ее компьютере, потому что гораздо проще найти и решить проблемы, когда вы можете попробовать все сами. Но если VNC не установлен, а правила перенаправления маршрутизатора нужно настроить, то как получить к нему удаленный доступ, чтобы это сделать? Есть несколько онлайн-сервисов, позволяющих установить удаленный доступ просто после заполнения web-формы. Обычно они работают медленнее, чем VNC или TightVNC, и лично меня малость нервирует передача информации через третьих лиц, но могут обеспечить соединение, достаточно долгое для установки одного из вариантов VNC и прямого соединения. Я пользовался одним из таких сервисов – LogMeIn на сайте http://www.logmein.com.
Для удаленных рабочих столов есть еще один вариант: NX с сайта http://www.nomachine.com. Это несвободный клиент, использующий VNC и протокол компании NX. Хотя это не открытый проект (впрочем, свободно распространяемая версия клиента доступна на сайте http://freenx.berlios.de), зато самый быстрый вариант для медленных интернет-соединений.
Передача файлов
SSH поддерживает не только терминальные сессии, но и передачу файлов. Команда scp очень похожа на обычную cp. Отличие в том, что источник или получатель должен содержать имя хоста, например:
scp -p root@host:/var/log/mail.log scp -pr somedir hostname:
Первая команда загружает файл mail.log с удаленного компьютера. Вторая копирует каталог целиком в домашний каталог пользователя на другом компьютере. Традиционный способ передачи файлов – FTP, но он небезопасен, потому что пароли и данные передаются в незашифрованном виде. OpenSSH включает сервер SFTP (SecureFTP), обычно запускаемый по умолчанию. Большинство FTP-клиентов, как и многие файловые менеджеры, сейчас поддерживают SFTP. Попробуйте соединиться с sftp://user@hostname, чтобы просмотреть домашний каталог пользователя. SFTP и scp используют такой же способ аутентификации, как SSH, а если вы настроите ключи, они тоже будут работать.
Пока что мы узнали, как с помощью SSH настроить безопасный удаленный терминал или удаленно запускать X-приложения, но у него в запасе есть еще кое-что (на самом деле, много чего; на все и места не хватит) – канал SSH можно использовать как туннель для другого соединения, даже если это другое соединение передает данные в открытом виде. Поскольку данные проходят через шифрованный канал, они защищены от посторонних глаз. Это особенно удобно при пользовании беспроводным соединением, защищенным только WEP-шифрованием.
Установить SSH-туннель можно так:
ssh -f -N -L 4321:home.network.com:25 user@home.network.com
Опция -f запускает SSH в фоновом режиме, а -N указывает, что не требуется выполнять команды. Перенаправление обрабатывается опцией -L, принимающей 3 параметра: первый – номер локального порта (который должен быть как минимум 1024, если вы не root), второй – имя сервера для перенаправления, и третий – номер порта на этом сервере. В конце указываются имя пользователя и хоста удаленного компьютера, который будет выполнять перенаправление. Учтите, что имя хоста в середине опции -L разрешается на удаленном сервере, и здесь можно было бы использовать localhost, но это потенциальная путаница. Результат выполнения команды будет таким, как если бы вы указали почтовой программе использовать localhost на порте 4321 как SMTP сервер, который будет перенаправлен через безопасный канал на порт 25 (стандартный порт для SMTP) на home.network.com.
Хотите – перенаправьте трафик на другой сервер, хотя данные будут шифроваться только на первом участке маршрута (до SSH-сервера). Этим можно воспользоваться, если ваш брандмауэр или прокси-сервер запрещает подключение к конкретному хосту или порту. Например, следующая команда позволит подключиться к Googletalk настройкой вашего IM-клиента на использование localhost и порта 5432:
ssh -f -N -L 5432:talk.google.com:5222 user@home.network.com
Если вы примените это, чтобы обойти ограничения в корпоративной сети, вы сами и отвечаете за все последствия.
SSH умеет делать больше, и все через защищенные, аутентифицированные соединения. Например, можно запустить сеанс SSH, затем сессию Screen и программы в ней. Потом можно выйти из обеих сессий и переподключиться с другого компьютера, чтобы убедиться, что программы все еще выполняются. Есть еще масса неизведанного – чего же вы ждете? LXF
