abstract: В статье описаны продвинутые функций OpenSSH, которые позволяют сильно упростить жизнь системным администраторам и программистам, которые не боятся шелла. В отличие от большинства руководств, которые кроме ключей и -L/D/R опций ничего не описывают, я попытался собрать все интересные фичи и удобства, которые с собой несёт ssh.

Предупреждение: пост очень объёмный, но для удобства использования я решил не резать его на части.

Оглавление:

• управление ключами
• копирование файлов через ssh
• Проброс потоков ввода/вывода
• Монтирование удалённой FS через ssh
• Удалённое исполнение кода
• Алиасы и опции для подключений в.ssh/config
• Опции по-умолчанию
• Проброс X-сервера
• ssh в качестве socks-proxy
• Проброс портов - прямой и обратный
• Реверс-сокс-прокси
• туннелирование L2/L3 трафика
• Проброс агента авторизации
• Туннелирование ssh через ssh сквозь недоверенный сервер (с большой вероятностью вы этого не знаете )

Управление ключами

Теория в нескольких словах: ssh может авторизоваться не по паролю, а по ключу. Ключ состоит из открытой и закрытой части. Открытая кладётся в домашний каталог пользователя, «которым» заходят на сервер, закрытая - в домашний каталог пользователя, который идёт на удалённый сервер. Половинки сравниваются (я утрирую) и если всё ок - пускают. Важно: авторизуется не только клиент на сервере, но и сервер по отношению к клиенту (то есть у сервера есть свой собственный ключ). Главной особенностью ключа по сравнению с паролем является то, что его нельзя «украсть», взломав сервер - ключ не передаётся с клиента на сервер, а во время авторизации клиент доказывает серверу, что владеет ключом (та самая криптографическая магия).

Генерация ключа

Свой ключ можно сгенерировать с помощью команды ssh-keygen. Если не задать параметры, то он сохранит всё так, как надо.

Ключ можно закрыть паролем. Этот пароль (в обычных графических интерфейсах) спрашивается один раз и сохраняется некоторое время. Если пароль указать пустым, он спрашиваться при использовании не будет. Восстановить забытый пароль невозможно.

Сменить пароль на ключ можно с помощью команды ssh-keygen -p .

Структура ключа

(если на вопрос про расположение ответили по-умолчанию).
~/.ssh/id_rsa.pub - открытый ключ. Его копируют на сервера, куда нужно получить доступ.
~/.ssh/id_rsa - закрытый ключ. Его нельзя никому показывать. Если вы в письмо/чат скопипастите его вместо pub, то нужно генерировать новый ключ. (Я не шучу, примерно 10% людей, которых просишь дать ssh-ключ постят id_rsa, причём из этих десяти процентов мужского пола 100%).

Копирование ключа на сервер

В каталоге пользователя, под которым вы хотите зайти, если создать файл ~/.ssh/authorized_keys и положить туда открытый ключ, то можно будет заходить без пароля. Обратите внимание, права на файл не должны давать возможность писать в этот файл посторонним пользователям, иначе ssh его не примет. В ключе последнее поле - user@machine. Оно не имеет никакого отношения к авторизации и служит только для удобства определения где чей ключ. Заметим, это поле может быть поменяно (или даже удалено) без нарушения структуры ключа.

Если вы знаете пароль пользователя, то процесс можно упростить. Команда ssh-copy-id user@server позволяет скопировать ключ не редактируя файлы вручную.

Замечание: Старые руководства по ssh упоминают про authorized_keys2. Причина: была первая версия ssh, потом стала вторая (текущая), для неё сделали свой набор конфигов, всех это очень утомило, и вторая версия уже давным давно переключилась на версии без всяких «2». То есть всегда authorized_keys и не думать о разных версиях.

Если у вас ssh на нестандартном порту, то ssh-copy-id требует особого ухищрения при работе: ssh-copy-id "-p 443 user@server" (внимание на кавычки).

Ключ сервера

Первый раз, когда вы заходите на сервер, ssh вас спрашивает, доверяете ли вы ключу. Если отвечаете нет, соединение закрывается. Если да - ключ сохраняется в файл ~/.ssh/known_hosts . Узнать, где какой ключ нельзя (ибо несекьюрно).

Если ключ сервера поменялся (например, сервер переустановили), ssh вопит от подделке ключа. Обратите внимание, если сервер не трогали, а ssh вопит, значит вы не на тот сервер ломитесь (например, в сети появился ещё один компьютер с тем же IP, особо этим страдают всякие локальные сети с 192.168.1.1, которых в мире несколько миллионов). Сценарий «злобной man in the middle атаки» маловероятен, чаще просто ошибка с IP, хотя если «всё хорошо», а ключ поменялся - это повод поднять уровень паранойи на пару уровней (а если у вас авторизация по ключу, а сервер вдруг запросил пароль - то паранойю можно включать на 100% и пароль не вводить).

Удалить известный ключ сервера можно командой ssh-keygen -R server . При этом нужно удалить ещё и ключ IP (они хранятся раздельно): ssh-keygen -R 127.0.0.1 .

Ключ сервера хранится в /etc/ssh/ssh_host_rsa_key и /etc/ssh/ssh_host_rsa_key.pub . Их можно:
а) скопировать со старого сервера на новый.
б) сгенерировать с помощью ssh-keygen. Пароля при этом задавать не надо (т.е. пустой). Ключ с паролем ssh-сервер использовать не сможет.

Заметим, если вы сервера клонируете (например, в виртуалках), то ssh-ключи сервера нужно обязательно перегенерировать.

Старые ключи из know_hosts при этом лучше убрать, иначе ssh будет ругаться на duplicate key.

Копирование файлов

Передача файлов на сервер иногда может утомлять. Помимо возни с sftp и прочими странными вещами, ssh предоставляет нам команду scp , которая осуществляет копирование файла через ssh-сессию.

Scp path/myfile [email protected]:/full/path/to/new/location/

Обратно тоже можно:
scp [email protected]:/full/path/to/file /path/to/put/here

Fish warning: Не смотря на то, что mc умеет делать соединение по ssh, копировать большие файлы будет очень мучительно, т.к. fish (модуль mc для работы с ssh как с виртуальной fs) работает очень медленно. 100-200кб - предел, дальше начинается испытание терпения. (Я вспомнил свою очень раннюю молодость, когда не зная про scp, я копировал ~5Гб через fish в mc, заняло это чуть больше 12 часов на FastEthernet).

Возможность копировать здорово. Но хочется так, чтобы «сохранить как» - и сразу на сервер. И чтобы в графическом режиме копировать не из специальной программы, а из любой, привычной.

Так тоже можно:

sshfs

Теория: модуль fuse позволяет «экспортировать» запросы к файловой системе из ядра обратно в userspace к соответствующей программе. Это позволяет легко реализовывать «псевдофайловые системы». Например, мы можем предоставить доступ к удалённой файловой системе через ssh так, что все локальные приложения (за малым исключением) не будут ничего подозревать.

Собственно, исключение: O_DIRECT не поддерживается, увы (это проблема не sshfs, это проблема fuse вообще).

Использование: установить пакет sshfs (сам притащит за собой fuse).

Собственно, пример моего скрипта, который монтирует desunote.ru (размещающийся у меня на домашнем комьютере - с него в этой статье показываются картинки) на мой ноут:

#!/bin/bash sshfs desunote.ru:/var/www/desunote.ru/ /media/desunote.ru -o reconnect

Делаем файл +x, вызываем, идём в любое приложение, говорим сохранить и видим:

Параметры sshfs, которые могут оказаться важными: -o reconnect (говорит пытаться пересоединиться вместо ошибок).

Если вы много работаете с данными от рута, то можно (нужно) сделать idmap:

-o idmap=user . Работает она следующим образом: если мы коннектимся как пользователь pupkin@server, а локально работаем как пользователь vasiliy, то мы говорим «считать, что файлы pupkin, это файлы vasiliy». ну или «root», если мы коннектимся как root.

В моём случае idmap не нужен, так как имена пользователей (локальное и удалённое) совпадают.

Заметим, комфортно работать получается только если у нас есть ssh-ключик (см. начало статьи), если нет - авторизация по паролю выбешивает на 2-3 подключение.

Отключить обратно можно командой fusermount -u /path , однако, если соединение залипло (например, нет сети), то можно/нужно делать это из-под рута: sudo umount -f /path.

Удалённое исполнение кода

ssh может выполнить команду на удалённом сервере и тут же закрыть соединение. Простейший пример:

Ssh user@server ls /etc/

Выведет нам содержимое /etc/ на server, при этом у нас будет локальная командная строка.

Некоторые приложения хотят иметь управляющий терминал. Их следует запускать с опцией -t:
ssh user@server -t remove_command

Кстати, мы можем сделать что-то такого вида:
ssh user@server cat /some/file|awk "{print $2}" |local_app

Это нас приводит следующей фиче:

Проброс stdin/out

Допустим, мы хотим сделать запрос к программе удалённо, а потом её вывод поместить в локальный файл

Ssh [email protected] command >my_file

Допустим, мы хотим локальный вывод положить удалённо

Mycommand |scp - [email protected]:/path/remote_file

Усложним пример - мы можем прокидывать файлы с сервера на сервер: Делаем цепочку, чтобы положить stdin на 10.1.1.2, который нам не доступен снаружи:

Mycommand | ssh [email protected] «scp - [email protected]:/path/to/file»

Есть и вот такой головоломный приём использования pipe"а (любезно подсказали в комментариях в жж):

Tar -c * | ssh user@server "cd && tar -x"

Tar запаковывает файлы по маске локально, пишет их в stdout, откуда их читает ssh, передаёт в stdin на удалённом сервере, где их cd игнорирует (не читает stdin), а tar - читает и распаковывает. Так сказать, scp для бедных.

Алиасы

Скажу честно, до последнего времени не знал и не использовал. Оказались очень удобными.

В более-менее крупной компании часто оказывается, что имена серверов выглядят так: spb-MX-i3.extrt.int.company.net. И пользователь там не равен локальному. То есть логиниться надо так: ssh [email protected]. Каждый раз печатать - туннельных синдромов не напасёшься. В малых компаниях проблема обратная - никто не думает о DNS, и обращение на сервер выглядит так: ssh [email protected]. Короче, но всё равно напрягает. Ещё большая драма, если у нас есть нестандартный порт, и, например, первая версия ssh (привет цискам). Тогда всё выглядит так: ssh -1 -p 334 [email protected]. Удавиться. Про драму с scp даже рассказывать не хочется.

Можно прописать общесистемные alias"ы на IP (/etc/hosts), но это кривоватый выход (и пользователя и опции всё равно печатать). Есть путь короче.

Файл ~/.ssh/config позволяет задать параметры подключения, в том числе специальные для серверов, что самое важное, для каждого сервера своё. Вот пример конфига:

Host ric Hostname ооо-рога-и-копыта.рф User Администратор ForwardX11 yes Compression yes Host home Hostname myhome.dyndns.org User vasya PasswordAuthentication no

Все доступные для использования опции можно увидеть в man ssh_config (не путать с sshd_config).

Опции по умолчанию

По подсказке UUSER : вы можете указать настройки соединения по умолчанию с помощью конструкции Host *, т.е., например:

Host * User root Compression yes

То же самое можно сделать и в /etc/ssh/ssh_config (не путать с /etc/ssh/sshd _config), но это требует прав рута и распространяется на всех пользователей.

Проброс X-сервера

Собственно, немножко я проспойлерил эту часть в примере конфига выше. ForwardX11 - это как раз оно.

Теория: Графические приложения в юникс обычно используют X-сервер (wayland в пути, но всё ещё не готов). Это означает, что приложение запускается и подключается к X-серверу для рисования. Иными словами, если у вас есть голый сервер без гуя и есть локальный x-сервер (в котором вы работаете), то вы можете дать возможность приложениям с сервера рисовать у вас на рабочем столе. Обычно подключение к удалённом X-серверу - не самая безопасная и тривиальная вещь. SSH позволяет упростить этот процесс и сделать его совсем безопасным. А возможность жать трафик позволяет ещё и обойтись меньшим трафиком (т.е. уменьшить утилизацию канала, то есть уменьшить ping (точнее, latency), то есть уменьшить лаги).

Ключики: -X - проброс X-сервера. -Y проброс авторизации.

Достаточно просто запомнить комбинацию ssh -XYC user@SERVER.
В примере выше (названия компании вымышленные) я подключаюсь к серверу ооо-рога-и-копыта.рф не просто так, а с целью получить доступ к windows-серверу. Безопасность microsoft при работе в сети мы все хорошо знаем , так что выставлять наружу голый RDP неуютно. Вместо этого мы подключаемся к серверу по ssh, а дальше запускаем там команду rdesktop:
ssh ric
rdesktop -k en-us 192.168.1.1 -g 1900x1200

И чудо, окошко логина в windows на нашем рабочем столе. Заметим, тщательно зашифрованное и неотличимое от обычного ssh-трафика.

Socks-proxy

Когда я оказываюсь в очередной гостинице (кафе, конференции), то местный wifi чаще всего оказывается ужасным - закрытые порты, неизвестно какой уровень безопасности. Да и доверия к чужим точкам доступа не особо много (это не паранойя, я вполне наблюдал как уводят пароли и куки с помощью банального ноутбука, раздающего 3G всем желающим с названием близлежащей кафешки (и пишущего интересное в процессе)).

Особые проблемы доставляют закрытые порты. То джаббер прикроют, то IMAP, то ещё что-нибудь.

Обычный VPN (pptp, l2tp, openvpn) в таких ситуациях не работает - его просто не пропускают. Экспериментально известно, что 443ий порт чаще всего оставляют, причём в режиме CONNECT, то есть пропускают «как есть» (обычный http могут ещё прозрачно на сквид завернуть).

Решением служит socks-proxy режим работы ssh. Его принцип: ssh-клиент подключается к серверу и слушает локально. Получив запрос, он отправляет его (через открытое соединение) на сервер, сервер устанавливает соединение согласно запросу и все данные передаёт обратно ssh-клиенту. А тот отвечает обратившемуся. Для работы нужно сказать приложениям «использовать socks-proxy». И указать IP-адрес прокси. В случае с ssh это чаще всего localhost (так вы не отдадите свой канал чужим людям).

Подключение в режиме sock-proxy выглядит так:
ssh -D 8080 user@server

В силу того, что чужие wifi чаще всего не только фиговые, но и лагливые, то бывает неплохо включить опцию -C (сжимать трафик). Получается почти что opera turbo (только картинки не жмёт). В реальном сёрфинге по http жмёт примерно в 2-3 раза (читай - если вам выпало несчастье в 64кбит, то вы будете мегабайтные страницы открывать не по две минуты, а секунд за 40. Фигово, но всё ж лучше). Но главное: никаких украденных кук и подслушанных сессий.

Я не зря сказал про закрытые порты. 22ой порт закрывают ровно так же, как «не нужный» порт джаббера. Решение - повесить сервер на 443-й порт. Снимать с 22 не стоит, иногда бывают системы с DPI (deep packet inspection), которые ваш «псевдо-ssl» не пустят.

Вот так выглядит мой конфиг:

/etc/ssh/sshd_config:
(фрагмент)
Port 22
Port 443

А вот кусок ~/.ssh/config с ноутбука, который описывает vpn

Host vpn Hostname desunote.ru User vasya Compression yes DynamicForward 127.1:8080 Port 443

(обратите внимание на «ленивую» форму записи localhost - 127.1, это вполне себе законный метод написать 127.0.0.1)

Проброс портов

Мы переходим к крайне сложной для понимания части функционала SSH, позволяющей осуществлять головоломные операции по туннелированию TCP «из сервера» и «на сервер».

Для понимания ситуации все примеры ниже будут ссылаться на вот эту схему:

Комментарии: Две серые сети. Первая сеть напоминает типичную офисную сеть (NAT), вторая - «гейтвей», то есть сервер с белым интерфейсом и серым, смотрящим в свою собственную приватную сеть. В дальнейших рассуждениях мы полагаем, что «наш» ноутбук - А, а «сервер» - Б.

Задача : у нас локально запущено приложение, нам нужно дать возможность другому пользователю (за пределами нашей сети) посмотреть на него.

Решение: проброс локального порта (127.0.0.1:80) на публично доступный адрес. Допустим, наш «публично доступный» Б занял 80ый порт чем-то полезным, так что пробрасывать мы будем на нестандартный порт (8080).

Итоговая конфигурация: запросы на 8.8.8.8:8080 будут попадать на localhost ноутбука А.

Ssh -R 127.1:80:8.8.8.8:8080 [email protected]

Опция -R позволяет перенаправлять с удалённого (R emote) сервера порт на свой (локальный).
Важно: если мы хотим использовать адрес 8.8.8.8, то нам нужно разрешить GatewayPorts в настройках сервера Б.
Задача . На сервере «Б» слушает некий демон (допустим, sql-сервер). Наше приложение не совместимо с сервером (другая битность, ОС, злой админ, запрещающий и накладывающий лимиты и т.д.). Мы хотим локально получить доступ к удалённому localhost"у.

Итоговая конфигурация: запросы на localhost:3333 на "A" должны обслуживаться демоном на localhost:3128 "Б".

Ssh -L 127.1:3333:127.1:3128 [email protected]

Опция -L позволяет локальные обращения (L ocal) направлять на удалённый сервер.

Задача : На сервере «Б» на сером интерфейсе слушает некий сервис и мы хотим дать возможность коллеге (192.168.0.3) посмотреть на это приложение.

Итоговая конфигурация: запросы на наш серый IP-адрес (192.168.0.2) попадают на серый интерфейс сервера Б.

Ssh -L 192.168.0.2:8080:10.1.1.1:80 [email protected]

Вложенные туннели

Разумеется, туннели можно перенаправлять.

Усложним задачу: теперь нам хочется показать коллеге приложение, запущенное на localhost на сервере с адресом 10.1.1.2 (на 80ом порту).

Решение сложно:
ssh -L 192.168.0.2:8080:127.1:9999 [email protected] ssh -L 127.1:9999:127.1:80 [email protected]

Что происходит? Мы говорим ssh перенаправлять локальные запросы с нашего адреса на localhost сервера Б и сразу после подключения запустить ssh (то есть клиента ssh) на сервере Б с опцией слушать на localhost и передавать запросы на сервер 10.1.1.2 (куда клиент и должен подключиться). Порт 9999 выбран произвольно, главное, чтобы совпадал в первом вызове и во втором.

Реверс-сокс-прокси

Если предыдущий пример вам показался простым и очевидным, то попробуйте догадаться, что сделает этот пример:
ssh -D 8080 -R 127.1:8080:127.1:8080 [email protected] ssh -R 127.1:8080:127.1:8080 [email protected]

Если вы офицер безопасности, задача которого запретить использование интернета на сервере 10.1.1.2, то можете начинать выдёргивать волосы на попе, ибо эта команда организует доступ в интернет для сервера 10.1.1.2 посредством сокс-прокси, запущенного на компьютере «А». Трафик полностью зашифрован и неотличим от любого другого трафика SSH. А исходящий трафик с компьютера с точки зрения сети «192.168.0/24» не отличим от обычного трафика компьютера А.

Туннелирование

Если к этому моменту попа отдела безопасности не сияет лысиной, а ssh всё ещё не внесён в список врагов безопасности номер один, вот вам окончательный убийца всего и вся: туннелирование IP или даже ethernet. В самых радикальных случаях это позволяет туннелировать dhcp, заниматься удалённым arp-спуфингом, делать wake up on lan и прочие безобразия второго уровня.

(сам я увы, таким не пользовался).

Легко понять, что в таких условиях невозможно никаким DPI (deep packet inspection) отловить подобные туннели - либо ssh разрешён (читай - делай что хочешь), либо ssh запрещён (и можно смело из такой компании идиотов увольняться не ощущая ни малейшего сожаления).

Проброс авторизации

Если вы думаете, что на этом всё, то…… впрочем, в отличие от автора, у которого «снизу» ещё не написано, читатель заранее видит, что там снизу много букв и интриги не получается.

OpenSSH позволяет использовать сервера в качестве плацдарма для подключения к другим серверам, даже если эти сервера недоверенные и могут злоупотреблять чем хотят.

Повторю картинку:

Допустим, мы хотим подключиться к серверу 10.1.1.2, который готов принять наш ключ. Но копировать его на 8.8.8.8 мы не хотим, ибо там проходной двор и половина людей имеет sudo и может шариться по чужим каталогам. Компромиссным вариантом было бы иметь «другой» ssh-ключ, который бы авторизовывал [email protected] на 10.1.1.2, но если мы не хотим пускать кого попало с 8.8.8.8 на 10.1.1.2, то это не вариант (тем паче, что ключ могут не только поюзать, но и скопировать себе «на чёрный день»).

Ssh предлагает возможность форварда ssh-агента (это такой сервис, который запрашивает пароль к ключу). Опция ssh -A пробрасывает авторизацию на удалённый сервер.

Вызов выглядит так:

Ssh -A [email protected] ssh [email protected]

Удалённый ssh-клиент (на 8.8.8.8) может доказать 10.1.1.2, что мы это мы только если мы к этому серверу подключены и дали ssh-клиенту доступ к своему агенту авторизации (но не ключу!).

В большинстве случаев это прокатывает.

Однако, если сервер совсем дурной, то root сервера может использовать сокет для имперсонализации, когда мы подключены.

Есть ещё более могучий метод - он превращает ssh в простой pipe (в смысле, «трубу») через которую насквозь мы осуществляем работу с удалённым сервером.

Главным достоинством этого метода является полная независимость от доверенности промежуточного сервера. Он может использовать поддельный ssh-сервер, логгировать все байты и все действия, перехватывать любые данные и подделывать их как хочет - взаимодействие идёт между «итоговым» сервером и клиентом. Если данные оконечного сервера подделаны, то подпись не сойдётся. Если данные не подделаны, то сессия устанавливается в защищённом режиме, так что перехватывать нечего.

Эту клёвую настройку я не знал, и раскопал её redrampage .

Настройка завязана на две возможности ssh: опцию -W (превращающую ssh в «трубу») и опцию конфига ProxyCommand (опции командной строки, вроде бы нет), которая говорит «запустить программу и присосаться к её stdin/out». Опции эти появились недавно, так что пользователи centos в пролёте.

Выглядит это так (циферки для картинки выше):

Ssh/config:
Host raep HostName 10.1.1.2 User user2 ProxyCommand ssh -W %h:%p [email protected]

Ну а подключение тривиально: ssh raep .

Повторю важную мысль: сервер 8.8.8.8 не может перехватить или подделать трафик, воспользоваться агентом авторизации пользователя или иным образом изменить трафик. Запретить - да, может. Но если разрешил - пропустит через себя без расшифровки или модификации. Для работы конфигурации нужно иметь свой открытый ключ в authorized_keys как для [email protected], так и в [email protected]

Разумеется, подключение можно оснащать всеми прочими фенечками - прокидыванием портов, копированием файлов, сокс-прокси, L2-туннелями, туннелированием X-сервера и т.д.
туннелирование ssh Добавить метки

Благодарим Вас за проявленный интерес к нашему сайту. Компания Айтишник существует с 2006 года и предоставляет услуги IT аутсорсинга. Аутсорсинг - это перепоручение необходимых, но непрофильных для компании работ другой организации. В нашем случае это: создание, поддержка и сопровождение сайтов, продвижение сайтов в поисковых системах, поддержка и администрирование серверов под управлением Debian GNU/Linux.

Сайты на Joomla

В нынешний век информации, сайт де факто, становится как минимум визитной карточкой организации, а зачастую одним из инструментов бизнеса. Уже сейчас сайты создаются не только для организаций и частных лиц, но и для отдельных товаров, услуг и даже событий. На сегодняшний день сайт это не только источник рекламы на гигантскую аудиторию, но и инструмент для продаж и завязывания новых контактов. Мы создаем сайты, используя CMS Joomla! Эта система управления сайтами проста и интуитивно понятна. Она очень широко распространена и, следовательно, в Интернете о ней содержится большое количество информации. Найти специалиста, работающего с Joomla тоже несложно. И вам не надо далеко ходить! Наша компания Айтишник занимается обслуживанием и сопровождением сайтов на Joomla! Мы проведём все технические работы, возьмём на себя всю переписку с хостером и регистратором домена, наполним сайт и обновим на нём информацию. И хотя Joomla проста в управлении, интуитивно понятна. Но будете ли вы сами регулярно выполнять необходимые работы на сайте? Сколько времени они отнимут у вас? Если вы хотите сконцентрироваться на своём деле, то доверьте поддержку вашего сайта нам. Мы сделаем все от нас зависящее, чтобы сайт жил и приносил пользу своему владельцу.
Если вы коммерческая организация, которая рекламирует или продаёт свои товары, услуги в Интернет, то вам просто необходимо продвижение сайта в поисковых системах. Ведь для того, чтобы продать что-нибудь надо, как минимум, чтобы это увидели, чтобы об этом узнали. И мы поможем вам в этом, мы продвинем ваш Joomla сайт в поисковых системах. В зависимости от конкуренции и выделенного для продвижения бюджета, ваш сайт будет занимать достойные позиции в поисковой выдаче. Сайт увеличит вашу прибыль!

Серверы Debian

Рано или поздно, стремясь к открытости и прозрачности своего бизнеса, многие компании сталкиваются с необходимостью обеспечения лицензионной чистоты используемого программного обеспечения. Однако, далеко не всегда затраты на лицензионные отчисления приемлемы, в особенности для малого и среднего бизнеса. Выходом из этой сложной ситуации является решение о переходе на Open Source технологии. Одним из направлений Open Source является операционная система Linux (Линукс). Сотрудники нашей компании специализируются на Debian Linux (Дебиан Линукс). Это старейший и наиболее устойчивый дистрибутив операционной системы Линукс. Мы предлагаем вам услуги по внедрению Debian Linux на Вашем предприятии, настройку, обслуживание и поддержку серверов.

Информация и реклама

SSH-ключи используются для идентификации клиента при подключении к серверу по SSH-протоколу. Используйте этот способ вместо аутентификации по паролю.

SSH-ключи представляют собой пару - закрытый и открытый ключ. Закрытый должен храниться в закрытом доступе у клиента, открытый отправляется на сервер и размещается в файле authorized_keys.

Создание SSH-ключей в Linux на примере CentOS

На клиентской стороне должен быть установлен пакет ssh (openssh). На серверах FirstVDS с шаблонами по умолчанию необходимое ПО уже установлено.

Yum -y install openssh-server openssh-clients

На клиентском компьютере в командной строке выполните команду генерации ключей:

Ssh-keygen

Введите путь файла, в который будут помещены ключи. Каталог по умолчанию указан в скобках, в примере /домашний_каталог/.ssh/id_rsa . Если хотите оставить расположение по умолчанию, нажмите Enter .

Пароль (passphrase) используется для ограничения доступа к закрытому ключу. Пароль усложнит использование ключа третьими лицами в случае утраты. Если не хотите использовать секретную фразу, нажмите Enter без заполнения строки.

Успешно сгенерировав пару ключей, вы увидите уведомление:

Открытый ключ хранится в файле /домашний_каталог/.ssh/id_rsa.pub , закрытый - /домашний_каталог/.ssh/id_rsa .

Скопируйте открытый ключ на сервер в файл /домашний_каталог/.ssh/authorized_key . Одной строкой:

Cat ~/.ssh/id_rsa.pub | ssh root@ip-адрес-сервера %22cat >> ~/.ssh/authorized_keys%22

Или откройте этот файл на сервере редактором vi и вставьте строку с открытым ключом после ssh-rsa .

Ещё один способ скопировать ключ в authorized_keys - команда echo , которая помещает строку в конец файла.

Echo ssh-rsa строка-публичного-ключа >> /root/.ssh/authorized_keys

Создание SSH-ключей на Windows с PuTTYgen

Если вы используете ОС Windows, то подключиться по SSH к вашему (Linux) серверу можно через PuTTY или OpenSSH . Генерация ключей в этом случае выполняется также при помощи этих программ. В примере мы используем клиент PuTTY.

Запустите приложение PuTTYgen , которое устанавливается вместе с PuTTY.

Выберите тип ключа SSH2-RSA и нажмите Generate .

В процессе генерации ключей несколько раз произвольно проведите мышкой по экрану приложения для создания случайных величин, используемых для ключей.

После завершения создания ключей открытый ключ выводится на экран, закрытый хранится в памяти приложения. Чтобы сохранить эти ключи нажмите Save public key и Save private key . Укажите расположение файлов с ключами.

При сохранении закрытого ключа, если не заполнено поле Key passphrase , появится запрос «Хотите ли вы сохранить ключ без секретной фразы?»

Теперь открытый ключ необходимо скопировать на сервер в файл authorized_keys . Используйте WinSCP или другой клиент для работы с файлами на удалённом Linux-сервере. Вы можете скопировать файл с открытым ключом целиком на сервер, чтоб его копия хранилась в папке.ssh

Откройте файл authorized_keys через WinSCP и файл, в который вы сохранили открытый ключ (public), на локальном компьютере текстовым редактором. Скопируйте значение ключа, сохраните и закройте файл в WinSCP.

При запуске PuTTY укажите путь к закрытому ключу на локальном компьютере. Для этого во вкладке Connections → Auth выберите необходимый путь.

Теперь можно отключить на сервере аутентификацию по паролю и использовать только SSH-ключи.

Отключение аутентификации по паролю

Подключитесь к серверу по SSH, используя пароль, и откройте файл sshd_config для редактирования.

Vi /etc/ssh/sshd_config

Убедитесь, что указан правильный путь к открытым ключам SSH, поставьте значение параметра PasswordAuthentication no .

Перезапустите службу sshd.

Service sshd restart

Подключитесь к серверу по SSH без использования пароля. Например, запустите PuTTY, проверьте, что во вкладке Connections -> Auth содержится путь к закрытому ключу и откройте подключение.

В случае успешной аутентификации по SSH-ключу вы получите доступ к командной строке сервера и сообщение вида Authenticating with public key "rsa-key-20170510" , где rsa-key-20170510 - имя применённого закрытого ключа, указанное вами в файле authorized_keys .

Эта статья помечена как незаконченная. См. заметку в конце статьи.

Данная статья посвящена клиенту и серверу защищенного терминала (secure shell) в Ubuntu, их настройке и использованию. SSH - это специальный сетевой протокол, позволяющий получать удаленный доступ к компьютеру с большой степенью безопасности соединения. Более подробно про протокол ssh можно прочитать .

Описание принципов работы и используемых приложений

В основном, SSH реализован в виде двух приложений - SSH -сервера и SSH -клиента В Ubuntu используется свободная реализация клиента и сервера SSH - OpenSSH . При подключении клиент проходит процедуру авторизации у сервера и между ними устанавливается зашифрованное соединение. OpenSSH сервер может работать как с протоколом ssh1, так и с протоколом ssh2. В настоящее время протокол ssh1 считается небезопасным, поэтому его использование крайне не рекомендуется. Я намеренно опускаю различные технические подробности работы протокола, т. к. основной целью данного руководства является описание его настройки и использования. Про сам протокол, принципы его работы, алгоритмы шифрования и т. д. существует множество статей в интернете, например подробно про это можно почитать .

Установка

Установить OpenSSH можно из терминала командой:

sudo apt-get install ssh

В метапакете ssh содержится как клиент, так и сервер, но при этом, скорее всего, будет установлен только сервер, т. к. клиент уже есть в Ubuntu по умолчанию.

Настройка сервера

При установке SSH -сервер автоматически прописывается в автозагрузку. Управлять его запуском, остановкой или перезапуском можно с помощью команд:

sudo service ssh stop| start| restart

Основной файл конфигурации SSH -сервера - файл /etc/ssh/sshd_config , доступный для чтения или редактирования только суперпользователю . После каждого изменения этого файла необходимо перезапустить ssh-сервер для применения таких изменений.

Пример конфигурации SSH -сервера в Ubuntu по умолчанию :

# Пример конфигурации open-ssh сервера с русскими # # комментариями..2010. # # # # # # Условные обозначения: # # Под "по умолчанию" - подразумевается поведение sshd при # # неуказанной явно директиве. Стоит заметить, что в Ubuntu # # файл sshd_config уже содержит ряд настроек, которые # # являются настройками по умолчанию для именно для Ubuntu. # # Такие настройки указаны в этом файле. # # # ############################################################ ################ Настройки адресов/портов и т.д. ########### ############################################################ # # ## Port #################################################### # # # Используемый порт. Можно указывать несколько, например: # # Port 22 # # Port 23 # # Port 24 # # Рекомендуется использовать нестандартный порт, т.к. # # стандартный часто сканируется ботами на предмет # # потенциальных "дырок". Может быть опущен, если задан # # через адрес. См. также параметр ListenAddress. # # # Port 22 # # ## ListenAddress ########################################### # # # Сетевой адрес, на котором "слушает" сервер. Адрес можно # # записывать так: # # ListenAddress host|IPv4_addr|IPv6_addr # # ListenAddress host|IPv4_addr:port # # ListenAddress :port # # Если порт не задан, sshd будет слушать на этом адресе и # # на порту, указанному в опции Port. Если вы будете # # использовать ListenAddress не указывая порт, то опция # # Port должна предшествовать опции ListenAddress. Если не # # указывать, то по умолчанию слушает на всех локальных # # адресах. Можно указывать несколько адресов. # # # ## AddressFamily ########################################### # # # Указывает, какое семейство IP адресов должно быть # # использовано sshd. Возможные варианты: # # “any” - любые # # “inet” (только IPv4) # # “inet6” (только IPv6) # # По умолчанию - “any”. # AddressFamily inet # # ## UseDNS ################################################## # # # Указывает, должен ли sshd проверять имя хоста и # # используя это имя сверять IP адрес переданный клиентом с # # полученным от DNS. # # Значение по умолчанию - “yes”. # # # ############################################################ ############# Настройки доступа пользователей ############## ############################################################ # # # Пустить/не пустить пользователя определяется директивами # # DenyUsers, AllowUsers, DenyGroups, и AllowGroups. # # при этом, проверка проходит сверху - вниз по цепочке: # # ## DenyUsers ## # # || # # ## AllowUsers ## # # || # # ## DenyGroups ## # # || # # ## AllowGroups ## # # Принимаются только имена пользователей и групп, числовые # # идентификаторы (UserID) - не распознаются. Корректная # # запись нескольких пользователей/групп по очереди, через # # пробел. Если записано в виде пользователь@хост - то # # пользователь и хост проверяются отдельно, это позволяет # # разграничить доступ определенных пользователей с # # определенных хостов. Стоит помнить, что директивы # # DenyUsers и AllowUsers принимают в качестве параметра # # имя пользователя, а DenyGroups и AllowGroups - имя # # группы. См. PATTERNS в man ssh_config для дополнительной # # информации о формах записи имен пользователей и групп. # # # ## DenyUsers ############################################### # # # Список ПОЛЬЗОВАТЕЛЕЙ, которым НЕЛЬЗЯ пользоваться sshd. # # По умолчанию - не указан = не запрещен никто. Т.е. если # # тут указан пользователь, то ему будет отказано в доступе # # к ssh серверу. # # # ## AllowUsers ############################################## # # # Список ПОЛЬЗОВАТЕЛЕЙ, которым МОЖНО пользоваться sshd, # # По умолчанию - не указан = разрешено всем. Т.е. если # # указан хотя бы один пользователь, ssh доступ к серверу # # доступен только для него. # # # ## DenyGroups ############################################## # # # Список ГРУПП, которым НЕЛЬЗЯ пользоваться sshd. # # По умолчанию - не указан = не запрещена ни одна группа. # # Т.е. если указана хотя бы одна группа, то пользователям, # # входящим в эту группу будет отказано в доступе к ssh # # серверу. # # # ## AllowGroups ############################################# # # # Список ГРУПП, которым МОЖНО пользоваться sshd. # # По умолчанию - не указан = разрешено всем. Т.е. если # # указана хотя бы одна группа, то только тем пользователям,# # которые в нее входят будет разрешен доступ к ssh серверу.# # # ############################################################ ######### Опции определения состояния соединения ########### ############################################################ # # ## TCPKeepAlive ############################################ # # # Указывает, нужно системе посылать TCP сообщения клиенту # # с целью поддержания соединения. Если посылать эти пакеты,# # можно определить разрыв соединения. Однако это также # # означает, что соединение может быть разорвано в случае # # кратковременного перебоя в работе маршрутизации и # # некоторых это сильно раздражает. С другой стороны, если # # таких сообщений не посылать - сеансы на сервере могут # # длиться бесконечно, порождая пользователей - "призраков",# # и пожирая ресурсы сервера. Значение по умолчанию - “yes”,# # т.е. посылать такие сообщения. Для отключения отправки # # таких сообщений нужно задать значение “no”. Ранее эта # # опция называлась KeepAlive. Стоит заметить, что # # существуют более защищенные способы проверки состояния # # соединения (см. ниже). # # # TCPKeepAlive yes # # ## ClientAliveCountMax ##################################### # # # Задает количество сообщений к клиентам, которые sshd # # посылает подряд, не получая какого либо ответа от # # клиента. Если пороговое значение будет достигнуто, а # # клиент так и не ответил - sshd отключит клиента, прервав # # ssh сессию. Стоит отметить, что использование таких # # сообщений в корне отличается от директивы TCPKeepAlive. # # Сообщения к/от клиентов посылаются по зашифрованному # # каналу и поэтому не подвержены спуфингу. Сообщения же # # TCPKeepAlive спуфингу подвержены. Механизм client alive # # особо ценен в тех случаях, когда серверу и клиенту нужно # # знать когда соединение стало неактивным. По умолчанию # # значение равно 3. В случае, если ClientAliveInterval # # задан равным 15 и ClientAliveCountMax оставлен по # # умолчанию, неотвечающие клиенты будут отключены примерно # # через 45 секунд. Эта директива работает только для # # протокола ssh2. # # # ## ClientAliveInterval ##################################### # # # Задает временной интервал в секундах. Если в течении # # этого интервала не было обмена данными с клиентом, sshd # # посылает сообщение по зашифрованному каналу, # # запрашивающее ответ от клиента. По умолчанию - 0, т.е. # # не посылать таких сообщений. Эта директива работает # # только для протокола ssh2. # # # ############################################################ ################ Общие опции аутентификации ################ ############################################################ # # ## AuthorizedKeysFile ###################################### # # # Указывает файл, в котором содержатся публичные ключи, # # используемые для аутентификации пользователей. Директива # # может содержать маркеры вида %М, которые подставляются в # # процессе установки соединения. # # Определены следующие маркеры: # # %% - заменяется литералом "%" # # %h - заменяется домашней директорией # # аутентифицируещегося пользователя # # %u - заменяется именем аутентифицируещегося пользователя # # Таким образом, файл с ключами может быть задан как # # абсолютным путем (т.е. один общий файл с ключами), так и # # динамически - в зависимости от пользователя (т.е. по # # файлу на каждого пользователя). # # По умолчанию - “.ssh/authorized_keys”. # # Пример для файла ключа в домашней папке пользователя: # # AuthorizedKeysFile %h/.ssh/authorized_key # # Пример для общего файла: # # AuthorizedKeysFile /etc/ssh/authorized_keys # # См. описание файла authorized_keys для большей # # информации. # # # ## ChallengeResponseAuthentication ######################### # # # Указывает, разрешить ли аутентификацию вида вопрос-ответ # # (challenge-response authentication). Поддерживаются все # # виды аутентификации из login.conf По умолчанию - “yes”, # # т.е. разрешить. # # В Ubuntu - выключена по соображениям безопасности. # # # ChallengeResponseAuthentication no # # ## HostbasedUsesNameFromPacketOnly ######################### # # # Указывает, как сервер должен получать имя хоста клиента # # при схеме аутентификации, основанной на проверке хоста. # # Если задать "yes" - при проверке соответствия в файлах # # ~/.shosts, ~/.rhosts или /etc/hosts.equiv sshd будет # # использовать имя хоста, предоставленное клиентом. # # (выполняя реверсивное DNS распознование) Если задать "no"# # - sshd будет ресолвить имя из самого TCP соединения. # # По умолчанию - "no". # # # ## IgnoreRhosts ############################################ # # # Запрещает использование файлов.rhosts и.shosts # # в процессе аутентификации, основанной на проверке хоста. # # (RhostsRSAAuthentication или HostbasedAuthentication). # # Файлы /etc/hosts.equiv и /etc/ssh/shosts.equiv все еще # # используются. # # По умолчанию - “yes”. # # # IgnoreRhosts yes # # ## IgnoreUserKnownHosts #################################### # # # Указывает должен ли sshd игнорировать пользовательские # # "известные хосты" - файл ~/.ssh/known_hosts в процессе # # аутентификации, основанной на проверке хоста # # (RhostsRSAAuthentication или HostbasedAuthentication). # # По умолчанию - “no”. # # # ## PermitBlacklistedKeys ################################### # # # Указывает, стоит ли sshd принимать ключи, занесенные в # # черный список как скомпрометированные (known-compromised # # keys (см. ssh-vulnkey)). Если задано значение “yes” - # # попытки аутентификации с такими ключами будут занесены в # # журнал и приняты, если значение “no” - попытки # # аутентификации будут отвергнуты. # # По умолчанию - “no”. # # # ## PermitEmptyPasswords #################################### # # # В случае разрешенной аутентификации с помощью пароля, # # указывает, возможен ли вход с пустым паролем. # # По умолчанию - “no”. # # # PermitEmptyPasswords no # # ## PermitRootLogin ######################################### # # # Указывает, возможен ли ssh-вход под суперпользователем # # (root). Может принимать значения: # # “yes” - суперпользователь может зайти. Применяется # # текущая глобальная схема аутентификации. # # # # “without-password” - суперпользователь может зайти. # # Парольная аутентификация для него будет отключена. # # # # “forced-commands-only” - суперпользователь сможет зайти, # # пользуясь аутентификацией на основе публичного ключа и # # только если передаст необходимую к исполнению комнаду. # # Это удобно для осуществления резервного копирования, # # даже в том случае, когда нормальный (т.е. не через ssh) # # вход суперпользователя запрещен. Все остальные методы # # аутентификации для суперпользователя будут заблокированы.# # # # “no” - суперпользователь не может использовать ssh для # # входа в систему. # # # # Значение по умолчанию - “yes”. # # # PermitRootLogin yes # # ## Protocol ################################################ # # # Указывает, какой протокол должен использовать sshd. # # Возможные значения ‘1’ и ‘2’ - ssh1 и ssh2 # # соответственно. Возможна одновременная запись, при # # которой значения следует разделять запятыми. # # По умолчанию - “2,1”. # # Стоит отметить, что порядок следования протоколов в # # записи не задает приоритет, т.к. клиент выбирает какой # # из нескольких предложенных сервером протоколов ему # # использовать.Запись "2,1" абсолютно идентична # # записи "1,2". # # # Protocol 2 # # ## UsePAM ################################################## # # # Включает интерфейс PAM (Pluggable Authentication Module # # interface).Если задано значение "yes" - для всех типов # # аутентификации помимо обработки модуля сессии и аккаунта # # PAM будет использоваться аутентификация на основе # # запроса-ответа (ChallengeResponseAuthentication и # # PasswordAuthentication) Т.к. аутентификация # # запросов-ответов в PAM обычно выполняет ту же роль, # # что и парольная аутентификация, вам следует отключить # # либо PasswordAuthentication, либо # # ChallengeResponseAuthentication. Стоит отметить, что # # если директива UsePAM включена - вы не сможете запустить # # sshd от имени пользователя, отличного от root. # # Значение по умолчанию - “no”. # # # UsePAM yes # # ## PasswordAuthentication ################################## # # # Указывает, разрешена ли аутентификация с использованием # # пароля. # # По умолчанию - “yes”. # # # ## HostKey ################################################# # # # Указывает файл, содержащий закрытый хост-ключ, # # используемый SSH. По умолчанию - /etc/ssh/ssh_host_key # # для протокола ssh1 и /etc/ssh/ssh_host_rsa_key и # # /etc/ssh/ssh_host_dsa_key для протокола ssh2. Стоит # # отметить, что sshd не станет пользоваться файлом, # # который доступен кому либо, кроме пользователя. Можно # # использовать несколько файлов с ключами, ключи “rsa1” - # # для протокола ssh1 и “dsa”/“rsa” для протокола ssh2. # # # HostKey /etc/ssh/ssh_host_rsa_key HostKey /etc/ssh/ssh_host_dsa_key # # ############################################################ ########## Опции протокола SSH версии 1 (ssh1) ############# ############################################################ # Настоятельно НЕ РЕКОМЕНДУЕТСЯ использовать протокол ssh1.# # Протокол ssh2 намного более безопасен, чем ssh1 # ############################################################ # # ## KeyRegenerationInterval ################################# # # # Для протокола ssh1 - раз в определенное время # # автоматически генерируется новый временный ключ сервера # # (если он был использован). Это сделано для # # предотвращения расшифровки перехваченных сеансов,с целью # # позже зайти с параметрами этих сеансов на машину и # # украсть ключи. Такой ключ нигде не хранится (хранится в # # оперативной памяти). Данная директива указывает период # # "жизни" ключа в секундах, после которого он будет # # сгенерирован заново. Если значение задать равным 0 - # # ключ не будет генерироваться заново. # # По умолчанию значение - 3600 (секунд). # # # KeyRegenerationInterval 3600 # # ## RhostsRSAAuthentication ################################# # # # Указывает, нужна ли аутентификация на основе файлов # # rhosts или /etc/hosts.equiv совместно с успешной # # аутентификацией хоста через RSA. # # Актуально только для протокола ssh1. # # По умолчанию - “no”. # # # RhostsRSAAuthentication no # # ## RSAAuthentication ####################################### # # # Указывает, разрешена ли "чистая" RSA-аутентификация. # # Актуально только для протокола ssh1. # # По умолчанию - “yes”. # # # RSAAuthentication yes # # ## ServerKeyBits ########################################### # # # Определяет число бит во временном ключе сервера для # # протокола ssh1. Минимальное значение 512. # # Значение по умолчанию - 1024. # ServerKeyBits 768 # # ############################################################ ########### Опции протокола SSH версии 2 (ssh2) ############ ############################################################ # # ## Ciphers ################################################# # # # Указывает алгоритмы шифрования, разрешенные для # # протокола ssh2. Несколько алгоритмов должны быть # # разделены запятыми. Поддерживаемые алгоритмы: # # “3des-cbc”, “aes128-cbc”, “aes192-cbc”, “aes256-cbc”, # # “aes128-ctr”, “aes192-ctr”, “aes256-ctr”, “arcfour128”, # # “arcfour256”, “arcfour”, “blowfish-cbc”, “cast128-cbc”. # # По умолчанию используются: # # aes128-cbc,3des-cbc,blowfish-cbc,cast128-cbc,arcfour128, # # arcfour256,arcfour,aes192-cbc,aes256-cbc,aes128-ctr, # # aes192-ctr,aes256-ctr # # # ## HostbasedAuthentication ################################# # # # Указывает, разрешена ли аутентификация, основанная на # # проверке хоста. Проверяется rhosts или /etc/hosts.equiv, # # и в случае успеха, совместного с успешной проверкой # # публичного ключа, доступ разрешается. Данная директива # # одинакова с директивой RhostsRSAAuthentication и # # подходит только для протокола ssh2. # # По умолчанию - "no". # # # HostbasedAuthentication no # # ## MACs #################################################### # # # Указывает допустимый алгоритм MAC (message # # authentication code). Алгоритм MAC используется # # протоколом ssh2 для защиты целостности данных. Несколько # # алгоритмов должны быть разделены запятыми. # # По умолчанию используются: # # hmac-md5,hmac-sha1,[email protected],hmac-ripemd160, # # hmac-sha1-96,hmac-md5-96 # # # ## PubkeyAuthentication #################################### # # # Указывает, разрешена ли аутентификация на основе # # публичного ключа. Актуально только для протокола ssh2. # # По умолчанию - “yes”. # # # PubkeyAuthentication yes ############################################################ #################### Опции GSSAPI ########################## ############################################################ # # ############ Применимо только для протокола ssh2 ########### # # ## GSSAPIAuthentication #################################### # # # Указывает, разрешена ли аутентификация пользователя на # # основе GSSAPI. По умолчанию - "no", т.е. запрещена. # # # ## GSSAPIKeyExchange ####################################### # # # Указывает, разрешен ли обмен ключами, основанный на # # GSSAPI. Обмен ключам при помощи GSSAPI не полагается на # # ssh ключи при верификации идентичности хоста. # # По умолчанию - "no" - т.е. обмен запрещен. # # # ## GSSAPICleanupCredentials ################################ # # # Указывает, нужно ли автоматически уничтожать # # пользовательский кеш аутентификационных полномочий при # # завершении сеанса. # # По умолчанию - "yes" - т.е. нужно уничтожать. # # # ## GSSAPIStrictAcceptorCheck ############################### # # # Указывает, насколько строгой должна быть проверка # # идентичности клиента при аутентификации через GSSAPI. # # Значение "yes" заставляет клиента аутентифицироваться в # # принимающей хост-службе на текущем хосте. Значение "no" # # позволяет клиенту аутентифицироваться при помощи любого # # ключа служб. # # Значение по умолчанию - "yes". # # Стоит заметить, что задание значения "no" может # # сработать только с редкими библиотеками Kerberos GSSAPI. # # # ############################################################ ################### Опции Kerberos ######################### ############################################################ # # ## KerberosAuthentication ################################## # # # Указывает, требует ли пароль, предоставленный # # пользователем для аутентификации # # (PasswordAuthentication) валидации в Kerberos KDC. # # Для использования этой опции серверу нужно # # удостовериться в истинности KDC. (Тhe server needs a # # Kerberos servtab which allows the verification of the # # KDC’s identity) # # По умолчанию - “no”. # # # ## KerberosGetAFSToken ##################################### # # # Если активен AFS и пользователь получил Kerberos 5 TGT, # # пытаться ли получить AFS токен до того, как пользователь # # получит доступ к своей домашней папке. # # По умолчанию - “no”. # # # ## KerberosOrLocalPasswd ################################### # # # Указывает, как поступать в случае, если аутентификация # # через Kerberos завершилась неудачей. Если # # значение = "yes" - пароль будет проверен при помощи # # любого дополнительного локального механизма авторизации, # # например - /etc/passwd. # # По умолчанию - “yes”. # # # ## KerberosTicketCleanup ################################### # # # Указывает, нужно ли автоматически уничтожать файл с # # кешем тикета пользователя по завершению сеанса. # # По умолчанию - “yes”. # # # ############################################################ ################# Опции перенаправления #################### ############################################################ # # ## AllowAgentForwarding #################################### # # # Указывает, разрешить или запретить перенаправление # # ssh-agent"а. По умолчанию - “yes”, т.е. разрешить. # # Стоит заметить, что отключение перенаправления не # # увеличит безопасности пока пользователям также не будет # # запрещен shell доступ, т.к. они всегда смогут установить # # свои собственные аналоги агента. # # # ## AllowTcpForwarding ###################################### # # # Указывает, разрешить или запретить перенаправление TCP. # # По умолчанию - “yes”, т.е. разрешить. Стоит заметить, # # что как и в случае с AllowAgentForwarding отключение # # перенаправления не увеличит безопасности, пока у # # пользователей будет консольный доступ, т.к. они смогут # # установить свои аналоги. # # # # # ## GatewayPorts ############################################ # # # Указывает, разрешать ли удаленным хостам доступ к # # перенаправленным портам. По умолчанию, sshd слушает # # соединения к перенаправленным портам только на локальном # # интерфейсе (loopback). Это не дает другим удаленным # # хостам подсоединяться к перенаправленным портам. Можно # # использовать GatewayPorts, чтобы разрешить sshd это # # делать. Директива может принимать 3 значения: # # "no" - только loopback. # # "yes"- любые адреса. # # "clientspecified" - адреса указанные клиентом. # # # ## PermitOpen ############################################## # # # Указывает куда разрешено перенаправление TCP портов. # # Указание перенаправления должно принимать одну из # # следующих форм: # # PermitOpen host:port # # PermitOpen IPv4_addr:port # # PermitOpen :port # # Несколько записей можно задать, разделяя их пробелами. # # Аргумент “any” можно использовать для снятия всех # # запретов на перенаправление портов. По умолчанию любое # # перенаправление разрешено. # # # ## PermitTunnel ############################################ # # # Указывает, разрешено ли перенаправление tun-устройств. # # Может принимать значения: # # “yes” # # “point-to-point” (3-й сетевой уровень) # # “ethernet” (2-й сетевой уровень) # # “no” # # Значение “yes” разрешает одновременно и “point-to-point” # # и “ethernet”. По умолчанию - “no”. # # # ############################################################ ################## Опции журналирования #################### ############################################################ # # ## SyslogFacility ########################################## # # # Задает код объекта журнала для записи сообщений в # # системный журнал от sshd. Возможные значения: # # DAEMON # # USER # # AUTH # # LOCAL0 # # LOCAL1 # # LOCAL2 # # LOCAL3 # # LOCAL4 # # LOCAL5 # # LOCAL6 # # LOCAL7 # # По умолчанию используется AUTH. # # # SyslogFacility AUTH # # ## LogLevel ################################################ # # # Задает уровень детальности журнала sshd. # # Возможные варианты: # # SILENT # # QUIET # # FATAL # # ERROR # # INFO # # VERBOSE # # DEBUG # # DEBUG1 # # DEBUG2 # # DEBUG3 # # По умолчанию - INFO. # # DEBUG и DEBUG1 эквивалентны друг другу. # # DEBUG2 и DEBUG3 задают самые высокие уровни отладочного # # вывода. Запись логов с уровнем DEBUG угрожает # # приватности пользователей и не рекомендована. # # # LogLevel INFO # # ############################################################ ################### Перенаправление X11 #################### ############################################################ # # ## X11Forwarding ########################################### # # # Указывает, разрешено ли перенаправление графической # # подсистемы X11. Может принимать значения “yes” или “no”. # # По умолчанию - “no”. # # Внимание - включение простого перенаправления Х11 - # # большой риск как для сервера, так и для клиентов, т.к. в # # случае такого перенаправления прокси-дисплей sshd # # принимает соединения с любых адресов. Используйте # # директиву X11UseLocalhost для ограничения доступа к # # серверу перенаправления "иксов". Стоит отметить, что # # отключение перенаправления не даст гарантии, что # # пользователи не смогут перенаправлять Х11, т.к. имея # # консольный доступ они всегда установить свой # # перенаправлятель. Перенаправление Х11 будет # # автоматически отключено, если будет задействована # # директива UseLogin. # # # X11Forwarding yes # # ## X11UseLocalhost ######################################### # # # Указывает, должен ли sshd ограничить область # # перенаправления Х11 локальным loopback адресом, или # # должен разрешить любые адреса. По умолчанию - sshd # # "сажает" сервер перенаправления Х11 на локальный адрес # # и задает часть переменной окружения DISPLAY, отвечающую # # за имя хоста как “localhost”. Стоит заметить, что # # некоторые старые клиенты Х11 могут не работать с такими # # настройками. По умолчанию - "yes", т.е. перенаправление # # ограничено локалхостом, значение - “no” - отключает # # ограничения. # # # ## XAuthLocation ########################################### # # # Указывает полный путь к программе xauth. # # По умолчанию - /usr/bin/X11/xauth. # # # ## X11DisplayOffset ######################################## # # # Указывает номер первого дисплея, доступного sshd в # # качестве перенаправления X11. Это сделано для того, # # чтобы перенаправленные "иксы" не пересекались с # # реальными. По умолчанию - 10. # # # X11DisplayOffset 10 # # ############################################################ ################### Различные опции ######################## ############################################################ # # ## LoginGraceTime ########################################## # # # Время, по прошествии которого сервер отключает # # пользователя, если тот не смог удовлетворительно # # залогиниться. Значение 0 - разрешает пользователю # # логиниться бесконечно. По умолчанию - 120 (секунд). # # # LoginGraceTime 120 # # ## MaxAuthTries ############################################ # # # Указывает максимальное число попыток аутентификации, # # разрешенное для одного соединения. # # Как только число неудачных попыток превысит половину # # заданного значения, все последующие попытки будут # # заноситься в журнал. Значение по умолчанию - 6. # # # ## MaxSessions ############################################# # # # Указывает максимальное число одновременных подключений # # для каждого сетевого соединения. По умолчанию - 10. # # # ## MaxStartups ############################################# # # # Указывает максимальное число одновременных # # неавторизованных подключений к sshd. В случае, если # # число подключений превысит лимит - все дополнительные # # подключения будут сброшены до тех пор, пока текущие # # подключения не завершатся либо успешной авторизацией, # # либо истечением периода времени указанного в директиве # # LoginGraceTime. Значение по умолчанию - 10. # # Дополнительно, можно задать ранний сброс соединений, # # указав в качестве параметра три значения, разделенные # # двоеточием “start:rate:full” (например: "10:30:60"). # # sshd отклонит попытку соединения с вероятностью равной # # “rate/100” (т.е. в нашем примере - 30%), если уже # # имеется “start” (10) неавторизованных соединений. # # Вероятность увеличивается линейно и любые попытки # # соединения будут отклонены, если число неавторизованных # # соединений достигнет значения “full” (60). # # # ## Compression ############################################# # # # Указывает, разрешено ли сжатие данных. Может быть # # "yes" - сжатие разрешено. # # "delayed" - сжатие отложено до тех пор, пока # # пользователь успешно не аутентифицируется. # # "no" - сжатие запрещено. # # По умолчанию - "delayed". # # # ## UseLogin ################################################ # # # Указывает, должен ли использоваться login для # # интерактивного сеанса. Значение по умолчанию - “no”. # # Стоит отметить, что login никогда не использовался для # # выполнения удаленных команд. Так же заметим, что # # использование login сделает невозможным использование # # директивы X11Forwarding, потому что login не знает, что # # ему делать с xauth. Если включена директива # # UsePrivilegeSeparation - она будет отключена после # # авторизации. # # # ## UsePrivilegeSeparation ################################## # # # Указывает, должен ли sshd разделять привилегии. Если да # # - то сначала будет создан непривилегированный дочерний # # процесс для входящего сетевого трафика. После успешной # # авторизации будет создан другой процесс с привилегиями # # вошедшего пользователя. Основная цель разделения # # привилегий - предотвращение превышения прав доступа. # # Значение по умолчанию - “yes”. # # # UsePrivilegeSeparation yes # # ## StrictModes ############################################# # # # Указывает должен ли sshd проверить режимы доступа и # # владения пользовательских папок и файлов перед тем, как # # дать пользователю войти. Обычно это объясняется тем, что # # новички часто делают свои файлы доступными для записи # # всем подряд.По умолчанию - “yes”. # # # StrictModes yes # # ## AcceptEnv ############################################### # # # Указывает, какие переменные окружения, переданные # # клиентом будут приняты. См. опцию SendEnv в клиенте. # # Стоит заметить, что передача переменных возможна только # # для протокола ssh2. Переменные указываются по имени, # # можно использовать маски (‘*’ и ‘?’). Можно указывать # # несколько переменных через пробел, или разбить на # # несколько строк AcceptEnv. Будьте осторожны - некоторые # # переменные окружения могут быть использованы для обхода # # запрещенных пользовательских окружений. Пользуйтесь этой # # директивой аккуратно. По умолчанию никакие # # пользовательские переменные окружения не принимаются. # # # AcceptEnv LANG LC_* # # ## PermitUserEnvironment ################################### # # # Указывает, должен ли sshd воспринимать # # ~/.ssh/environment и опцию environment= в # # ~/.ssh/authorized_keys. По умолчанию - “no”. Стоит # # заметить, что разрешение обработки окружения может дать # # пользователям возможность обойти ограничения в некоторых # # конфигурациях, использующих такие механизмы, как # # LD_PRELOAD. # # # # # ## PidFile ################################################# # # # Указывает файл, содержащий идентификатор процесса # # (process ID, PID) демона SSH. # # По умолчанию - /var/run/sshd.pid # # # # # ## PrintLastLog ############################################ # # # Указывает, должен ли sshd выводить на экран дату и время # # последнего севнса при интерактивном входе пользователя. # # По умолчанию - “yes”. # # # PrintLastLog yes # # ## PrintMotd ############################################### # # # Указывает, должен ли sshd выводить на экран /etc/motd # # при интерактивном входе пользователя. На некоторых # # системах (например в Ubuntu) эта информация так же # # выводится на экран оболочкой. # # Значение по умолчанию - “yes”. # # # PrintMotd no # # ## Banner ################################################## # # # Указывает какой файл содержит текстовый баннер, который # # будет показан пользователю ПЕРЕД процедурой # # аутентификации. Опция доступна только для протокола ssh2.# # По умолчанию - не показывает ничего. # # В Ubuntu файл issue.net содержит фразу Ubuntu {version}, # # например, для karmic это "Ubuntu 9.10". Можно # # использовать для дезориентации возможных атакующих, # # написав туда например "My D-Link Interet Router" =) # # # Banner /etc/issue.net # # ## ChrootDirectory ######################################### # # # Если указан - предоставляет путь, по которому будет # # выполнен chroot после аутентификации. Путь и все его # # содержимое должны соответствовать принадлежащим # # суперпользователю папкам и быть не доступными для # # записи другими пользователями. # # В пути могут быть указаны метки, подставляемые в # # процессе аутентификации: # # %% - заменяется литералом "%" # # %h - заменяется домашней директорией # # аутентифицируещегося пользователя # # %u - заменяется именем аутентифицируещегося пользователя # # chroot-папка должна содержать все необходимые файлы и # # папки для пользовательского сеанса. Для интерактивного # # сеанса нужны как минимум: # # оболочка, обычно - sh # # базовые устройства в /dev, такие как: # # null, zero, stdin, stdout, stderr, arandom и tty # # для сеанса передачи данных при помощи sftp никаких # # дополнительных настроек не нужно, если используется # # внутренний процесс sftp сервера. См. Subsystem для # # большей информации. По умолчанию chroot не выполняется. # # # ## ForceCommand ############################################ # # # Заставляет выполняться указанную команду. Игнорирует # # любые команды переданные клиентом или записанные в # # ~/.ssh/rc. Команда вызывается из пользовательской # # оболочки с опцией -с. Подходит для запуска оболочки, # # команды или подсистемы. Наиболее полезна внутри блока # # Match. Команда, изначально переданная клиентом, хранится # # в переменной окружения SSH_ORIGINAL_COMMAND. Если # # указать команду "internal-sftp", будет запущен # # внутренний sftp сервер, которому не нужны дополнительные # # файлы и папки, описанные в директиве ChrootDirectory. # # # ## Subsystem ############################################### # # # Определяет и настраивает внешнюю подсистему (например # # демона передачи файлов - file transfer daemon). # # Аргументами служат имя и команда (с возможными # # аргументами), которая будет выполнена во время запроса # # на подсистемы. Команда sftp-server запускает “sftp” - # # подсистему передачи файлов. Дополнительно можно указать # # в качестве подсистемы “internal-sftp” - что запустит # # внутренний sftp сервер. Это может значительно упростить # # настройку в случае использования директивы # # ChrootDirectory По умолчанию никаких подсистем # # не вызывается. Актуально только для протокола ssh2. # # # Subsystem sftp /usr/lib/openssh/sftp-server # # ############################################################ ##################### Блок Match ########################### ############################################################ # # # Специально вынес в конец файла, чтобы было удобнее # # писать Match правила. # # MadKox. # # # # Директива Match представляет собой начало условного # # блока. Если выполнены все критерии, указанные в строке # # Match, директивы в последующих строках блока выполняются,# # позволяя обойти значения глобальных директив файла # # sshd_config для случая, являющегося критерием директивы # # Match. Блоком считаются все строки, идущие после строки # # с критерием (Match - строки) до следующей match-строки # # или до конца файла. Аргумент директивы Match - одна или # # несколько пар записей критериев. Возможные виды записей: # # User # # Group # # Host # # Address # # Записи могут содержать как одиночные значения # # (например User=user), так и несколько значений, # # разделенные запятыми (User=user1,user2). Так же могут # # быть использованы регулярные выражения, описанные в # # секции PATTERNS файла ssh_config. Записи в критерии # # Address могут содержать адреса в нотации CIDR # # (Адрес/Длинна маски, например “192.0.2.0/24” или # # “3ffe:ffff::/32”). Стоит заметить, что представленная # # длинна маски должна соответствовать адресу, и слишком # # длинные/короткие для адреса не будут работать. # # В качестве директив Match может использовать только # # определенный набор директив: # # AllowTcpForwarding # # Banner # # ChrootDirectory # # ForceCommand # # GatewayPorts # # GSSAPIAuthentication # # HostbasedAuthentication # # KbdInteractiveAuthentication # # KerberosAuthentication # # MaxAuthTries # # MaxSessions # # PasswordAuthentication # # PermitOpen # # PermitRootLogin # # RhostsRSAAuthentication # # RSAAuthentication # # X11DisplayOffset # # X11Forwarding # # X11UseLocalHost #

Можно скопировать приведенный выше текст в ваш собственный sshd_config и использовать в дальнейшем для настройки.

Сам по себе, неправильно настроенный SSH -сервер - огромная уязвимость в безопасности системы, т. к. у возможного злоумышленника есть возможность получить практически неограниченный доступ к системе. Помимо этого, у sshd есть много дополнительных полезных опций, которые желательно включить для повышения удобства работы и безопасности .

Port, ListenAddress и AddressFamily

Эти три параметра определяют, на каких портах и адресах ваш сервер будет ждать входящие соединения. Во-первых, имеет смысл по возможности ограничить семейство обрабатываемых адресов реально используемыми, т. е. если вы используете только IPv4 - отключите IРv6, и наоборот. Сделать это можно при помощи параметра AddressFamily, например (для разрешения IPv4 и запрета IPv6):

AddressFamily inet

Во-вторых, желательно сменить стандартный порт (22) на котором слушает sshd. Это связано с тем, что многочисленные сетевые сканеры постоянно пытаются соединиться с 22-м портом и как минимум получить доступ путем перебора логинов/паролей из своей базы. Даже если у вас и отключена парольная аутентификация - эти попытки сильно засоряют журналы и (в большом количестве) могут негативно повлиять на скорость работы ssh сервера. Если же вы по какой либо причине не желаете изменить стандартный порт вы можете использовать как различные внешние утилиты для борьбы брутфорсерами, например fail2ban , так и встроенные, такие как MaxStartups .
Задать порт можно как абсолютным значением для всех интерфейсов при помощи директивы Port , так и конкретным значением для каждого интерфейса, при помощи директивы ListenAddress . Например:

Port 2002

ListenAddress 192.168.0.1:2003 ListenAddress 192.168.1.1:2004

Запрещение удаленного доступа для суперпользователя

По умолчанию root-доступ запрещен по паролю (по ключу - можно) - опция PermitRootLogin установлена в without-password . Но, при условии, что по умолчанию в Ubuntu пользователь, добавленный при установке системы имеет возможность решать все административные задачи через sudo, создавать возможность root доступа к системе через ssh - выглядит неразумно (даже при аутентификации по ключу). Рекомендуется совсем отключить. эту опцию, или применять ее только в режиме forced-commands-only . Отключить root-доступ можно так:

PermitRootLogin no

Парольная аутентификация

Разрешенная по умолчанию парольная аутентификация является практически самым примитивным способом авторизации в sshd. С одной стороны это упрощает конфигурацию и подключение новых пользователей (пользователю достаточно знать свой системный логин/пароль), с другой стороны пароль всегда можно подобрать, а пользователи часто пренебрегают созданием сложных и длинных паролей. Специальные боты постоянно сканируют доступные из интернета ssh сервера и пытаются авторизоваться на них путем перебора логинов/паролей из своей базы. Настоятельно не рекомендуется использовать парольную аутентификацию. Отключить ее можно так:

PasswordAuthentication no

Если по каким либо причинам вам все таки хочется использовать парольную аутентификацию - позаботьтесь о том, чтобы никто не мог авторизоваться с пустым паролем. Для этого задайте директиву PermitEmptyPasswords:

PermitEmptyPasswords no

Протоколы SSH1 и SSH2

Как уже было сказано, sshd может работать с протоколами SSH1 и SSH2. При этом использование небезопасного SSH1 крайне не рекомендуется. Заставить sshd работать только с протоколом SSH2 можно так:

Аутентификация на основе SSH2 RSA-ключей

Наиболее предпочтительным способом авторизации является аутентификация на основе SSH2 RSA-ключей. При таком способе пользователь генерирует на своей стороне пару ключей, из которой один ключ является секретным, а другой публичным. Публичный ключ копируется на сервер и служит для проверки идентичности пользователя. Более подробно про создание пары ключей и способы размещения их на сервере см. в описании SSH -клиента. Включить аутентификацию по публичному ключу можно так:

PubkeyAuthentication yes

Сервер должен знать, где ему следует искать публичный ключ пользователя. Для этого применяется специальный файл authorized_keys . Синтаксис его может быть следующим:

# Коментарии записываются только с новой строки # общий вид записей в файле authorized_keys # [опции] тип_ключа(ssh-rsa или ssh-dss) очень_длинная_строка_непонятная_простому_человеку [логин@хост] ssh-rsa AAAAB3Nza...LiPk== [email protected] from="*.sales.example.net,!pc.sales.example.net" ssh-rsa AAAAB2...19Q== [email protected] command="dump /home",no-pty,no-port-forwarding ssh-dss AAAAC3...51R== example.net permitopen="192.0.2.1:80",permitopen="192.0.2.2:25" ssh-dss AAAAB5...21S== tunnel="0",command="sh /etc/netstart tun0" ssh-rsa AAAA...== [email protected]

Можно указать как один общий файл с ключами, так и по файлу на каждого пользователя. Последний способ является более удобным и безопасным, т. к. можно во-первых указывать разные комбинации ключей для каждого пользователя , а во-вторых ограничить доступ к публичному ключу пользователя. Задать файл с ключами можно при помощи директивы AuthorizedKeysFile:

AuthorizedKeysFile %h/.ssh/my_keys

для схемы пользователь - файл
или

AuthorizedKeysFile /etc/ssh/authorized_keys

для схемы с общим файлом. По умолчанию SSH -клиент ищет ключи в файле ~/.ssh/authorized_keys .

Еще про безопасность

Дополнительные настройки

Пользователи и группы.

Если у вас на сервере «живет» много пользователей, а доступ через ssh вы хотите разрешить только нескольким из них - вы можете использовать директивы DenyUsers , AllowUsers , DenyGroups , и AllowGroups . Более подробно про эти директивы см. комментарии в примере sshd_config .

Опции определения состояния соединения

По умолчанию из способов определения состояния соединения включен только способ проверки TCP соединения - TCPKeepAlive , однако, sshd умеет определять состояния соединения и более удобными и безопасными способами. Подробнее см. соответствующий раздел в примере sshd_config .

Производительность. MaxStartups

Перенаправление портов

Перенаправление X11

На сервере в файле /etc/ssh/sshd_config выставить параметр (по умолчанию включено):

ForwardX11 yes

На клиенте в файле /etc/ssh/ssh_config выставить параметры (по умолчанию выключено):

ForwardAgent yes ForwardX11 yes

Запускать на клиенте можно так ssh yurauname@serverip firefox . Или сначала заходим ssh yurauname@serverip потом запускаем, например sudo synaptic .

SFTP

В sshd по умолчанию встроен SFTP-сервер. Протокол SFTP (SSH File Transfer Protocol) - SSH -протокол для передачи файлов. Он предназначен для копирования и выполнения других операций с файлами поверх надёжного и безопасного соединения. Как правило, в качестве базового протокола, обеспечивающего соединение, и используется протокол SSH2. Для того чтобы включить поддержку SFTP добавьте в sshd_config строку

Subsystem sftp /usr/lib/openssh/sftp-server

По умолчанию поддержка SFTP включена.

Использование критериев. Директива Match

Настройка SSH-клиента

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

ssh-keygen -t rsa

Получаем предложение ввести пароль для защиты файла ключа (оказывается полезным при попадании файла в чужие руки). Если мы собираемся по SSH выполнять скрипты, то оставляем пустым. Передаём публичный ключ на сервер командой

Ssh-copy-id -i ~/ .ssh/ id_rsa.pub user@ server

Всё, можно заходить.

Когда ssh работает на нестандартном порту:

Ssh-copy-id -i ~/ .ssh/ id_rsa.pub "-p port user@server"

Если возникает ошибка: Bad port "umask 077; test -d .ssh || mkdir .ssh ; cat >> .ssh/authorized_keys"

попробуйте взять параметры в кавычки:

Ssh-copy-id "-i /home/user/.ssh/id_rsa.pub "-p port user@server""

Удобно при подключени на удалённой системе пользоваться утилитой screen .

Настройка удаленной ssh-директории в Nautilus

Монтирование удаленной директории с помощью sshfs

Монтирование удаленного каталога в локальный каталог

sshfs user@ hostingserver.ru:/ home/ userdir ~/ sshfsdir

Размонтирование

Fusermount -u ~/ sshsfdir

SSH aliases

При использовании нескольких серверов с различными параметрами доступа (нестандартный порт, длинное имя хоста, логин отличный от локального, и т.п.) порой утомительно вводить все настройки подключения каждый раз заново. Для облегчения этого можно использовать aliases.

Настройки хранятся в ~/.ssh/config для одного пользователя и в /etc/ssh/ssh_config глобально для всех пользователей.

Пример конфига. Описано может быть множество серверов. Подробнее в man ssh_config (не путать с sshd_config )

Host AliasName # Произвольное имя хоста HostName 1.2.3.4 # Можно указывать как IP, так и hostname (если работает DNS) User YourUserName # Если пользователь не совпадает с локальным пользователем Port YourSSHPort # Если нестандартный порт

После этого можно подключаться к серверу командой

ssh AliasName

ssh-agent

Диагностика проблем подключения

Анализ лога подключения:

ssh -vvv user@ host

Анализ конфигурационных файлов клиента и сервера.

Расположение конфигурационных файлов можно узнать из

Man ssh man sshd

Использование смарт-карт

1. Создание сертификата и экспорт открытого ключа, а также клиентская часть на Windows + Putty SC описано на сайте: http://habrahabr.ru/post/88540/ Описанное там дополнение Key Manager доступно только в старых версиях Firefox. Проверено на версии 3.5 для Windows. Прямая ссылка на дополнение: https://addons.mozilla.org/ru/firefox/addon/key-manager/

2. Подготовка сервера. Вам необходимо убедиться что в конфигурации sshd разрешена аутентификация при помощи публичных ключей. Для этого необходимо в файле «sshd_config» указать значение параметра «PubkeyAuthentication» в «yes». Затем в файл «~/.ssh/authorized_keys» добавляем наш публичный ключ полученный ранее (одной строкой). Обратите внимание, файл «.ssh/authorized_keys» находится в домашнем каталоге того пользователя, который потом будет логиниться по публичному ключу.

3. Клиентская часть на Linux. Потребуется пересборка пакета OpenSSH без параметров. Рекомендуется только указать префиксы каталогов, например –prefix=/usr. Также следует учесть, что файлы конфигов будут в /usr/etc. Перед началом необходимы пакеты: opensc-lite-devel, zlib-devel, openssl-devel. Устанавливаем драйвер смарт-карты. Для удобства в конфиге ssh_config (не путать с sshd_config) указать путь к библиотеке pkcs: PKCS11Provider=<путь к библиотеке>

4. На клиенте запускаем ssh user@host Если смарт-карта (токен) подключена, будет запрошен пароль и выполнен вход в сессию SSH .

Возможные проблемы при использовании

Привычная комбинация клавиш Ctrl + S , используемая во многих редакторах для сохранения исправлений, при работе в терминале с ssh-cервером приведёт к выполнению команды XOFF что внешне напоминает зависание сессии. Однако это не так. Сервер продолжает принимать вводимые символы и команды, но не выводит это на экран. Что бы выйти из такого затруднительного положения достаточно применить комбинацию Ctrl + Q , тем самым включив режим XON обратно.

Ссылки

Т. е. user1 может быть прописан как у себя - в файле /home/user1/.ssh/keys) так и у другого пользователя, что позволит ему выполнять со своего компьютера вход как «под собой», так и под «другим»

Часть 2.

Перед тем как начнём, давайте создадим нового пользователя с root правами.

Укажем права пользователю test командой

usermod -a -G sudo test

Чтобы убедиться, что пользователь test был добавлен в группу sudo, можно выполнить следующую команду:

Теперь настраим удаленный доступ к серверу по ssh (командная строка), как по локальной сети, так и по интернету

Установим ssh

sudo apt-get install openssh-server

После установки нам необходимо настроить безопасность соединения и непосредственный доступ. Зайдем в файл с настройками

sudo nano /etc/ssh/sshd_config

По умолчанию, ssh использует порт 22. Заменим его на нестандартный, это повысит безопасность нашего доступа. Порт заменим например на 2200

При подключении по ssh, наш сервер потребует вместо пароля ключ RSA, а не пароль. Что бы этого не произошло, в параметре RSAAuthentication и PubkeyAuthentication, вписываем "NO". Так же запрещаем доступ пользователю ROOT, для этого нужно раскомментировать параметр Authetication: и в параметре PermitRootLogin вписать "NO"

Теперь пропишем доступ пользователям

В строке AllowUsers прописываем пользователей через пробел в виде юзер@хост, т. е. указываем какой пользователь откуда может подключаться. Можно использовать знак *

Пропишем пользователю test права доступа и разберёмся в них.

test@* - пользователь test может подключаться откуда угодно
[email protected].* - пользователь test может подключаться только находясь в 192.168.0.0 подсети
[email protected] - пользователь test может подключиться только с ip адреса 192.168.0.104
*@192.168.0.* - все пользователи могут подключаться находясь в 192.168.0.0 подсети

Так же можно запретить доступ определённым пользователям (например пользователю test2), для этого нужно вписать ниже

Запускаем

sudo /etc/init.d/ssh start

Ssh мы настроили. Теперь откроем к нему доступ. Для этого откроем доступ к порту 2200.

В прошлой части мы устанавливали firewall командой arno-iptables-firewall, теперь нужно внести туда изменения. По этому перенатроим его.

sudo dpkg-reconfigure arno-iptables-firewall

Запустилась настройка

Вписываем порт, который нужно открыть. Так же в этом окне можно вписать и другие порты, если они нуждаются в открытии.

В следующем окне, так же вписваем порт 2200.

Как только вписали порты, можно везде нажимать ENTER и перезагрузить Файрвол.

После этого порт ssh будет доступен из сети

Для повышения безопасности ssh соединения можно настраиваем утилиту denyhosts. Утилита представляет собой python-скрипт, который анализирует файл /var/log/auth.log на наличие записей о несанкционированных попытках входа на сервер по ssh и добавляет ip-адреса, с которых осуществлялись эти попытки в файл /etc/hosts.deny, с которых запрещен вход по ssh.

Установим командой

sudo aptitude install denyhosts

Сразу после установки утилита просканирует файл /var/log/auth.log и добавит ip-адреса, с которых осуществлялся подбор паролей, в /etc/hosts.deny. На сканирование потребуется время, если в файле /var/log/auth.log уже много таких записей.

После установки нужно подправить конфигурационный файл

sudo nano /etc/denyhosts.conf

Скорректируем настройку PURGE_DENY на 3 часа. А то мы можем заблокировать доступ самому себе, введя несколько раз неверный пароль.

Ещё, для контроля, нужно указать адрес электронной почты для рассылки уведомлений о неудачных попытках доступа к серверу:

ADMIN_EMAIL = [email protected] вместо [email protected] указываем свою почту

Для того чтобы новые настройки вступили в силу, нужно перезапустить службу denyhosts:

sudo service denyhosts restart

P.S. Если вам понадобиться сменить пароль на учетной записи. Введите команду

passwd user - где user это имя пользователя

P.S.S. Если возникнут проблемы с кодирвкой, то покопайтесь в настройках клиентской программы shh

Самая популярная программа для работы по ssh, программа PuttY.