|
РУКОВОДСТВО ПО НАСТРОЙКЕ И ИСПОЛЬЗОВАНИЮ SECURE SHELL
О шифровании методом публичных ключей
Создание вашего ключа аутентикации и изменение парольной
фразы
Авторизация доступа, директории и права
Вход на удаленную систему
Хранение ключей авторизации в памяти
- запуск системы X11 на локальном дисплее
- запуск системы X11 через сессию xdm
Управление ключами авторизации в памяти
Запуск команд на удаленной системе
Копирование файлов между системами
Изменение стандартных настроек
Ссылки на другие полезные источники информации
О шифровании методом публичных ключей
Шифрование методом публичного ключа использует public key для шифрации
и private key для дешифрации данных. Сам термин public key укзывает на
тот факт, что использовать этот метод можно без страха за безопасность
передаваемых данных или ключ дешифрации, ибо последний просто не передается
по данной технологии.
Это означает, что нет опасности передачи вашего public key или содержимого
файла $home/.ssh/identity.pub по электронной почте или другими методами
системному администратору удаленного сервера, чтобы он поместил эти данные
в файл $home/.ssh/authorized_keys на удаленном сервере.
Если кто-либо хочет получить несанкционированный доступ к вашим данным
или воспользоваться вашим входом при авторизации, то ему необходимо сначала
получить доступ к вашему личному ключу $home/.ssh/identity и соответственно
дешифровать его для идентификации сперва самого себя.
Однако для большей защиты вашего private key, при его генерации с помощью
программы keygen необходимо задать passphrase - парольную-фразу для шифрации
содержимого файла, когда он будет записываться на файловую систему. Это
должно предотвратить от дешифрации личного ключа, даже если кто-либо имеет
доступ в вашу домашнюю директорию и файлам.
Создание вашего ключа аутентикации и изменение парольной фразы
Итак, первое, что вам необходимо сделать - это использовать команду
"ssh-keygen"
для создания собственных ключей авторизации. Достаточно просто запустить
эту команду, ключи, использованные в этой команде по-умолчанию, обычно
удовлетворяют все потребности.
Совет: перед запуском "ssh-keygen" сначала придумайте и запомните фразу -
пароль, которая должна удовлетворять следующим рекомендациям:
- содержать последовательность отдельных слов
- удобнее и лучше, если слова будут разделяться пробелами; это не только
допускается, но и приветствуется в целях увеличения секретности
- изменить некоторые слова на предмет неверного произношения(соответственно
и их написание должно быть изменено)
- заменить некоторые буквы в словах на цифры или добавить набор цифр
в вашу
"секретную" пароль-фразу
Чем большему количеству перечисленных выше рекомендаций будет соответствовать
ваша пароль-фраза, тем надежнее будет она сама и ваш личный ключ - private
key
далее приведен пример создания личного, публичного ключа и их криптование:
/* не забудьте что вводимая passphrase не высвечивается */
unix1% ssh-keygen
Initializing random number generator...
Generating p: .............................................++ (distance
830)
Generating q: .......................................++ (distance 636)
Computing the keys...
Testing the keys...
Key generation complete.
Enter file in which to save the key ($HOME/.ssh/identity):
Enter passphrase: pust' vsegda 2000
Enter the same passphrase again: pust' vsegda 2000
Your identification has been saved in /home/lavr/.ssh/identity.
Your public key is:
1024 37 [lots of numbers] lavr@unix1
Your public key has been saved in /home/lavr/.ssh/identity.pub
unix1%
Если вы имеете несколько accounts (входов в разные системы), то можете
создать несколько отдельных и разных ключей для каждого из них, например:
- для оффиса
- для личной системы
- для Internet service provider (ISP) системы
- для унивеситета
- для научно-исследовательского центра или интститута
Это разграничение позволяет существенно ограничить доступ между этими
организаациями, например использование доступа из одной в другую и
отслеживать несанкционированный доступ по регистрационной информации
Помните, что при необходимости, вы всегда можете изменить свою пароль-фразу
выполнив команду "ssh-keygen" с опцией -p , например:
/* не забудьте что вводимая passphrase не высвечивается */
unix1% ssh-keygen -p
Enter file in which the key is ($HOME/.ssh/identity):
Enter old passphrase: pust' vsegda 2000
Key has comment 'lavr@sunhe'
Enter new passphrase: budet new 3000
Enter the same passphrase again: budet new 3000
Your identification has been saved with the new passphrase.
unix1%
Авторизация доступа, директории и права
Для того, чтобы расширить или ограничить список систем, с которых
разрешен доступ, необходимо создать файл $home/.ssh/authorized_keys,
в который поместить список public key тех систем, которым разрешен доступ.
Обычно пользователи хотят иметь авторизованный доступ на _локальную_
систему, используя локальный ключ (этод метод хорош там, где используется
метод разделяемых домашних директорий с использованием NFS). В данном случае
достаточно просто скопировать файл с public key в файл
$home/.ssh/authorized_keys.
unix1% cd ~/.ssh
unix1% cp identity.pub authorized_keys
Теперь вы можете скопировать файл authorized_keys на другие удаленные
системы, чтобы позволить доступ к ним с локальной системы. Передать этот
файл вы можете по ftp или через rcp/scp.
При появлении доступа к новым или закрытия к старым системам, вы можете
изменять соответственно ваш файл authorized_keys, используя текстовый редактор.
Помните, что каждый ключ - это одна строка файла, а также то, что добавляемые
вами ключи всегда "public key" из файлов с расширением ".pub".
Всегда следите за правами доступа к любым вашим файлам, но особенно
к тем, с которыми связана безопасность вашей работы и сохранность данных.
Если после всех проделанных мероприятий, удаленная система отказывает
вам в доступе, попробуйте проверить права и доступ к :
∙ the home directory itself
∙ the ~/.ssh directory
∙ the ~/.ssh/authorized_keys file
Права на запись должны быть только у вас - владельца. Следующий пример
показывает какими они должны быть:
unix1% cd
unix1% ls -ld . .ssh .ssh/authorized_keys
drwxr-xr-x 36 lavr dug 4096 Jul 25 02:24 .
drwxr-xr-x 2 lavr dug 512 Apr 10 02:30 .ssh
-rw-r--r-- 1 lavr dug 1674 Apr 10 02:29 .ssh/authorized_keys
unix1%
Чтобы удаленная система позволила удаленный доступ, вы можете запретить
права на запись всех, за исключением владельца:
unix1% cd
unix1% chmod go-w . .ssh .ssh/authorized_keys
unix1%
Запомните, проделав эту процедуру на всех системах, вы получите полный
доступ ко всем вашим accounts.
Вход на удаленную систему
Для интерактивного входа на удаленную систему можно использовать
либо
slogin, либо ssh команду, что собственно одно и то же.
Достаточно указать только один входной параметр - имя удаленной системы.
Не забывайте, что пароль или пароль-фраза при вводе с клавиатуры не будет
отображаться на экране.
unix1% slogin spp
Enter passphrase for RSA key 'lavr@spp.jinr.dubna.su': pust' vsegda
2000
Last login: Wed Oct 16 20:37:00 1996 from idefix
[more output from the remote machine]
spp%
Вы можете избежать приглашения для ввода passphrase, сохранив до этого
ключи аутентикации в памяти. Но все равно вы будете вынуждены ввести passphrase,
но лишь однажды, когда будете добавлять их в память.
(см. использование ssh-add)
Если ваше регистрационное имя на обоих системах локальной и удаленной
различаются, вы можете использовать опцию "-l username" для указания
имени на удаленной системе. Как например:
unix1% slogin -l lavr nusun
Last login: Sun Oct 13 14:55:17 1997 from nusun.jinr.ru
[more output from the remote machine]
nusun%
Или изменить настройки в файле конфигурации для удаленной системы.
Если у вас возникли какие-либо проблемы при входе на удаленную систему,
используйте опцию -v для просмотра отладочной информации и все ваши
проблемы исчезнут после того, как вы установите в чем ошибка.
Например вход на интерактивный кластер:
[unix1]~ > slogin lxpub01
OpenSSH_3.8.1p1 FreeBSD-20040419, OpenSSL 0.9.7e-p1 25 Oct 2004
debug1: Reading configuration data /home/lavr/.ssh/config
debug1: Applying options for *
debug1: /home/lavr/.ssh/config line 47: Deprecated option "FallBackToRsh"
debug1: /home/lavr/.ssh/config line 48: Deprecated option "UseRsh"
debug1: Reading configuration data /etc/ssh/ssh_config
debug1: Connecting to lxpub01.jinr.ru [159.93.39.51] port 22.
debug1: Connection established.
debug1: identity file /home/lavr/.ssh/identity type 0
debug1: Remote protocol version 1.99,
remote software version OpenSSH_3.6.1p2-CERN20030917
debug1: match: OpenSSH_3.6.1p2-CERN20030917 pat OpenSSH*
debug1: Enabling compatibility mode for protocol 2.0
debug1: Local version string SSH-2.0-OpenSSH_3.8.1p1 FreeBSD-20040419
debug1: SSH2_MSG_KEXINIT sent
debug1: SSH2_MSG_KEXINIT received
debug1: kex: server->client aes128-cbc hmac-md5 none
debug1: kex: client->server aes128-cbc hmac-md5 none
debug1: SSH2_MSG_KEX_DH_GEX_REQUEST(1024<1024<8192) sent
debug1: expecting SSH2_MSG_KEX_DH_GEX_GROUP
debug1: SSH2_MSG_KEX_DH_GEX_INIT sent
debug1: expecting SSH2_MSG_KEX_DH_GEX_REPLY
debug1: Host 'lxpub01.jinr.ru' is known and matches the DSA host key.
debug1: Found key in /home/lavr/.ssh/known_hosts:74
debug1: ssh_dss_verify: signature correct
debug1: SSH2_MSG_NEWKEYS sent
debug1: expecting SSH2_MSG_NEWKEYS
debug1: SSH2_MSG_NEWKEYS received
debug1: SSH2_MSG_SERVICE_REQUEST sent
debug1: SSH2_MSG_SERVICE_ACCEPT received
Scientific Linux CERN Release 3.0.6 (SL)
debug1: Authentications that can continue: publickey,password,hostbased
debug1: Next authentication method: publickey
debug1: Offering public key: /home/lavr/.ssh/id_rsa
debug1: Server accepts key: pkalg ssh-rsa blen 149
debug1: Authentication succeeded (publickey).
debug1: channel 0: new [client-session]
debug1: Entering interactive session.
debug1: Requesting X11 forwarding with authentication spoofing.
debug1: Requesting authentication agent forwarding.
Last login: Thu Mar 16 12:00:31 2006 from unix1.jinr.ru
Dear users of lxpub interactive cluster!
We strongly advise you to run long terms jobs via batch system
only. Try "man qsub".
----------------------- Important note ------------------------
You should call "pbspwstore" and type your AFS password every
time when you have changed AFS password (and for the first time
of course) for PBS will be able to access your AFS home.
---------------------------------------------------------------
For additional documentations, FAQ and hints have a look at:
http://www.jinr.ru/unixinfo/
############################################################
Please read! The most important news about state of upgrade:
at the top of http://www.jinr.ru/unixinfo/
############################################################
lxpub01:~ >
Хранение ключей авторизации в памяти
Если вам приходится часто открывать соединения с удаленной системой,
то вероятно будет удобней запускать ваш сеанс через "ssh-agent".
Агент будет обеспечивать дешифрацию ключей аутентикации для всех команд
при создании новых соединений.
Для запуска ssh-agent в качестве параметра необходимо указать имя команды,
которая будет им запущена, обычно это либо ваш "shell", либо команда запуска
оконной среды. Соответствено по выходу из такой команды все ключи будут
удалены из памяти.
unix1% ssh-agent $SHELL
unix1%
Теперь нам только осталось добавить ключи в память, чтобы они были доступны
для других команд.
Рассмотрим запуск оконной среды X11 на локальный дисплей
Если у вас имеется локальная машина с установленной и настроенной
средой X window system, вы можете получить полноценную оконную среду, но
с ключами в памяти при запуске через ssh-agent. Обычно X window system
запускается отработкой скрипта startx с инициализацией клиентов из домашнего
- .xinitrc или при его отсутствии системного файла xinitrc.
Например, это можно выполнить так:
unix1% ssh-agent startx &
Если ваша рабочая станция имеет виртуальные консоли, как в этом примере,
то довольно удобно запускать X11 в фоновом режиме, при котором остается
возможность продолжать использовать для работы ту консоль, с которой мы
стартовали X11, независимо от них.
Системным администраторам могу описать свой путь решения запуска X11:
a) запуск X11 только через ssh-agent
b) обычный запуск и с использованием ssh-agent
Первый способ состоит в том, что пользователя заставляют в принудительном
порядке стартовать оконную среду исключительно с использованием ssh-agent.
Здесь можно придумать массу разнообразных вариантов со своими плюсами
и минусами, например создание alias на команду startx во входных скриптах:
unix1% ls -la /usr/local[/etc]/.[a-z]*
-rw-r--r-- 1 root wheel 6 Jun 6 1997 /usr/local/etc/.bash_logout
-rw-r--r-- 1 root wheel 2361 Dec 29 1997 /usr/local/etc/.bash_profile
-rw-r--r-- 1 root wheel 1543 Dec 29 1997 /usr/local/etc/.bashrc
-rwxr-xr-x 1 root wheel 1267 May 18 13:46 /usr/local/etc/.cshrc
-rwxr-xr-x 1 root wheel 1534 Jan 23 14:59 /usr/local/etc/.login
unix1%
На моих серверах пользователи в основном используют в качестве SHELL:
sh,bash,csh,tcsh, я, как и большая масса системных администраторов,
заменяю стандартные скрипты, которые обычно находятся в директории /etc/skel
или, в зависимости от системы, в иной директории на болванки с одной
строкой-вызовом скриптов доработанных и проверенных системным администратором,
в которые и вставляется alias на startx.
Примеры:
пользовательские файлы настройки среды:
unix1% cat .cshrc
source /usr/local/etc/.cshrc
unix1% cat .login
source /usr/local/etc/.login
unix1% cat .bashrc
. /usr/local/etc/.bashrc
unix1% cat .bash_profile
. /usr/local/etc/.bash_profile
unix1%
вырезки из /usr/local/etc/.bashrc и /usr/local/etc/.cshrc[.login]
соответственно (почему указан .login думаю системные администраторы меня поймут)
unix1% grep startx /usr/local/etc/.[a-z]*
/usr/local/etc/.bashrc:alias startx='ssh-agent startx'
/usr/local/etc/.cshrc:alias startx 'ssh-agent startx'
unix1%
Соответствующие изменения производятся и с системным xinitrc ,в
который добавляется проверка на собственно аутентикацию.
unix1% grep ssh /usr/X11/lib/X11/xinit/xinitrc
#-ssh-auth
until ssh-askpass | ssh-add -p; do true; done
unix1%
Указанная выше строка должна запускаться до инициализации X clients
и вызова оконного менеджера.
----------------------- cut from xinitrc -------------------------------------------
...
until ssh-askpass | ssh-add -p; do true; done
xterm -geometry 80x40+8+9 -name login -ls -sb &
xconsole -geometry 480x130+0-0 -daemon -notify -verbose -fn fixed &
exec fvwm
----------------------- end of cut from xinitrc ------------------------------------
Минусы этого способа в том, что пользователь может использовать только
свои входные настройки среды - имеет право, и соответственно свой .xinitrc.
Остается лишь одно средство оповещения через различные системы сообщений
и предупреждений, если пользователь либо просто глуп, либо достаточно умен
и игнорирует соблюдение методов предосторожностей, он способствует нарушению
безопасности вашей системы. К такому пользователю должны быть применены
соответствующие санкции, вплоть до полного отключения не только от отдельных
серверов, но и от сети в целом.
Второй способ технически мало отличается от первого, ибо приемы могут
быть взаимодополнены или заменены, я подразумевал саму идею, в первом случае
принудительный запуск X11 через ssh-agent, а в данном способе использовать
некий переходной этап - разрешить использование как обычного запуска, так
и с использованием ssh-agent.
Просто переименовываем известный скрипт startx допустим в startX
unix1% mv startx startX
А startx изображаем следующим образом:
#!/bin/sh
if [ -d $HOME/.ssh ]
then ssh-agent startX
else startX
fi
Соответствующие дополнения вносим и в системный xinitrc до старта x-clients
и оконного менеджера
------------------ cut from xinitrc -------------------------------------------------
if [ -d $HOME/.ssh ]
then until ssh-askpass | ssh-add -p; do true; done
fi
------------------ cut here ---------------------------------------------------------
Примечания: все вышеизложенное может использоваться обычными пользователями
в собственных настройках вызова X11 через ssh-agent. Для этого им необходимо
сделать следующее:
unix1% cd
unix1% cp /usr/X11[R...]/lib/X11/xinit/xinitrc .xinitrc
Далее вставить строку "until ssh-askpass | ssh-add -p; do true; done"
в свой .xinitrc в нужное место, описано выше и, в зависимости от
используемого SHELL, вставить alias на вызов startx, описано выше.
Будьте аккуратны, все вышеизложенное касается запуска X11 на локальной
машине!
[R...] - означает что путь зависит от того как и какая версия X11 установлена.
Рассмотрим запуск X11 через сессию xdm
Если на вашем сервере или рабочей станции X11 запускается через
сеанс XDM, вам необходимо создание неких условий, благодаря которым клиенты
будут запущены под ssh-agent. Простейший способ, практически схожий с предыдущим
- startx. Произвести инициализацию клиентов через .xinitrc, который в свою
очередь будет вызываться из стартового файла .xsession.
В качестве примера смотрите .xsession ниже, ssh-agent стартует
только при наличии в домашней директории пользователя поддиректории .ssh.
#!/bin/sh
if [ -d $HOME/.ssh ]
then EXEC="exec ssh-agent"
else EXEC="exec"
fi
if [ -x $HOME/.xinitrc ]
then $EXEC $HOME/.xinitrc
else $EXEC xterm -geometry 80x24+0-60 -ls
fi
Не забудьте проверить статус ваших скриптов и сделайте их исполняемыми:
unix1% chmod a+x ~/.xinitrc ~/.xsession
Примечания: если ваш администратор не позаботился о настройках системы,
вам достаточно настроить свои файлы .xinitrc и .xsession, однако, если в
вашей системе X11 запускается иным - нестандартным способом, лучше всего
обратититься к системному администратору.
На мой взгляд лучше заранее обратиться к администратору и выяснить
все вопросы и это касается любой темы, не только безопасности системы.
Важное: все изложенное не может быть применено к X-terminal'у, который
остается узким местом в безопасности вашей системы и сети.
Управление ключами авторизации в памяти
До того, как ваше соединение будет авторизовано без использования passphrase,
вы можете использовать ssh-add для добавления необходимых ключей в память.
Для добавления обычных ключей в память локальной системы не требуется
дополнительных опций. А passphrase будет затребован для дешифрации этих
ключей и не будет отображаться при вводе с клавиатуры.
unix1% ssh-add
Need passphrase for /home/lavr/.ssh/identity (lavr@unix1.jinr.dubna.su).
Enter passphrase: pust' vsegda 2000
Identity added: /home/lavr/.ssh/identity (lavr@unix1.jinr.dubna.su)
Можно указать отличное имя файла от identity, где будет хранится ваш
личный ключ, если вас не устраивают значения по умолчанию, только не забывайте
затем, что там будет храниться ваш private key.
Опция -d позволяет удалять ключи из памяти, не забудьте, что в
SSH нет команды "ssh-delete".
unix1% ssh-add -d ~/.ssh/isp
Получить список всех текущих ключей в памяти - опция-l .
unix1% ssh-add -l
1024 33 [lots of numbers] lavr@unix1.jinr.dubna.su
Ну и конечно вы можете использовать ключ -D для удаления всех
ключей из памяти.
unix1% ssh-add -D
Этого достаточно, если вы добавили ключи в память на удаленной системе
и не хотите заново установить соединение до тех пор, пока ключи не будут
удалены.
Запуск команд на удаленной системе
Команда ssh может оказаться удобной для использования запуска программ
или команд на удаленной системе без осуществления интерактивного входа
на нее. Результат действия которых - вывод может быть отображен и управляться
на локальной системе. Ниже приведен подобный пример.
[unix1]~ > ssh lxpub02 who
Scientific Linux CERN Release 3.0.6 (SL)
root pts/0 Mar 16 01:22 (mammoth.jinr.ru)
usubov pts/1 Mar 16 07:57 (nusun9.jinr.ru)
usubov pts/6 Mar 16 11:32 (lxpub01.jinr.ru)
tanyusha pts/3 Mar 16 11:11 (bk026.jinr.ru)
yuldash pts/2 Mar 16 12:00 (bk0134)
[unix1]~ >
Если вы работаете в X Window System, то можете запустить xterm для получения
интерактивного сеанса на удаленной машине:
[unix1]~ > ssh -n lxpub02 xterm &
[1] 69915
[unix1]~ >
Использование опции -n запрещает чтение со стандартного вывода
(в /dev/nul) и запускает ssh в фоновом режиме. Однако не стоит использовать
данный метод запуска, если удаленная сторона пытается запрашивать вас ввести
passphrase или passowrd.
Копирование файлов между системами
Вы можете копировать файлы между локальной и удаленной системами
или между двумя удаленными системами используя команду scp, и все это не
требует какого-либо вашего присутствия на удаленной системе. Для указания
файла на удаленной машине достаточно лишь перед именем файла указать имя
удаленной машины и отделить от файла двоеточием, host:filename.
Если вы опустили имя выходного файла или директории при копировании,
тогда будет использоваться имя источника копирования. Самый простой способ
задания имени сохранения копируемого файла и помещения в текущую директорию
это указание точки:
unix1% scp -p spp:dead.letter .
unix1%
Опция -p необязательна, она указывает на то, чтобы все атрибуты
файла, такие как время модификации, доступа и другие режимы, сохранились
от оригинального копируемого файла. Однако это для каждого пользователя
индивидуально и зависит от личных задач и целей.
unix1% scp -r lxpub03:source src
unix1%
В данном примере опция -r означает, что необходимо рекурсивно
скопировать директорию source, расположенную на машине "lxpub03", в директорию
src на "unix1".
Можно также отметить еще ряд полезных ключей:
-C - копирование с компрессией, понятно, что нет смысла использовать
данную опцию для копирования уже сжатых данных
-v - как и в остальных утилитах ssh[slogin] служит для вывода отладочной
информации.
Необходимо заметить, что относительные имена на локальной и удаленной
системах разрешаются по разному:
- на локальной за базу принимается текущая директория
- на удаленной за базу принимается домашняя директория пользователя
unix1% scp ultra:ftptmp/ftp.out spp:temp/ftp.out.ultra
unix1%
Примечание: необходимо отметить, что при копировании с удаленной
машины на
удаленную, копирование происходит непосредственно между теми двумя
машинами без участия локальной.
Изменение стандартных настроек
Значения по умолчанию могут устанавливаться и изменяться каждым
пользователем в файле ~/.ssh/config в дополнение или альтернативу
системному файлу -
/etc/ssh_config.
Каждая строка в конфигурации начинается с ключего слова HOST. Для задания
общих значений можно использовать образцы соответствия:
* ? соответсвует любому символу
* * соответствует пустой или последовательности любого количества символов
обычно используются следующие ключевые слова (умолчание в скобках):
Compression yes/no (no)
использование компрессии в соединениях
CompressionLevel 1-9 (6)
уровень сжатия: 1 - самый быстрый, 9
- самый медленный (достигается
максимальная компрессия), имеет смысл
использовать на медленных
соединениях
FallBackToRsh yes/no (yes)
если не удается установить секретное
соединение с использованием SSH,
пытаться перейти на использование Rsh,
в системах со строгим соблюдением
секретности данная опция отключается
KeepAlive yes/no (yes)
Управляет использование сообщения TCP
keepalive. Когда используется,
позволяет определять наличие связи в
сети и автоматически закрывать
соединение при обрыве или потере соединения.
User account (local account)
Укзывает имя на удаленной системе. Можете
добавить эту характеристику
вместо использования опции -l.
Ниже пример файла ~/.ssh/config.
Host nusun.jinr.ru
User lavr
Compression no
Host sunhe.jinr.ru
User lavr
CompressionLevel 6
FallBackToRsh no
KeepAlive yes
Host *
Compression yes
CompressionLevel 9
FallBackToRsh yes
KeepAlive no
Не забывайте, что host-зависимые переменные следует определять до задания
остальных - общих параметров (по-умолчанию), те, общие параметры для ssh
укажите в самом конце конфигурационного файла, а выше задайте конкретные
и специфические значения для индивидуальных host'ов и подсетей.
Из верхнего примера видно, что для всех hosts приписывается работать
со сжатием данных - уровень 9, с переходом на rsh и без keepalive.
И тем не менее с nusun работать под account=lavr, с sunhe с более быстрой
компрессией и сваливанием на rsh ибо там отключен sshd и проверкой связи.
Для изучения полного списка опций читайте руководство по ssh/sshd.
Ссылки на другие полезные источники информации
/* данный пункт готовится */
| 
