SSH — доступ, настройка программ. Подключение к виртуальному серверу по SSH и SFTP

" Вы начинающий админ и хотите, например, поднять свой веб сервер. Идете в интернет, находите подходящую Вам статью и вперед! Давайте обратим внимание на один Важный момент, практически во всех этих статьях дается минимум команд для запуска необходимых служб и сервисов. Хорошо - заработало! А все ли Вы сделали для того, чтобы работать не перестало? Используете SSH через интернет? Почему никто в своих статьях не освещает проблем, которые могут получить новоиспеченные админы с таким подходом к настройке сервера, ведь именно для новичков и написаны статьи. Для того, чтобы Вы вовремя обратили внимание на вопрос безопасности, я обязательно буду делать пометки и ссылки в своих статьях на данный материал. Предупрежден – вооружен! "

Итак, SSH (secure shell) – безопасный сервер терминалов, предоставляет удаленный доступ к системе. Безопасный, т.к. весь трафик между клиентом и сервером шифруется. А так ли он безопасен с настройками по умолчанию? Если Вы имеете сервер с возможностью подключения по SSH через интернет, обязательно найдутся желающие подобрать пароль для входа. Думаю, не стоит объяснять, что возможный злоумышленник сможет получить практически неограниченный доступ к системе.

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

Установка SSH сервера в Ubuntu.

Установка SSH сервера в Ubuntu выполняется следующей командой:

Sudo apt-get install ssh openssh-server

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

Sudo service ssh stop | start | restart

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

Настройки безопасности SSH сервера.

Протокол по умолчанию.

Опять же в современных дистрибутивах по умолчанию реализуется протокол SSH2. Если в Вашем случае указано нечто вроде:

Protocol 2,1

Необходимо оставить только 2:

Protocol 2

Использование небезопасного протокола SSH1 не рекомендуется.

По умолчанию в последних релизах Ubuntu, доступ пользователя root через SSH ограничен.

PermitRootLogin without-password

PermitRootLogin no

С такими настройками пользователь root не сможет авторизоваться по SSH.

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

Еще немного о root в Ubuntu, созданный по умолчанию пользователь (при установке системы) может решать все административные задачи через sudo. Активировать пользователя root для доступа к системе мне кажется не обоснованным решением.

Предоставление доступа только указанным пользователям или группам.

Представим, что на Вашем сервере есть определенное количество пользователей, но предоставлять доступ по SSH необходимо только некоторым. Так давайте ограничим круг пользователей имеющих доступ:

AllowUsers user1 user2

Также Вы можете указать необходимую группу, например administrators:

AllowGroups administrators

Запретите доступ с "пустыми" паролями.

Вы должны явно запретить удаленный доступ с использованием пустых паролей:

PermitEmptyPasswords no

Изменение стандартного порта.

SSH по умолчанию работает на 22 порту. Соответственно основная масса атак будет направлена именно на этот порт, далее используя подбор имени пользователя и пароля, будут происходить попытки получить доступ к серверу. Мы уже исключили самое известное имя пользователя из базы возможного злоумышленника (root) и разрешили доступ только определенным пользователям, теперь сократим количество возможных атак (боты, ищущие уязвимости на стандартных портах), изменив порт, используемый по умолчанию (новый порт должен быть свободен!).

Изменим, к примеру, на:

Port 2220

Стоит понимать, что изменение порта никак не поможет Вам при целенаправленной атаке brute-force (подбор пароля). Злоумышленник может, например, пройтись сканером портов по IP адресу, на котором распложен Ваш сервер, в результате он получит список всех открытых портов.

Также помните, что теперь для подключения к серверу помимо IP адреса Вам нужно указать и номер порта.

Действительно рабочим вариантом защиты от перебора является использование для аутентификации SSH2 RSA-ключей. При таком способе пользователь генерирует пару ключей, из которой один ключ является секретным, а другой публичным. Публичный ключ находится на сервере и служит для проверки идентичности пользователя. Плюс ко всему связку ключ – публичный ключ можно обезопасить парольной фразой, повысив криптостойкость авторизации. Логика проста, не используете для авторизации пароль – подбирать нечего!

Заходим в систему под тем пользователем, которому будем настраивать доступ по SSH к серверу.

Сгенерируем RSA ключ длинной 4096, Вам будет предложено указать место хранения, оставим по умолчанию (/home/UserName/.ssh/id_rsa), также будет предложено задать пароль на создаваемый ключ. Если пароль не указывать, то во время аутентификации на сервере по сертификату вводить его не придется, это менее надежно. Рекомендую Вам указать пароль:

Ssh-keygen -t rsa -b 4096

В указанной директории будет создана пара ключей:

id_rsa.pub - публичный

id_rsa – приватный

Проверим, созданы ли файлы:

Cd ~/.ssh ls -al

Установим права на папку и файлы:

Sudo chmod 0700 ~/.ssh/ sudo chmod 0600 ~/.ssh/id*

Приватный ключ необходимо передать клиенту защищенным образом и удалить с сервера во избежание компрометации ключей.

Ключ id_rsa передается клиенту:

/home/UserName/.ssh/id_rsa

После чего удаляется с сервера:

Sudo rm /home/UserName/.ssh/id_rsa

Создадим файл authorized_keys (находимся в системе под тем же пользователем “UserName”, для которого создавался сертификат) и скопируем в него содержимое файла id_rsa.pub , определим владельца и выставим права на директорию и файл.

Cd ~/.ssh sudo touch authorized_keys sudo chown UserName:UserName authorized_keys sudo cat id_rsa.pub >> authorized_keys sudo chmod 0700 ~/.ssh/ sudo chmod 0600 ~/.ssh/authorized_keys

Проверим, что текст скопировался:

Sudo cat /home/UserName/.ssh/authorized_keys

Если текст успешно скопирован, можно удалить публичный ключ:

Sudo rm /home/UserName/.ssh/id_rsa.pub

Sudo nano /etc/ssh/sshd_config

Необходимо раскоментировать строки и выставить параметры следующим образом:

# разрешаем авторизацию при помощи ключей PubkeyAuthentication yes # Путь, где будут находиться ключи, с которыми можно соединяться для каждого пользователя свой файл в его директории. AuthorizedKeysFile %h/.ssh/authorized_keys

Перезапустим SSH сервер:

Sudo service ssh restart

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

Внимание перед отключением аутентификации по паролю убедитесь в возможности доступа по ключу

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

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

Для этого нам потребуется программа PuTTYgen .

Загружаем файл приватного ключа "Conversions - Import Key ".

Если Вы установили, пароль вводим его.

Выбираем "Save private key " и сохраняем полученный ppk файл. Хранить его стоит в месте, где он не сможет быть скомпрометирован.

Открываем программу PuTTY и настраиваем соединение:

Session - Host Name (or IP Address) IP адрес хоста, на котором настраивался SSH Сервер;

Session - Port Порт, указанный в настройках SSH сервера;

Session - Saved Session Название сессии (соединения);

Connection - Data - Autologin username Имя пользователя;

Connection - SSH - Auth - Private key file for authentication Путь к ppk файлу;

Session - Save Сохраняем сессию;

Session - Saved Session (выбираем нашу сессию) - Load - Open - Сессия должна запуститься;

Вводим пароль и нажимаем Enter, после этого попадаем в систему.

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

Для того, чтобы закрыть доступ пользователю UserName к Хосту по сертификату, перейдем в папку где хранится его сертификат:

Cd ~/.ssh

Удалим файл его публичного сертификат authorized_key с сервера OpenSSH, если же вы неосмотрительно не удаляли файлы id_rsa.pub и id_rsa , удалите их. Просматриваем содержимое каталога коммандой "ls".

Удаляем необходимые файлы:

Sudo rm authorized_key id_rsa.pub id_rsa

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

В примере ниже это время ограничено до 30 секунд:

LoginGraceTime 30

Таймаут при отсутствии активности соединения.

Автоматическое отключение соединения после определенного времени, в течение которого зафиксировано бездействие в консоли.

ClientAliveCountMax – Параметр указывает на полное количество сообщений, отсылаемых ssh-сервером для распознавания активности ssh-клиента. По умолчанию это 3.

ClientAliveInterval – Параметр указывает на время ожидания в секундах. По истечению ssh-сервер отошлет сообщение-запрос клиенту. По умолчанию значение этого параметра – 0. Сервер не отсылает сообщение для проверки.

Отключение ssh-клиента автоматически после 5 минут (300 секунд):

ClientAliveInterval 300 ClientAliveCountMax 0

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

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

Оглавление:

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

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

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

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

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

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

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

Если вы знаете пароль пользователя, то процесс можно упростить. Команда 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 вопит, значит вы не на тот сервер ломитесь (например, в сети появился ещё один компьютер с тем же 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.

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

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

Собственно, исключение: 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 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).

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

Host * User root Compression yes

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

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

Теория: Графические приложения в юникс обычно используют 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

Особые проблемы доставляют закрытые порты. То джаббер прикроют, то 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)

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

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

Комментарии: Две серые сети. Первая сеть напоминает типичную офисную сеть (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» не отличим от обычного трафика компьютера А.

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

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

Легко понять, что в таких условиях невозможно никаким 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 Добавить метки

SSH (Secure Shell) — это сетевой протокол, предназначенный для удалённого управления сервером и передачи данных по зашифрованным TCP соединениям. Большинство хостингов , даже виртуальных, сегодня предоставляет доступ как по FTP, так и по SSH. На мой взгляд, это здорово, SSH намного удобнее и безопаснее в использовании.

Настройка SSH

Настройка будет происходить под выделенный сервер, VDS, VPS на Debian, Ubuntu. Конфигурационный файл располагается тут: /etc/ssh/sshd_config .
Если у вас обычный хостинг, всё и так должно быть настроено как надо, переходите к разделу .

По умолчанию, демон SSHD (именно в него мы вносим изменения) не нуждается в каких-либо настройках и работает нормально. Мы внесём лишь пару небольших изменений с целью ограничить доступ нежелательных лиц к серверу.

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

Как ограничить доступ по SSH

Все изменения вносятся в /etc/ssh/sshd_config
Чтобы изменения вступили в силу, необходимо

Сменить порт

Теперь при авторизации вам нужно вместо стандартного 22 порта указывать 9724 .
Способ очень простой и действенный против большинства простых ботов хакеров, которые стучатся в стандартные порты. Тут главное не создать конфликт с другими службами и подобрать заведомо неиспользуемое число.

Запретить связь по старому протоколу

Здесь мы определяем, что связь возможна только по протоколу v2

Если вы авторизованы не под root , перед всеми консольными командами нужно добавлять sudo — расшифровывается как Substitute User and DO — подмени юзера и делай (под ним). Например, позволяет исполнять команды от имени суперпользователя root .

Уменьшить число попыток авторизации

Количество попыток ввода пароля. По умолчанию 6. При неудачном переборе сеанс связи обрывается.

Уменьшить время ожидания авторизации

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

Закрыть доступ по IP

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

1. Открываем /etc/hosts.allow и добавляем туда SSHD: 192.168.1.1

   где 192.168.1.1 — ваш IP. Если у вас динамический IP, определите IP с маской подсети и запишите Вашу подсеть вместо IP, например:

   SSHD: 192.168.0.0/16

2. Открываем /etc/hosts.deny и добавляем туда: SSHD: ALL

Ещё один способ ограничения доступа по IP

Можно воспользоваться следующей директивой:

AllowUsers = *@1.2.3.4

Здесь мы разрешаем доступ только для IP 1.2.3.4

Авторизация SSH по ключам

Намного безопаснее, удобнее и правильнее будет настроить ssh авторизацию без пароля. Для этого будет использоваться авторизация по ключу.

Итак, вот инструкция:

Подключение настроено. Если что-то сделали не так, при авторизации появится ошибка Server refused our key , то есть Сервер не принял наш ключ . В этом случае пройдитесь по всем пунктам последовательно и поищите ошибку

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

Порт SSH: что это и зачем нужно?

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

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

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

Стандартный порт SSH

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

Так, например, если в качестве клиента применяется Jabber, для корректного соединения, шифрования и передачи данных должен использоваться порт 443, хотя в стандартном варианте устанавливается порт 22.

Чтобы перенастроить маршрутизатор с выделением для определенной программы или процесса необходимых условий, придется выполнить проброс портов SSH. есть назначение определенного доступа для отдельно взятой программы, которая использует подключение к Интернету, вне зависимости от того, какие настройки имеет текущий протокол обмена данными (IPv4 или IPv6).

Техническое обоснование

Как уже понятно, стандартный порт SSH 22 используется не всегда. Однако тут нужно выделить некоторые характеристики и параметры, используемые при настройке.

Почему конфиденциальность передачи зашифрованных данных предполагает использование протокола SSH в виде исключительно внешнего (гостевого) пользовательского порта? Да только потому, что применяемое туннелирование позволяет использовать так называемую удаленную оболочку (SSH), получить доступ к управлению терминалом посредством удаленного входа в систему (slogin), а также применять процедуры удаленного копирования (scp).

Кроме того, SSH-порт может быть задействован и в том случае, когда у пользователя возникает необходимость выполнения удаленных сценариев X Windows, что в самом простом случае представляет собой передачу информации с одной машины на другую, как уже говорилось, с принудительным шифрованием данных. В таких ситуациях самым необходимым станет использование алгоритмов на основе AES. Это есть алгоритм симметричного шифрования, которое изначально предусмотрено в технологии SSH. И использовать его не только можно, но и нужно.

История реализации

Сама технология появилась достаточно давно. Оставим пока в стороне вопрос того, как сделать проброс портов SSH, а остановимся на том, как все это работает.

Обычно все сводится к тому, чтобы использовать прокси на основе Socks или применить туннелирование VPN. В случае если какое-то программное приложение умеет работать с VPN, лучше предпочесть именно этот вариант. Дело в том, что практически все известные на сегодня программы, использующие интернет-траффик, с VPN работать могут, а настройка маршрутизации особого труда не составляет. Это, как и в случае с прокси-серверами, позволяет оставить внешний адрес терминала, с которого в данный момент производится выход в сеть, неузнанным. То есть в случае с прокси адрес меняется постоянно, а в варианте VPN остается неизменным с фиксацией определённого региона, отличного от того, где действует запрет доступа.

Сама же технология, когда открывается порт SSH, была разработана еще в 1995 году в Технологическом университете Финляндии (SSH-1). В 1996 году было добавлено усовершенствование в виде протокола SSH-2, который получил достаточно большое распространение на постсоветском пространстве, хотя для этого, равно как и в некоторых странах Западной Европы, иногда необходимо получение разрешения на использование такого туннеля, причем от государственных органов.

Основным преимуществом открытия SSH-порта, в отличие от telnet или rlogin, считается применение цифровой подписи RSA или DSA (использование пары в виде открытого и зарытого ключа). Кроме того, в данной ситуации может использовать так называемый сеансовый ключ на основе алгоритма Диффи-Хеллмана, который подразумевает применение симметричного шифрования на выходе, хотя и не исключает использование алгоритмов асимметричного шифрования в процессе передачи данных и их приема другой машиной.

Серверы и оболочки

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

В этом смысле нужно обратить внимание на вопрос передачи информации и аутентификации. Во-первых, сам протокол оказывается достаточно защищенным от так называемого снифинга, представляющего собой самую обычную «прослушку» траффика. SSH-1 оказался беззащитным перед атаками. Вмешательство в процесс передачи данных в виде схемы «человек посередине» имело свои результаты. Информацию можно было просто перехватить и расшифровать совершенно элементарно. Зато вторая версия (SSH-2) была застрахована от подобного рода вмешательства, называемого session hijacking, благодаря чему и получила наибольшее распространение.

Запреты системы безопасности

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

• определение ключа к хосту на стадии передачи, когда используется «слепок» fingerprint;
• поддержка Windows и UNIX-подобных систем;
• подмена адресов IP и DNS (spoofing);
• перехват открытых паролей при физическом доступе к каналу передачи данных.

Собственно, вся организация такой системы построена по принципу «клиент-сервер», то есть в первую очередь пользовательская машина посредством специальной программы или надстройки обращается к серверу, который и производит соответствующее перенаправление.

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

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

Как правило, в Windows-системах это встроенный в программную оболочку драйвер Microsoft Teredo, представляющий собой некое виртуальное средство эмулирования протокола IPv6 в сетях с поддержкой только IPv4. по умолчанию находится в активном состоянии. В случае появления сбоев, с ним связанных, можно просто произвести перезапуск системы или выполнить команды отключения и рестарта в командной консоли. Для деактивации используются такие строки:

• netsh;
• interface teredo set state disabled;
• interface isatap set state disabled.

После ввода команд следует перезагрузка. Для повторного включения адаптера и проверки его состояния вместо disabled прописывается разрешение enabled, после чего, опять же, следует рестарт всей системы.

SSH-сервер

Теперь посмотрим, какой порт SSH используется в качестве основного, отталкиваясь от схемы «клиент-сервер». Обычно по умолчанию применяется 22-й порт, но, как уже было указано выше, может использовать и 443-й. Вопрос только в предпочтении самого сервера.

Самыми распространенными SSH-серверами принято считать следующие:

• для Windows: Tectia SSH Server, OpenSSH с Cygwin, MobaSSH, KpyM Telnet/SSH Server, WinSSHD, copssh, freeSSHd;
• для FreeBSD: OpenSSH;
• для Linux: Tectia SSH Server, ssh, openssh-server, lsh-server, dropbear.

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

SSH-клиент

Смена порта SSH сможет производиться на основе клиентской программы или соответствующих настроек при пробросе портов на маршрутизаторе.

Однако, если касаться клиентских оболочек, для разных систем могут применяться следующие программные продукты:

• Windows - SecureCRT, PuTTY\KiTTY, Axessh, ShellGuard, SSHWindows, ZOC, XShell, ProSSHD и т. д.;
• Mac OS X: iTerm2, vSSH, NiftyTelnet SSH;
• Linux и BSD: lsh-client, kdessh, openssh-client, Vinagre, putty.

Аутентификация на основе открытых ключей и изменение порта

Теперь несколько слов о том, как происходит верификация и настройка сервера. В самом простом случае необходимо использовать файл конфигурации (sshd_config). Однако можно обойтись и без этого, например, в случае использования программ вроде PuTTY. Изменить порт SSH со стандартного значения (22) на любое другое можно совершенно элементарно.

Главное - чтобы номер открываемого порта не превышал значение 65535 (выше портов просто не бывает в природе). К тому же следует обратить внимание на некоторые открытые по умолчанию порты, которые могут использоваться клиентами вроде MySQL или базами данных FTPD. Если указать для SSH их конфигурацию, понятное дело, те просто перестанут работать.

Стоит учесть, что тот же клиент Jabber должен быть запущен в одной среде с использованием SSH-сервера, например, на виртуальной машине. А самому серверу localhost необходимо будет присвоение значения 4430 (а не 443, как было указано выше). Такая конфигурация может использоваться в том случае, когда доступ к основному файлу jabber.example.com блокируется файрволом.

С другой стороны, перебросить порты можно и на самом маршрутизаторе, используя для этого настройки его интерфейса с созданием правил исключения. На большинстве моделей вход осуществляется через ввод адресов, начинающихся с 192.168 с добавлением 0.1 или 1.1, но на роутерах, совмещающих возможности ADSL-модемов вроде Mikrotik, конечный адрес предполагает использование 88.1.

В этом случае создается новое правило, после этого устанавливаются необходимые параметры, например, для установки внешнего подключения dst-nat, а также вручную прописываются порты не в разделе общих настроек, и в разделе предпочтений активных действий (Action). Ничего особо сложного здесь нет. Главное - указать необходимые значения настроек и установить правильный порт. По умолчанию можно использовать порт 22, но, если используется специализированный клиент (какой-то из вышеуказанных для разных систем), значение можно менять произвольно, но только так, чтобы этот параметр не превышал заявленное значение, выше которого номера портов просто отсутствуют.

При настройке подключения также стоит обратить внимание на параметры клиентской программы. Очень может быть, что в ее настройках придется указать минимальную длину ключа (512), хотя по умолчанию обычно установлено 768. Также желательно установить таймаут входа в систему на уровне 600 секунд и разрешение на удаленный доступ с использованием прав root. После применения таких настроек необходимо дать еще и разрешение на использование всех прав аутентификации, кроме тех, которые основаны на использовании.rhost (но это нужно лишь системным администраторам).

Кроме всего прочего, если имя пользователя, зарегистрированного в системе, не совпадает с вводимым в данный момент, нужно будет указать его явно, используя для этого команду user ssh master с вводом дополнительных параметров (для тех, кто понимает, о чем идет речь).

Для преобразования ключа и самого метода шифрования может применяться команда ~/.ssh/id_dsa (или rsa). Для создания публичного ключа используется преобразование при помощи строки ~/.ssh/identity.pub (но это не обязательно). Но, как показывает практика, проще всего использовать команды вроде ssh-keygen. Тут суть вопроса сводится только к тому, чтобы добавить ключ к доступным инструментам авторизации (~/.ssh/authorized_keys).

Но мы зашли слишком далеко. Если возвращаться к вопросу настройки порта SSH, как уже понятно, изменить порт SSH не так уж и сложно. Правда, в некоторых ситуациях, что называется, придется попотеть, поскольку нужно будет учесть все значения основных параметров. В остальном же вопрос настройки сводится либо ко входу в серверную или клиентскую программу (если это предусмотрено изначально), либо к использованию проброса портов на маршрутизаторе. Но даже в случае изменения порта 22, установленного по умолчанию, на тот же 443-й, нужно четко понимать, что такая схема работает не всегда, а только в случае с установкой той же надстройки Jabber (другие аналоги могут задействовать и соответствующие им порты, отличающиеся от стандартных). Кроме того, особое внимание следует уделить выставлению параметров SSH-клиента, который будет непосредственно взаимодействовать с SSH-сервером, если таковое действительно предполагается в использовании текущего подключения.

В остальном же, если не предусмотрен изначально (хотя желательно выполнить такие действия), настройки и параметры для доступа по протоколу SSH можно и не менять. Тут особых проблем при создании соединения и его дальнейшем использовании, в общем-то, не предвидится (если, конечно, не будет использоваться ручная настройка конфигурации на основе сервера и клиента). Самое обычное создание правила исключения на роутере позволяет исправить все проблемы или избежать их появления.

SSH (Secure Shell) - это сетевой протокол удаленного доступа, использующий шифрование и сжатие для передаваемых данных. Проще говоря - это весьма полезный и мощный инструмент, позволяющий аутентифицироваться в системе и полноценно работать от имени локального пользователя, находясь за много километров от работающей машины. Также, в отличие от telnet и rsh - SSH шифрует весь трафик, так что вся переданная информация остается конфиденциальной.

Итак, ssh у нас уже установлен и ssh-daemon добавлен в автозагрузку при старте системы. Управлять им можно по команде:

service ssh stop|start|restart

В Ubuntu, или:

/etc/init.d/ssh {start|stop|reload|force-reload|restart|status}

В Debian, или:

systemctl start|stop|restart sshd.service

В ArchLinux (после каждой правки конфига нужно делать рестарт). В комплект входит клиент и сервер.

Опробуем в деле! Для начала создайте папку ~/.ssh

mkdir ~/.ssh

Сгенерируйте ключи для данного пользователя сервера командой:

ssh-keygen (от имени обычного пользователя).

При генерации, вы можете задать парольную фразу для ключа (желательно задать, и длинную - тогда даже заполучив ключ но не зная пароль от ключа, злоумышленник не сможет залогинится), а можете пропустить, просто нажав "Enter" - в таком случае, пароль никогда не спросится. В папке ~/.ssh появились те самые публичный и закрытый ключ.

Найдите ещё одну машину (даже смартфон подойдет - на Android есть несколько замечательных SSH-клиентов, вроде ConnectBot или JuiceSSH), установите на ней ssh и подключитесь к серверу командой:

ssh user@server

Если всё сделано правильно, будет запрошен пароль пользователя, и после ввода вы окажетесь в своей системе с видом из командной строки.

Для Windows, к слову, также есть сервера и клиенты ssh.

Насладившись результатом трудов своих, приступим к ещё более скучной части - настройке клиента/сервера.

Конфиг клиентской части лежит в /etc/ssh/ssh_config , а серверной - /etc/ssh/sshd_config . Наиболее полным руководством по настройке является, пожалуй, страница в man - man ssh и man sshd_config, так что рекомендуем прочититать её. А в данной статье рассмотрим наиболее необходимые вещи.

Настройка

Стандартный порт ssh - 22. Его можно сменить на любой нестандартный (усложняя возможный взлом благодаря безопасности через неясность, или же для привлечения внимания потенциальных взломщиков:) - для этого расскомментируйте строчку:

#Port 22

И добавьте любой желаемый до 65535 (убедившись, что порт не конфликтует с другими сервисами командой #netstat -tupln | grep LISTEN ).

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

ssh -p [порт] :

По умолчанию доступ от имени root разрешен. Крайне желательно ограничить его (и вместо этого правильно разграничить права локального пользователя с помощью sudo). Для этого найдите строчку "PermitRootLogin" и смените значение на "no". Можно также сменить на "without-password" - в таком случае, логин под рутом будет разрешен только из под машин с доверенным ключом.

Можно отключить аутентификацию по паролю и работать только с ключами - найдите строчку: "PasswordAuthentication" и смените значение на "no". Зачем? Если кто-то очень захочет получить доступ к вашей системе, то он сможет либо перебрать пароль при попытках авторизации, либо прослушать и расшифровать ваше соединение. Если отключить аутентификацию по паролю и добавить в ~/.ssh/authorized_keys на сервере публичный ключ своего, например, рабочего ноутбука, то, как мы помним, нас пустит на сервер сразу. Но как быть, если вы работаете на чужой машине и срочно нужно получить доступ на ssh-сервер, а он нас ожидаемо не пускает? Тогда можно не отключать парольную аутентификацию, а воспользоваться утилитой fail2ban. Просто установите её из вашего репозитория, после чего она применит настройки по умолчанию и, как минимум, защитит ваш ssh-канал от взлома методом перебора. Подробнее о fail2ban - http://putty.org.ru/articles/fail2ban-ssh.html.

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

PermitRootLogin no - запрещен логин под рутом.

PasswordAuthentication no - вход без пароля

Сгенерируем на удаленной машине длинный ключ (-t тип_шифрования, -b битовая длина):

ssh-keygen -t rsa -b 4096

С не менее сложной парольной фразой (восстановить забытый пароль, к слову, нельзя. Можно сменить его командой "ssh-keygen -p", но с вас в любом случае спросят старый). Перенесем публичный ключ удаленной локальной машины в ~/.ssh/authorized_keys сервера, и вуаля - теперь доступ можно получить с единственной машины, с помощью парольной фразы зыкрытого ключа. SSH позволяет настроить множество конфигураций безопасности и имеет для этого множество специфичных настроек - о них читайте в man.

Этим же целям служат два параметра sshd_config:

LoginGraceTime - задает время, по истечении которого будет разорвано соединение, если не произойдет аутентификация.

MaxAuthTries - задает количество неверных попыток ввода логина, по достижении которого соединение будет разорвано.

MaxSessions - количество одновременных сессий (если сервер - ваш домашний компьютер, к которому вы собираетесь подключаться из универа или с работы, то разумно будет ограничить число сессий до одной - отклоненный логин, в таком случае, станет поводом для повышения паранойи, генерации новых ключей и смены пароля). Впрочем, если вы внимательны, то могли заметить, что при каждом логине на сервер высвечивается строчка "Last Login". Помимо неё, можно добавить собственное приветственное сообщение - найдите строчку "Banner" и вместо none задайте путь к файлу с текстом, который будет прочитан и выведен при логине.

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

AllowUsers user1 - разрешить вход только user1.

DenyUsers user1 - разрешить всем, кроме user1.

И аналогичные параметры для доступа определенных групп - AllowGroups и DenyGroups.

Также по SSH можно передавать сеанс X11. Для этого найдите строчку "ForwardX11" и измените значение на "yes".

Аналогичную строку найдите в конфиге клиента - /etc/ssh/ssh_config, и также смените на "yes".

Теперь присоединяться к серверу по ssh нужно с аргументом -X:

ssh -X user@server>

Можно сразу запуcтить приложение при коннекте:

ssh -X user@server "приложение"

Вот так выглядит работающий GIMP в ssh-сессии:

Или можно получить вывод с веб-камеры ноутбука ничего не подозревающего пользователя:)

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

По SSH-сессии можно также копировать файлы - для этого есть простенькая утилита "scp". Передавать файлы можно прямо в сессии как с сервера на клиент:

scp user@server:/путь/к/файлу/на/сервере /куда/сохранить/на/локальной/машине

Так и с клиента на сервер:

scp путь/к/файлу/клиента user@server:/путь/на/сервере

Это достаточно удобно, если нужно скопировать текстовик или фотографию, но как быть, когда предстоит работа с многими файлами? Для этого существует удобнейшая вещь - sshfs (доступна для установки в репозиториях большинства *nix-систем).

Просто задайте путь аналогично scp:

sshfs user@server:/home/user /mnt/

И папка /home/user сервера появится в точке монтирования /mnt локальной машины!

Отмонтирование производится через umount.

И, напоследок, расскажем об одной малоизвестной фиче. Если создать файл /.ssh/config и заполнить его подобным образом:

Host [имя]

Hostname

User [имя пользователя сервера]

желаемые опции

вроде

ForwardX11 yes

Port 30000

То можно будем логиниться по:

ssh [имя]

ssh -X -p 30000 user@server

И все опции подхватятся автоматически. Таким образом, при частой аутентификации на определенном сервере, вы упростите этот процесс к делу пары мгновений.

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