OpenSSH: настройки, секреты, трюки и советы - История изменений

Nordwind: /* Скрываем записи о серверах, к которым мы подключались */

2013-06-02T09:25:15Z

Скрываем записи о серверах, к которым мы подключались

Nordwind: /* Сажаем пользователей в песочницу */

2013-06-02T09:24:28Z

Сажаем пользователей в песочницу

Nordwind: /* Создание SOCKS-сервера */

2013-06-02T09:22:56Z

Создание SOCKS-сервера

Nordwind: /* Мультиплексирование ssh-сессий */

2013-06-02T09:21:42Z

Мультиплексирование ssh-сессий

Nordwind: /* Безопасный способ получения почты */

2013-06-02T09:20:04Z

Безопасный способ получения почты

Nordwind: /* Пример создания резервных копий */

2013-06-02T09:18:51Z

Пример создания резервных копий

Nordwind: /* Ограничение доступа суперпользователя */

2013-06-02T09:17:17Z

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

Nordwind: /* Отключение прослушивания IPv6 адресов */

2013-06-02T09:14:10Z

Отключение прослушивания IPv6 адресов

Nordwind: Новая страница: «: Данная статья 100 % копипаст с [http://www.openbsd.ru www.openbsd.ru] За последние несколько лет OpenSSH из на…»

2013-06-02T09:13:21Z

Новая страница: «: Данная статья 100 % копипаст с [http://www.openbsd.ru www.openbsd.ru] За последние несколько лет OpenSSH из на…»

Новая страница

: Данная статья 100 % копипаст с [http://www.openbsd.ru www.openbsd.ru]

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

== Отключение прослушивания IPv6 адресов ==

По умолчанию sshd(8) слушает как на IPv4 так и на IPv6 адресах. Для того что бы отключить возможность работы по IPv6, необходимо изменить параметр AddressFamily:

AddressFamily inet

== Адрес и порт прослушивания ==

По умолчанию [http://www.openbsd.org/cgi-bin/man.cgi?query=sshd&apropos=0&sektion=8&manpath=OpenBSD+Current&arch=i386&format=html sshd(8)] принимает подключения на всех интерфейсах, в чем не всегда есть необходимость. Если не требуется заходить на сервер «из вне», следует ограничить его работу определенным адресом с помощью параметра ListenAddress:

# ListenAddress 0.0.0.0
ListenAddress 192.168.1.2

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

== Ограничение доступа суперпользователя ==

В большинстве дистрибутивов в целях безопасности доступ суперпользователю по SSH закрыт (PermitRootLogin no), и при попытке зарегистрироваться под root получаем сообщение об ошибке. Для выполнения задач, требующих привилегий администратора, приходится заходить под обычным пользователем и использовать su(1) или sudo(8). Красиво выйти из ситуации поможет директива Match. В качестве аргумента ей передается критерий отбора (User, Group, Host, Address), его значение и параметр, который нужно применить. Для примера разрешим подключение под root только с localhost и из доверенной подсети 192.168.5.0/24:

<pre>
PermitRootLogin no
Match Host 192.168.5.*,127.0.0.1
PermitRootLogin yes
</pre>

== Контроль неудачных подключений ==

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

LoginGraceTime 60
MaxStartups 2:50:10

Параметр LoginGraceTime определяет, по истечению какого времени простаивающее подключение будет разорвано (в секундах). Значение по умолчанию 120 явно завышено. Количество параллельных неаутентифицированных подключений к серверу контролируется при помощи MaxStartups. Запись параметра имеет форму «start: rate: full». В нашем случае она означает отключение с вероятностью 50 % при наличии двух неаутентифицированных связей, с линейным ростом вероятности до 100 % при достижении 10.

== Контроль за подключениями пользователей ==

Установки в файлах /etc/ssh/sshrc или ~/.ssh/rc позволяют выполнить некоторые действия при регистрации пользователя. Здесь можно использовать любые команды оболочки. Например, отправим администратору на почту уведомление о том, что в систему по SSH зашел пользователь:

# vi /etc/ssh/sshrc
echo $(date) $SSH_CONNECTION $USER $SSH_TTY | mail -s «ssh login» admin@domain.ru

== Пример создания резервных копий ==

Генерируем пару ключей (секретный и публичный):

<pre>
$ sudo ssh-keygen -t rsa -C 'remote backup'
Generating public/private rsa key pair.
Enter file in which to save the key (/home/user/.ssh/id_rsa):
/home/user/.ssh/id_rsa_backup
</pre>

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

$ ssh remotehost «umask 077; cat > .ssh/authorized_keys» < .ssh/id_rsa_backup.pub

Затем редактируем authorized_keys (ключ '-t' следует использовать при запуске программ, требующих для своей работы наличия псевдотерминала):

<pre>
$ ssh -t remotehost vi .ssh/authorized_keys
from="192.168.0.*,212.34.XX.YY", command="cd /work; tar cvf — ./* | bzip2 −9",
no-pty, no-agent-forwarding, no-X11-forwarding, no-port-forwarding ssh-rsa AAAA[…]
</pre>

И запускаем процедуру резервного копирования:

$ ssh -i .ssh/id_rsa_backup remotehost > ~/backup/work-`date +%d%m%Y`.tar.bz2 2>/dev/null

Каталог /work, находящийся на сервере remotehost, будет сохранен в архив ~/backup/work-11052008.tar.bz2.

== Используем dump в связке с SSH ==

Используя SSH, можно защитить информацию, передаваемую программами, не имеющими встроенных механизмов шифрования соединения. Например, сделаем бэкап с помощью [http://www.openbsd.org/cgi-bin/man.cgi?query=dump&apropos=0&sektion=8&manpath=OpenBSD+Current&arch=i386&format=html dump(8)] на удаленный сервер:

$ sudo dump −0au -f — /dev/rwd1a | gzip −9 | ssh remotehost 'dd of=cvs_backup.dump.gz'

Поскольку в [http://www.openbsd.org/cgi-bin/man.cgi?query=dump&apropos=0&sektion=8&manpath=OpenBSD+Current&arch=i386&format=html dump(8)] встроена возможность передавать данные по сети с использованием RSH, существует возможность использования и SSH, поскольку его функциональность аналогична:

$ ssh remotehost touch /home/user/cvs.dump
$ env RSH=`which ssh` sudo -E dump 0f remotehost:/home/user/cvs.dump /cvs

== Передача файлов и каталогов ==

Передать файл, используя SSH, можно одним из следующих способов:

$ cat myfile | ssh remotehost 'cat > myfile'
$ tar zcf — ~/coding | ssh remotehost 'cat > coding.tgz'

Чтобы рекурсивно отправить весь каталог, набираем:

$ scp -r mydir user@host.domain.ru:

Вариант копирования каталога с использованием [http://www.openbsd.org/cgi-bin/man.cgi?query=ssh&apropos=0&sektion=1&manpath=OpenBSD+Current&arch=i386&format=html ssh(1)] и [http://www.openbsd.org/cgi-bin/man.cgi?query=tar&apropos=0&sektion=1&manpath=OpenBSD+Current&arch=i386&format=html tar(1)] с локального хоста на удаленный:

$ tar cf — source | ssh remotehost «(cd /target; tar xpf -)»

и с удаленного хоста на локальный:

$ ssh remotehost «tar cf — source» | (cd /target; tar xpf -)

== Безопасный способ получения почты ==

Для безопасного получения почты с помощью fetchmail можно использовать SSH. Для этого в конфигурационном файле ~/.fetchmailrc необходимо указать следующее:

<pre>
poll localhost with protocol pop3 and port 8110:
preconnect "ssh -f -q -C user@213.167.XX.YY \
-L 8110:213.167.XX.YY:110 sleep 10" password noIdea;
</pre>

Забираем почту:

<pre>
$ fetchmail
1 message for user at localhost (8062 octets).
reading message user@localhost.domain.ru:1 of 1 (8062 octets)……. flushed
</pre>

== Почтовый шлюз ==

Настроим 192.168.1.1 на перенаправление входящей и исходящей почты по шифрованному каналу для клиентов из 192.168.1.0/24 на mail.domain.ru:

<pre>
$ vi .ssh/config
Host mail
Hostname mail.domain.ru
LocalForward 192.168.1.1:8025 mail.domain.ru:25
LocalForward 192.168.1.1:8110 mail.domain.ru:110
LocalForward 192.168.1.1:8143 mail.domain.ru:143
GatewayPorts yes
</pre>

Открываем туннель:

$ ssh mail

== Выполнение заданной команды после подключения ==

Параметр ProxyCommand позволяет выполнить произвольную команду. Для примера подключимся через шлюз к файловому серверу, который находится за NAT:

<pre>
$ vi .ssh/config
Host gateway
HostName ns.domain.ru
Host filesrv
HostName 192.168.5.201
ProxyCommand ssh gateway nc -w 180 %h %p
</pre>

Подключаемся:

$ ssh filesrv

== Мультиплексирование ssh-сессий ==

Использование параметра ControlMaster позволяет ускорить доступ к удаленному серверу за счет того, что в специальном файле сохраняются все параметры предыдущего сеанса, которые и используются при повторном подключении. Для примера создадим две Host-секции:

<pre>
$ vi .ssh/config
Host srv1
HostName 213.167.XX.YY
ControlMaster yes
# Здесь %r — имя, %h — хост и %p — порт
ControlPath ~/.ssh/ctl-%r-%h-%p
Host srv1fast
HostName 213.167.XX.YY
ControlMaster no
ControlPath ~/.ssh/ctl-%r-%h-%p
</pre>

Теперь на сервере srv1 выполняем утилиту uptime(1), логинимся на нем (чтобы создать локальный сокет для второго подключения), переходим на другую консоль и снова запрашиваем статистические счетчики:

<pre>
ttyp0$ time ssh srv1 uptime
5:55PM up 37 days, 9:19, 1 user, load averages: 0.33, 0.32, 0.33
0m0.77s real 0m0.06s user 0m0.01s system

ttyp0$ ssh srv1
ttyp1$ time ssh srv1fast uptime
5:57PM up 37 days, 9:20, 2 users, load averages: 0.37, 0.34, 0.33
0m0.03s real 0m0.00s user 0m0.01s system
</pre>

Из примера видно, что при использовании мультиплексирования соединений время выполнения команды uptime(1) на удаленном сервере уменьшилось в 25 раз.
== Создание SOCKS-сервера ==

OpenSSH можно использовать как специальный SOCKS-сервер, который поддерживает более гибкое проксирование, чем простое перенаправление портов. Например, команда:

$ ssh -D1080 user@domain.ru

Создает локальный SOCKS5-сервер, который ждет подключения на localhost:1080. Альтернативный вариант — прописать директиву DynamicForward в .ssh/config:

<pre>
$ vi .ssh/config
Host proxy
HostName ns.domain.ru
DynamicForward 1080
</pre>

Подключаемся, введя ssh proxy. Протестировать работу SOCKS5-сервера можно такой командой:

<pre>
$ echo -n «GET / HTTP/1.0\r\n\r\n» | nc -X 5 -x 127.0.0.1:1080 \
www.domain.ru 80 | head −4
HTTP/1.1 200 OK
Date: Sat, 23 Feb 2008 14:27:43 GMT
Server: Apache
X-Powered-By: PHP/4.4.1
</pre>

Теперь SOCKS-сервер готов к использованию:

$ tsocks thunderbird

== Сажаем пользователей в песочницу ==

В OpenSSH 4.9 появилась долгожданная поддержка [http://www.openbsd.org/cgi-bin/man.cgi?query=chroot&apropos=0&sektion=2&manpath=OpenBSD+Current&arch=i386&format=html chroot(2)] для [http://www.openbsd.org/cgi-bin/man.cgi?query=sshd&apropos=0&sektion=8&manpath=OpenBSD+Current&arch=i386&format=html sshd(8)], контролируемая с помощью опции ChrootDirectory. К примеру, заставим подключающегося по sftp пользователя worker переходить в измененный корневой каталог data:

<pre>
# vi /etc/ssh/sshd_config
# Subsystem sftp /usr/libexec/sftp-server
Subsystem sftp internal-sftp

Match User worker
X11Forwarding no
AllowTcpForwarding no
ForceCommand internal-sftp
ChrootDirectory /data
</pre>

Пример для хостинговых клиентов:

<pre>
# vi /etc/ssh/sshd_config
# Subsystem sftp /usr/libexec/sftp-server
Subsystem sftp internal-sftp

Match Group wwwusers
X11Forwarding no
AllowTcpForwarding no
ForceCommand internal-sftp
ChrootDirectory /var/www/hosting/%u
</pre>

Теперь зарегистрированные пользователи будут допущены только к «своему» каталогу, при подключении модификатор %u будет заменен именем пользователя. При необходимости можно использовать %h, который соответствует домашнему каталогу юзера.

== Скрываем записи о серверах, к которым мы подключались ==

Некоторые администраторы, возможно, захотят зашифровать все IP и доменные адреса из файла .ssh/known_hosts. Делается это следующим образом:

<pre>
$ echo 'HashKnownHosts' >> ~/.ssh/config
$ ssh-keygen -H -f ~/.ssh/known_hosts
$ head −1 ~/.ssh/known_hosts
+|1|TJ2SaXGqO8uHYeiA92KuNRIKR7M=|GpQB8Qz0tQPqA+nF+ghe37mpcHA= ssh-rsa AAAA[…]
</pre>

== Управляющие последовательности SSH ==

Управляющие последовательности SSH станут доступны, если в SSH-сессии сначала нажать <Enter>, затем управляющий символ сеанса (по умолчанию тильда, задается директивой EscapeChar) и специальную клавишу, которая указывает, какую именно функцию следует выполнить.

Допустим, мы с mail.domain.ru зашли на bastion.domain2.ru и решили, что не плохо было бы открыть обратный шифрованный туннель к почтовому серверу для безопасной загрузки сообщений. С помощью комбинации клавиш «<Enter>~C» можно интерактивно управлять локальным и удаленным форвардингами (ключи '-L' и '-R'):

<pre>
bastion$ <Enter>~C
ssh> -R 8110:mail.domain.ru:110
Forwarding port.
</pre>

Проверяем работу созданного почтового туннеля:

<pre>
bastion$ telnet localhost 8110
+OK Dovecot ready.
</pre>

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

<pre>
bastion$ <Enter>~C
ssh> help
Commands:
-L[bind_address:]port:host:hostport Request local forward
-R[bind_address:]port:host:hostport Request remote forward
-KR[bind_address:]port Cancel remote forward
</pre>

Если в ~/.ssh/config установить значение директивы PermitLocalCommand в yes, то мы сможем выполнять команды в локальном шелле, то есть на хосте, с которого зашли:

<pre>
ns$ ssh mx
mx$ <Enter>~C
ssh> !uptime # команда выполняется на хосте ns
7:02PM up 100 days, 11 mins, 1 user, load averages: 0.13, 0.21, 0.23
<Enter>
mx$ uptime # команда выполняется на хосте mx
7:02PM up 4 days, 7:34, 1 user, load averages: 0.21, 0.23, 0.19
</pre>

Если на предыдущем узле требуется выполнить сразу несколько команд, то SSH-сессию лучше временно засуспендить (приостановить выполнение программы ssh):

mx$ <Enter>~<Ctrl-Z>
[1] + Suspended «ssh» «$@»

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

<pre>
mx$ <Enter>~#
The following connections are open:
#0 client-session (t4 r0 i0/0 o0/0 fd 5/6 cfd -1)
</pre>

А для быстрого завершения SSH-сессии ставим точку:

mx$ <Enter>~.
Connection to 213.167.XX.YY closed.

== Сокращенный набор ==

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

<pre>
$ vi ~/.ssh/config
Host mx
Hostname mx.domain.ru
Port 2022
User admin
</pre>

Таким образом, достаточно ввести <tt>ssh mx</tt>, чтобы соединиться с нужным хостом.

== Получение доступа к закрытому сервису ==

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

<pre>
$ vi ~/.ssh/config
Host gate
Hostname gate.domain.ru
# Для ускорения соединений включаем мультиплексирование SSH-сессий
ControlMaster auto
ControlPath ~/.ssh/ctl-%r-%h-%p
# Перенаправляем локальный порт на файловый сервер (Win2k3 с поднятым VShell)
LocalForward 8022 192.168.1.101:22

# Подключаясь к localhost:8022, мы будем попадать на файловый сервер
Host fileserver
Hostname localhost
Port 8022
ControlMaster auto
ControlPath ~/.ssh/ctl-%r-%h-%p
HostKeyAlias fileserver
</pre>

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

<pre>
$ ssh -N -f gate
$ telnet localhost 8022
SSH-2.0-VShell_3_0_4_656 VShell
</pre>

Теперь можно подключиться к файловому серверу, который находится за NAT’ом, в обход правил файерола, установленных на шлюзе:

<pre>
$ ssh fileserver
Microsoft Windows [Version 5.2.3790]
C:\Documents and Settings\Username\My Documents>
</pre>

== Ограничение возможностей перебора паролей с помощью [http://www.openbsd.org/cgi-bin/man.cgi?query=pf&apropos=0&sektion=4&manpath=OpenBSD+Current&arch=i386&format=html pf(4)] ==

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

<pre>
# vi /etc/pf.conf
table <sshbf> persist
block in log quick on $ext_if inet from <sshbf>
pass in log on $ext_if inet proto tcp to $ext_if port ssh keep state \
(max-src-conn-rate 5/60, overload <sshbf> flush global)
</pre>

Данный набор правил инструктирует фильтр пакетов не допускать более 5 одновременных соединений к 22 порту за 60 секунд.

== Перенаправление X11-подключений ==

Для перенаправления X11-подключений следует использовать ключ '-Y':

$ ssh -Y user@domain.com

Причем в конфигурационном файле /etc/ssh/sshd_config параметр X11Forwarding должен быть установлен в «yes». Если X-сервер запущен на локальной системе, то необходимо включить и X11UseLocalhost.

== Использование аутентификации на базе публичного ключа ==

См. мини-руководство [[OpenSSH_мини-руководство|«шаг за шагом»]].

== VPN на базе SSH ==

См. мини-руководство [[OpenSSH_мини-руководство|«шаг за шагом»]].

Советы взяты из статей [http://www.synack.ru/articles/x_06_2008_xakep_pro_kaleidoskop_tainyh_znanii «Калейдоскоп тайных знаний»] и [http://www.synack.ru/articles/x_07_2008_xakep_pro_volshebnye_kriptotunneli «Волшебные криптотуннели»], опубликованных в июньском и июльском номерах журнала «Хакер» за 2008 год. Авторы статей: Андрей Матвеев и Сергей Яремчук. Коррективы и уточнения введены проектом OpenBSD.ru.

[[Категория:Howto]]

@@ Строка 72: / Строка 72: @@
   $ ssh -i .ssh/id_rsa_backup remotehost > ~/backup/work-`date +%d%m%Y`.tar.bz2 2>/dev/null
-Каталог /work, находящийся на сервере remotehost, будет сохранен в архив <span style="color:green;">~/backup/work-11052008.tar.bz2</span>.
+Каталог <tt>/work</tt>, находящийся на сервере remotehost, будет сохранен в архив <span style="color:green;">~/backup/work-11052008.tar.bz2</span>.
 == Используем dump в связке с SSH ==

@@ Строка 253: / Строка 253: @@
 == Скрываем записи о серверах, к которым мы подключались ==
-Некоторые администраторы, возможно, захотят зашифровать все IP и доменные адреса из файла .ssh/known_hosts. Делается это следующим образом:
+Некоторые администраторы, возможно, захотят зашифровать все IP и доменные адреса из файла <span style="color:green;">.ssh/known_hosts</span>. Делается это следующим образом:
 <pre>

@@ Строка 221: / Строка 221: @@
 == Сажаем пользователей в песочницу ==
-В OpenSSH 4.9 появилась долгожданная поддержка [http://www.openbsd.org/cgi-bin/man.cgi?query=chroot&apropos=0&sektion=2&manpath=OpenBSD+Current&arch=i386&format=html chroot(2)] для [http://www.openbsd.org/cgi-bin/man.cgi?query=sshd&apropos=0&sektion=8&manpath=OpenBSD+Current&arch=i386&format=html sshd(8)], контролируемая с помощью опции ChrootDirectory. К примеру, заставим подключающегося по sftp пользователя worker переходить в измененный корневой каталог data:
+В OpenSSH 4.9 появилась долгожданная поддержка [http://www.openbsd.org/cgi-bin/man.cgi?query=chroot&apropos=0&sektion=2&manpath=OpenBSD+Current&arch=i386&format=html chroot(2)] для [http://www.openbsd.org/cgi-bin/man.cgi?query=sshd&apropos=0&sektion=8&manpath=OpenBSD+Current&arch=i386&format=html sshd(8)], контролируемая с помощью опции ChrootDirectory. К примеру, заставим подключающегося по <tt>sftp</tt> пользователя <tt>worker</tt> переходить в измененный корневой каталог /data:
 <pre>

@@ Строка 195: / Строка 195: @@
   $ ssh -D1080 user@domain.ru
-Создает локальный SOCKS5-сервер, который ждет подключения на localhost:1080. Альтернативный вариант — прописать директиву DynamicForward в .ssh/config:
+Создает локальный SOCKS5-сервер, который ждет подключения на localhost:1080. Альтернативный вариант — прописать директиву DynamicForward в <span style="color:green;">.ssh/config</span>:
 <pre>

@@ Строка 174: / Строка 174: @@
 </pre>
-Теперь на сервере srv1 выполняем утилиту uptime(1), логинимся на нем (чтобы создать локальный сокет для второго подключения), переходим на другую консоль и снова запрашиваем статистические счетчики:
+Теперь на сервере srv1 выполняем утилиту [http://www.openbsd.org/cgi-bin/man.cgi?query=uptime&apropos=0&sektion=1&manpath=OpenBSD+Current&arch=i386&format=html uptime(1)], логинимся на нем (чтобы создать локальный сокет для второго подключения), переходим на другую консоль и снова запрашиваем статистические счетчики:
 <pre>
@@ Строка 187: / Строка 187: @@
 </pre>
-Из примера видно, что при использовании мультиплексирования соединений время выполнения команды uptime(1) на удаленном сервере уменьшилось в 25 раз.
+Из примера видно, что при использовании мультиплексирования соединений время выполнения команды [http://www.openbsd.org/cgi-bin/man.cgi?query=uptime&apropos=0&sektion=1&manpath=OpenBSD+Current&arch=i386&format=html uptime(1)] на удаленном сервере уменьшилось в 25 раз.
 == Создание SOCKS-сервера ==

@@ Строка 106: / Строка 106: @@
 == Безопасный способ получения почты ==
-Для безопасного получения почты с помощью fetchmail можно использовать SSH. Для этого в конфигурационном файле ~/.fetchmailrc необходимо указать следующее:
+Для безопасного получения почты с помощью fetchmail можно использовать SSH. Для этого в конфигурационном файле <span style="color:green;">~/.fetchmailrc</span> необходимо указать следующее:
 <pre>

@@ Строка 20: / Строка 20: @@
 == Ограничение доступа суперпользователя ==
-В большинстве дистрибутивов в целях безопасности доступ суперпользователю по SSH закрыт (PermitRootLogin no), и при попытке зарегистрироваться под root получаем сообщение об ошибке. Для выполнения задач, требующих привилегий администратора, приходится заходить под обычным пользователем и использовать su(1) или sudo(8). Красиво выйти из ситуации поможет директива Match. В качестве аргумента ей передается критерий отбора (User, Group, Host, Address), его значение и параметр, который нужно применить. Для примера разрешим подключение под root только с localhost и из доверенной подсети 192.168.5.0/24:
+В большинстве дистрибутивов в целях безопасности доступ суперпользователю по SSH закрыт (PermitRootLogin no), и при попытке зарегистрироваться под root получаем сообщение об ошибке. Для выполнения задач, требующих привилегий администратора, приходится заходить под обычным пользователем и использовать [http://www.openbsd.org/cgi-bin/man.cgi?query=su&apropos=0&sektion=1&manpath=OpenBSD+Current&arch=i386&format=html su(1)] или [http://www.openbsd.org/cgi-bin/man.cgi?query=sudo&apropos=0&sektion=8&manpath=OpenBSD+Current&arch=i386&format=html sudo(8)].
 <pre>

@@ Строка 5: / Строка 5: @@
 == Отключение прослушивания IPv6 адресов ==
-По умолчанию sshd(8) слушает как на IPv4 так и на IPv6 адресах. Для того что бы отключить возможность работы по IPv6, необходимо изменить параметр AddressFamily:
+По умолчанию [http://www.openbsd.org/cgi-bin/man.cgi?query=sshd&apropos=0&sektion=8&manpath=OpenBSD+Current&arch=i386&format=html sshd(8)] слушает как на IPv4 так и на IPv6 адресах. Для того что бы отключить возможность работы по IPv6, необходимо изменить параметр AddressFamily:
   AddressFamily inet