Руководство FreeBSD
Пред. | Глава 14. Безопасность | След.

# 14.11. OpenSSH

Предоставил Chern Lee.

OpenSSH это набор сетевых инструментов, используемых для защищенного доступа к удаленным компьютерам. Он может быть использован в качестве непосредственной замены `rlogin`, `rsh`, `rcp` и `telnet`. Кроме того, через SSH могут быть безопасно туннелированы и/или перенаправлены произвольные TCP/IP соединения. OpenSSH шифрует весь трафик, эффективно предотвращая кражу данных, перехват соединения и другие сетевые атаки.

OpenSSH поддерживается проектом OpenBSD, он основан на SSH v1.2.12 со всеми последними исправлениями и обновлениями, совместим с протоколами SSH версий 1 и 2.

## 14.11.1. Преимущества использования OpenSSH

Обычно при использовании telnet(1) или rlogin(1) данные пересылаются по сети в незашифрованной форме. Перехватчик пакетов в любой точке сети между клиентом и сервером может похитить информацию о пользователе/пароле или данные, передаваемые через соединение. Для предотвращения этого OpenSSH предлагает различные методы шифрования.

## 14.11.2. Включение sshd

В FreeBSD даемон sshd должен быть разрешен в процессе инсталляции. За запуск ответственна следующая строка в файле `rc.conf`:

    sshd_enable="YES"

При следующей загрузке системы будет запущен sshd(8), даемон для OpenSSH. Вы можете также воспользоваться скриптом `/etc/rc.d/sshd` системы rc(8) для запуска OpenSSH:

    /etc/rc.d/sshd start

## 14.11.3. SSH клиент

Утилита ssh(1) работает подобно rlogin(1).

    # ssh user@example.com
    Host key not found from the list of known hosts.
    Are you sure you want to continue connecting (yes/no)? yes
    Host 'example.com' added to the list of known hosts.
    user@example.com's password: *******

Вход продолжится так же, как если бы сессия была инициирована с использованием `rlogin` или `telnet`. SSH использует систему опознавательных ключей для проверки подлинности сервера при подключении клиента. Пользователю предлагается `yes` только при первом подключении. Дальнейшие попытки входа предваряются проверкой сохраненного ключа сервера. SSH клиент сообщит вам, если сохраненный ключ будет отличаться от только что полученного. Ключи серверов сохраняются в `~/.ssh/known_hosts`, или в `~/.ssh/known_hosts2` для SSH v2.

По умолчанию современные серверы OpenSSH настроены на приём только соединений SSH v2. Клиент будет использовать версию 2 там, где это возможно, а затем версию 1. Также, клиент можно заставить использовать конкретную версию при помощи опций `-1` и `-2` для указания соответствующей версии протокола. Версия 1 поддерживается ради совместимости со старыми серверами.

## 14.11.4. Безопасное копирование

Команда scp(1) работает подобно rcp(1); она копирует файл с удаленного компьютера, но делает это безопасным способом.

    #  scp user@example.com:/COPYRIGHT COPYRIGHT
    user@example.com's password: *******
    COPYRIGHT            100% |*****************************|  4735       00:00
    #

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

Параметры, передаваемые scp(1), похожи на параметры cp(1), с файлом или файлами в качестве первого аргумента и приемником копирования во втором. Поскольку файлы файлы передаются по сети через SSH, один или более аргументов принимают форму `user@host:<path_to_remote_file>`.

## 14.11.5. Настройка

Системные файлы настройки для даемона и клиента OpenSSH расположены в каталоге `/etc/ssh`.

Файл `ssh_config` используется для настройки клиента, а `sshd_config` для даемона.

Кроме того, параметры `sshd_program` (по умолчанию `/usr/sbin/sshd`), и `sshd_flags` `rc.conf` дают дополнительные возможности настройки.

## 14.11.6. ssh-keygen

Вместо использования паролей, с помощью ssh-keygen(1) можно создать ключи DSA или RSA, которыми пользователи могут аутентифицироваться:

    % ssh-keygen -t dsa
    Generating public/private dsa key pair.
    Enter file in which to save the key (/home/user/.ssh/id_dsa):
    Created directory '/home/user/.ssh'.
    Enter passphrase (empty for no passphrase):
    Enter same passphrase again:
    Your identification has been saved in /home/user/.ssh/id_dsa.
    Your public key has been saved in /home/user/.ssh/id_dsa.pub.
    The key fingerprint is:
    bb:48:db:f2:93:57:80:b6:aa:bc:f5:d5:ba:8f:79:17 user@host.example.com

ssh-keygen(1) создаст пару публичного и приватного ключей, используемых для аутентификации. Приватный ключ сохраняется в `~/.ssh/id_dsa` или `~/.ssh/id_rsa`, а публичный в `~/.ssh/id_dsa.pub` или `~/.ssh/id_rsa.pub` (для ключей DSA и RSA соответственно). Для включения аутентификации по ключам публичный ключ должен быть помещен в файл `~/.ssh/authorized_keys` на удаленном компьютере.

Это позволяет соединяться с удаленным компьютером с помощью SSH-ключей вместо паролей.

Если при генерации ключей был использован пароль, каждый раз для при использовании приватного ключа он будет запрашиваться у пользователя. Для того, чтобы избежать непрерывного набора кодовой фразы, можно использовать утилиту ssh-agent(1), как описано в разделе Разд. 14.11.7 ниже.

> Внимание: Параметры и имена файлов могут различаться для разных версий OpenSSH, установленных в системе, для решения проблем обратитесь к странице справочника ssh-keygen(1).

## 14.11.7. Утилиты ssh-agent и ssh-add

Утилиты ssh-agent(1) и ssh-add(1) позволяют сохранять ключи SSH в памяти, чтобы не набирать кодовые фразы при каждом использовании ключа.

Утилита ssh-agent(1) обеспечивает процесс аутентификации загруженными в нее секретными ключами; для этого утилита ssh-agent(1) должна запустить внешний процесс. В самом простом случае это может быть шелл-процесс; в чуть более продвинутом -- оконный менеджер.

Для использования ssh-agent(1) совместно с шеллом, ssh-agent(1) должен быть запущен с именем этого шелла в качестве аргумента. После этого в его память при помощи утилиты ssh-add(1) могут быть добавлены необходимые ключи; при этом будут запрошены соответствующие кодовые фразы. Добавленные ключи могут затем использоваться для ssh(1) на машины, на которых установлены соответствующие публичные ключи:

    % ssh-agent csh
    % ssh-add
    Enter passphrase for /home/user/.ssh/id_dsa:
    Identity added: /home/user/.ssh/id_dsa (/home/user/.ssh/id_dsa)
    %

Для того чтобы использовать ssh-agent(1) в X11, вызов ssh-agent(1)должен быть помещен в файл `~/.xinitrc`. Это обеспечит поддержкой ssh-agent(1) все программы, запущенные в X11. Файл `~/.xinitrc` может выглядеть, например, так:

    exec ssh-agent startxfce4

При этом будет запущен ssh-agent(1), который, в свою очередь, вызовет запуск XFCE, при каждом старте X11. После запуска X11, выполните команду ssh-add(1) для добавления ваших SSH-ключей.

## 14.11.8. Туннелирование SSH

OpenSSH поддерживает возможность создания туннеля для пропуска соединения по другому протоколу через защищенную сессию.

Следующая команда указывает ssh(1) создать туннель для telnet:

    % ssh -2 -N -f -L 5023:localhost:23 user@foo.example.com
    %

Команда `ssh` используется со следующими параметрами:

`-2`

  Указывает `ssh` использовать версию 2 протокола (не используйте этот параметр, если работаете со старыми SSH серверами).

`-N`

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

`-f`

  Указывает `ssh` запускаться в фоновом режиме.

`-L`

  Означает локальный туннель в стиле `localport:remotehost:remoteport`.

`user@foo.example.com`

  Удаленный сервер SSH.

Туннель SSH создается путем создания прослушивающего сокета на определенном порту `localhost`. Затем все принятые на локальном хосту/порту соединения переправляются на через SSH на определенный удаленный хост и порт.

В этом примере, порт `5023` на `localhost` перенаправляется на порт `23` на `localhost` удаленного компьютера. Поскольку `23` это порт telnet, будет создано защищенное соединение telnet через туннель SSH.

Этот метод можно использовать для любого числа небезопасных протоколов, таких как SMTP, POP3, FTP, и так далее.

Пример 14-1. Использование SSH для создания защищенного туннеля на SMTP

    % ssh -2 -N -f -L 5025:localhost:25 user@mailserver.example.com
    user@mailserver.example.com's password: *****
    % telnet localhost 5025
    Trying 127.0.0.1...
    Connected to localhost.
    Escape character is '^]'.
    220 mailserver.example.com ESMTP

Этот метод можно использовать вместе с ssh-keygen(1) и дополнительными пользовательскими учётными записями для создания более удобного автоматического SSH туннелирования. Ключи могут быть использованы вместо паролей, и туннели могут запускаться от отдельных пользователей.

### 14.11.8.1. Практические примеры SSH туннелирования

#### 14.11.8.1.1. Защищенный доступ к серверу POP3

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

    % ssh -2 -N -f -L 2110:mail.example.com:110 user@ssh-server.example.com
    user@ssh-server.example.com's password: ******

Когда туннель включен и работает, вы можете настроить почтовый клиент для отправки запросов POP3 на `localhost`, порт 2110. Соединение будет безопасно переправлено через туннель на `mail.example.com`.

#### 14.11.8.1.2. Прохождение через Драконовский Брандмауэр

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

Вам может потребоваться доступ к другому (возможно, не относящемуся к работе) сервису, такому как Ogg Vorbis для прослушивания музыки. Если этот сервер Ogg Vorbis выдает поток не с портов 22 или 80, вы не сможете получить к нему доступ.

Решение состоит в создании SSH соединения с компьютером вне брандмауэра и использование его для туннелирования сервера Ogg Vorbis.

    % ssh -2 -N -f -L 8888:music.example.com:8000 user@unfirewalled-system.example.org
    user@unfirewalled-system.example.org's password: *******

Клиентскую программу теперь можно настроить на `localhost` порт 8888, который будет перенаправлен на `music.example.com` порт 8000, успешно обойдя брандмауэр.

## 14.11.9. Параметр ограничения пользователей `AllowUsers`

Зачастую хорошие результаты даёт ограничение того, какие именно пользователи и откуда могут регистрироваться в системе. Задание параметра `AllowUsers` является хорошим способом добиться этого. К примеру, для разрешения регистрации только пользователю `root` с машины `192.168.1.32`, в файле `/etc/ssh/sshd_config` нужно указать нечто вроде следующего:

    AllowUsers root@192.168.1.32

Для разрешения регистрации пользователя `admin` из любой точки, просто укажите имя пользователя:

    AllowUsers admin

Несколько пользователей должны перечислять в одной строке, как здесь:

    AllowUsers root@192.168.1.32 admin

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

После внесения изменений в `/etc/ssh/sshd_config` вы должны указать sshd(8) на повторную загрузку конфигурационных файлов, выполнив следующую команду:

    # /etc/rc.d/sshd reload

## 14.11.10. Дополнительная литература

OpenSSH

ssh(1) scp(1) ssh-keygen(1) ssh-agent(1) ssh-add(1) ssh_config(5)

sshd(8) sftp-server(8) sshd_config(5)

Пред. | Начало | След.
VPN через IPsec | Уровень выше | Списки контроля доступа файловой системы (ACL)

Этот, и другие документы, могут быть скачаны с ftp://ftp.FreeBSD.org/pub/FreeBSD/doc/.

По вопросам, связанным с FreeBSD, прочитайте документацию прежде чем писать в <questions@FreeBSD.org>.
По вопросам, связанным с этой документацией, пишите <doc@FreeBSD.org>.
По вопросам, связанным с русским переводом документации, пишите в рассылку <frdp@FreeBSD.org.ua>.
Информация по подписке на эту рассылку находится на сайте проекта перевода.