Установка и конфигурирование SSH-сервера
Идея удаленного доступа не совсем понятна обычному человеку, но мы же не обычные и нам интересно узнать еще одну фишку, столь важную для администратора. Понятно, что удаленный доступ необходим серверу, администрировать который иногда бывает нужно из любой точки планеты, тогда следующий вопрос — зачем удаленный доступ к домашнему/офисному компьютеру, который отключается даже на ночь? Во-первых, удаленный доступ, как я уже писал — это интересно. Ну вот скажите, разве нет какой-то «магии», когда с другого компьютера получаешь доступ к своему? Во-вторых, настроить удаленный доступ полезно в общеобразовательных целях. Ведь никто не знает, что будет завтра — вдруг кому-то из нас предложат высокооплачиваемую должность администратора Linux-системы, и мы просто не сможем отказаться, при виде размера заработной платы?
Для организации удаленного соединения мы будем использовать протокол SSH, позволяющий получить доступ к консоли сервера. Именно это нам и нужно, если мы подключаемся по медленному каналу (модем, мобильный телефон), для передачи текста этого хватит. Хотя, сейчас разве, что можно встретить 3G, EDGE, Wi-Fi, Wi-max сети, но от этого суть не меняется, просто нужен доступ в сеть.
Протокол SSH
Раньше для организации удаленного доступа к консоли сервера использовался протокол telnet. В каждой сетевой операционной системе — будь то FreeBSD или Windows 95 (которую, впрочем, сложно назвать сетевой) — есть telnet-клиент. Данная программа так и называется — telnet (в Windows — telnet.exe).
После подключения с помощью telnet к удаленному компьютеру вы можете работать с ним, как обычно. В окне telnet-клиента вы увидите как бы консоль удаленного компьютера — вы будете вводить команды и получать результат их выполнения — все так. если бы вы работали непосредственно за удаленным компьютером.
Но технологии не стоят на месте, и протокол telnet устарел. Сейчас им практически никто не пользуется. На его смену пришел протокол SSH (Secure Shell). SSH, как видно из названия, представляет собой безопасную оболочку. Главное отличие от telnet состоит в том, что все данные (включая пароли доступа к удаленному компьютеру, передаваемые по SSH файлы) передаются в зашифрованном виде. Во времена telnet участились случаи перехвата паролей и другой важной информации, что и стало причиной создания SSH.
SSH использует следующие алгоритмы для шифрования передаваемых данных: BIowFish, 3DES (Data Encryption Standard), IDEA (International Data Encryption Algorithm) и RSA (Rivest—Shamir—Adelman algorithm). Самыми надежными являются алгоритмы IDEA и RSA. Поэтому если вы передаете действительно конфиденциальные данные, лучше использовать один из этих алгоритмов.
Для установки SSH-клиента (программы, которая подключается к SSH-cерверу) и самого SSH-сервера нужно установить пакеты openssh—client и openssh—server. Данная разновидность SSH-сервера называется OpenSSH. Если вам нужен традиционный сервер SSH, тогда вам следует установить пакет ssh, содержащий и клиента, и сервер.
Если у вас на рабочей станции установлена Windows и вам нужно подключиться к SSH-серверу, запущенному на Linux-машине, то используя Yandex или Google можно скачать бесплатный SSH/telnet-клиент PuTTY. А лучше сразу заглянуть на сайт русского сообщества — putty.org.ru, где есть что скачать и почитать.
Работать с SSH-клиентом очень просто. Для подключения к удаленному компьютеру введите команду:
ssh [опции] <адрес_удаленного_компьютера>
В качестве адреса можно указать как IP-адрес, так и доменное имя компьютера.
Опции программы SSH
- -с blowfish|3des|des — служит для выбора алгоритма шифрования, при условии, что используется первая версия протокола SSH (об этом позже). Можно указать blowfish, des или 3des.
- -с <шифр> — задает список шифров, разделенных запятыми в порядке предпочтения. Опция используется для второй версии SSH. Можно указать blowfish, twofish, arcfour, cast, des и 3des.
- -f — переводит ssh в фоновый режим после аутентификации пользователя. Рекомендуется использовать для запуска программы Х11. Например: ssh -f server xterm.
- -l <имя_пользователя> — указывает пользователя, от имени которого нужно зарегистрироваться на удаленном компьютере. Опцию использовать необязательно, поскольку удаленный компьютер и так запросит имя пользователя и пароль.
- -р порт — определяет порт SSH-cepвepa (по умолчанию используется порт 22).
- -q — тихий режим. Будут отображаться только сообщения о фатальных ошибках. Все прочие предупреждающие сообщения в стандартный выходной поток выводиться не будут.
- -х — отключает перенаправление Х11.
- -X — задействовать перенаправление Х11. Полезна при запуске Х11-программ.
- -1 — использовать только первую версию протокола SSH.
- -2 — использовать только вторую версию протокола SSH. Вторая версия протокола более безопасна, поэтому при настройке SSH-сервера (см. далее) нужно использовать именно ее.
Конфигурация SSH-сервера
Теперь можно приступить к конфигурированию SSH-сервера. Если используется OpenSSH (в большинстве случаев так оно и есть), все настройки SSH-сервера хранятся в одном-единственном файле — /etc/ssh/sshd_config, а настройки программы-клиента — в файле /etc/ssh/ssh_config. Настройки программы-клиента обычно задавать не нужно, поскольку они приемлемы по умолчанию. На всякий случай можно заглянуть в файл /etc/ssh/ssh_config — его формат, как и назначение опций (большая часть из них закомментирована), можно понять и без комментариев.
В данный момент нас больше интересует файл sshd_config, содержащий конфигурацию SSH-сервера. Рассмотрим пример файла конфигурации SSH-сервера. Все комментарии на русском, поэтому будет легко понимать назначение директив.
# Package generated configuration file # See the sshd_config(5) manpage for details # Задает порт, на котором будет работать SSH-сервер. # Если директива не указана (закомментирована), то по # умолчанию используется порт 22 Port 22 # Локальный адрес, который должен прослушиваться SSH-сервером #ListenAddress 0.0.0.0 # Директива Protocol, которая позволяет выбрать версию протокола, # рекомендуется использовать 2 версию Protocol 2 # Ключевые файлы для 2 версии протокола SSH HostKey /etc/ssh/ssh_host_rsa_key HostKey /etc/ssh/ssh_host_dsa_key #Privilege Separation is turned on for security UsePrivilegeSeparation yes # Время жизни ключа протокола первой версии. Время можно # задавать в секундах или в часах (постфикс h, например, # 1h — это 1 час или З600 секунд). По истечении указанного # времени ключевой файл будет сгенерирован заново KeyRegenerationInterval 3600 # Разрядность ключа сервера в битах (только для 1 версии протокола SSH) ServerKeyBits 768 # Директивы управления протоколированием SyslogFacility AUTH LogLevel INFO # Директивы аутентификации. Время, предоставляемое клиенту для # аутентификации. Задается в секундах или минутах. Если за это # время клиент не аутентифицировал себя, соединение будет прекращено LoginGraceTime 120 # Директива разрешает (yes) удаленный доступ пользователя root PermitRootLogin yes StrictModes yes # Использование RSA (yes) RSAAuthentication yes # Аутентификация с открытым ключом (если указано yes) PubkeyAuthentication yes #AuthorizedKeysFile %h/.ssh/authorized_keys # Don't read the user's ~/.rhosts and ~/.shosts files IgnoreRhosts yes # Использование rhosts-аутентификации с поддержкой RSA, # rhosts-аутентификацию использовать не рекомендуется, поэтому по # умолчанию для этой директивы указано значение no. Если вы все-таки # установите значение yes для этой директивы, то не забудьте указать # в файле /etc/ssh/ssh_known_hosts IP-адреса компьютеров, которым # разрешен доступ к SSH-серверу. Только для первой версии протокола RhostsRSAAuthentication no # Если вы используете вторую версию протокола и хотите разрешить # rhosts-аутентификацию, то вам нужно включить директиву # HostbasedAuthentioation, а разрешенные узлы указываются в файле # ~/.ssh/known_hosts HostbasedAuthentication no # Если вы не доверяете пользовательским файлам ~/.ssh/known_hosts, # установите значение yes для директивы IgnoreUserKnownHosts. Тогда # будет использован только файл /etc/ssh/ssh_known_hosts #IgnoreUserKnownHosts yes # Следующая директива запрещает использование пустых паролей (не # рекомендуется изменять) PermitEmptyPasswords no # Change to yes to enable challenge-response passwords (beware issues # with some PAM modules and threads) ChallengeResponseAuthentication no # Аутентификация по паролю, а не по IP-адресу компьютера, указанного # в файле /etc/ssh/ssh_known_hosts #PasswordAuthentication yes # Параметры протокола аутентификации Kerberos. Рекомендуется # использовать RSA-аутентификацию #KerberosAuthentication no #KerberosGetAFSToken no #KerberosOrLocalPasswd yes #KerberosTicketCleanup yes # Параметры GSSAPI (ничего конкретного сказать не могу) #GSSAPIAuthentication no #GSSAPICleanupCredentials yes # Использовать X11 форвардинг, для запуска X11 приложений X11Forwarding yes X11DisplayOffset 10 # Выводить сообщение дня (находится в файле /etc/motd/) PrintMotd no # Выводить время последней регистрации пользователя PrintLastLog yes # Не обрывать TCP-соединение после выполнения команды по SSH TCPKeepAlive yes # Остальные параметры желательно оставить не тронутыми #UseLogin no #MaxStartups 10:30:60 #Banner /etc/issue.net AcceptEnv LANG LC_* Subsystem sftp /usr/lib/openssh/sftp-server # Использовать для аутентификации модули PAM UsePAM yes |
После установки пакетов openssh—server и openssh—client можно приступить к тестированию работы SSH-сервера. Для запуска сервера можно использовать команду:
sudo /etc/init.d/ssh start |
А для останова — ту же команду, но с параметром stop: sudo /etc/init.d/ssh stop
После этого можно ввести команду:
ssh 127.0.0.1 |
для подключения к локальному компьютеру. Можно также подключиться с удаленного компьютера. Если сеть на локальном и удаленном компьютерах настроена правильно, проблем не должно возникнуть. Для более сложных вещей с применением SSH/OpenSSH — Google Вам в помощь! Кстати я многое узнаю с ru.wikipedia.org.
Я имею весьма отдалённое отношение к администрированию и удалённому доступу, но идея о том, что любому из нас могут предложить должность админа Linux’а мне понравилась))
Отличная штука, только бы докачку поддерживала
С SSH у новичком обысно много заморочек. Благодаря такому подробному материалу, жизнь упрощается. Подробная инструкция,опции программы — все что искал нашел.
Оно то конечно понятно, что SSH гораздо безопаснее telnet. Я вот «поселил» у себя на балконе тестовый сервак, повесил на него пару сайтов, настроил SSH. Роутер настроил так, что к SSH доступ есть только из домашней сети. Открывать доступ из мира все равно как-то стремно. Хотя все равно открываю, если приходится уезжать куда-то на какое-то время.
благодарю, было полезно. затруднился с этим на фряхе