5.7 Работа с клиентом и сервером SSH

Данная статья посвящена клиенту и серверу защищенного терминала (secure shell) в Linux Ред ОС, их настройке и использованию. SSH — это специальный сетевой протокол, позволяющий получать удаленный доступ к компьютеру с большой степенью безопасности соединения.
Описание принципов работы и используемых приложений
В основном, SSH реализован в виде двух приложений — SSH-сервера и SSH-клиента. При подключении клиент проходит процедуру авторизации у сервера и между ними устанавливается зашифрованное соединение. OpenSSH сервер может работать как с протоколом ssh1, так и с протоколом ssh2. В настоящее время протокол ssh1 считается небезопасным, поэтому его использование крайне не рекомендуется. Я намеренно опускаю различные технические подробности работы протокола, т. к. основной целью данного руководства является описание его настройки и использования.
Установка
Установить OpenSSH можно из терминала командой:

sudo yum install openssh.x86_64

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

sudo service sshd stop|start|restart

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

Рекомендуемые параметры. Безопасность

Сам по себе, неправильно настроенный 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. Но, при условии, что пользователь, добавленный при установке системы имеет возможность решать все административные задачи через sudo, создавать возможность root доступа к системе через ssh — выглядит неразумно (даже при аутентификации по ключу). Рекомендуется совсем отключить. эту опцию, или применять ее только в режиме forced-commands-only. Отключить root-доступ можно так:

PermitRootLogin no

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

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

PasswordAuthentication no

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

PermitEmptyPasswords no

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

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

PubkeyAuthentication yes

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

# Коментарии записываются только с новой строки
# общий вид записей в файле authorized_keys
# [опции] тип_ключа(ssh-rsa или ssh-dss) очень_длинная_строка_непонятная_простому_человеку [логин@хост]
ssh-rsa AAAAB3Nza...LiPk== user@example.net
from="*.sales.example.net,!pc.sales.example.net" ssh-rsa AAAAB2...19Q== john@example.net
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...== jane@example.net

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

AuthorizedKeysFile %h/.ssh/my_keys

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

AuthorizedKeysFile /etc/ssh/authorized_keys

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

SFTP

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

Настройка 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 (X11Forwarding)

X11 SSH Forwarding

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

/etc/ssh/sshd_config
...
X11Forwarding yes
...
Перезагрузка
/etc/init.d/sshd restart

Настройка клиента
/etc/ssh/ssh_config
...
ForwardX11 yes
...

Заходим на удаленный хост и потом запускаем приложение kopete

ssh -XC user1@remotehost
kopete

Сразу запустить приложение kopete

ssh -XC user1@remotehost "kopete"

Опции:

X : перенаправлять графический вывод
С : компрессия передаваемых данных

Если вы нашли ошибку, выделите текст и нажмите Ctrl+Enter.

Print Friendly, PDF & Email