Настройка SSH входа без пароля
Чтобы настроить SSH-вход без пароля в Linux, все, что вам нужно сделать, это сгенерировать открытый ключ аутентификации и добавить его в файл удаленных хостов.
Следующие шаги описывают процесс настройки входа по SSH без пароля:
-
Проверьте существующую пару ключей SSH.
Перед созданием новой пары ключей SSH сначала проверьте, есть ли у вас уже ключ SSH на вашем клиентском компьютере, потому что вы не хотите перезаписывать существующие ключи.
Выполните следующую команду ls, чтобы проверить наличие существующих ключей SSH:
Если есть существующие ключи, вы можете использовать их и пропустить следующий шаг или создать резервную копию старых ключей и сгенерировать новый.
Если вы видите или это означает, что у вас нет ключа SSH, и вы можете перейти к следующему шагу и сгенерировать новый.
-
Создайте новую пару ключей SSH.
Следующая команда сгенерирует новую пару ключей SSH 4096 бит с вашим адресом электронной почты в качестве комментария:
Нажмите чтобы принять расположение и имя файла по умолчанию:
Затем инструмент попросит вас ввести безопасную парольную фразу. Независимо от того, хотите ли вы использовать кодовую фразу, решать вам, если вы решите использовать кодовую фразу, вы получите дополнительный уровень безопасности. В большинстве случаев разработчики и системные администраторы используют SSH без парольной фразы, поскольку они полезны для полностью автоматизированных процессов. Если вы не хотите использовать кодовую фразу, просто нажмите .
В целом взаимодействие выглядит так:
Чтобы убедиться, что ключи SSH сгенерированы, вы можете указать свои новые закрытые и открытые ключи с помощью:
-
Скопируйте открытый ключ
Теперь, когда вы сгенерировали пару ключей SSH, чтобы иметь возможность войти на свой сервер без пароля, вам необходимо скопировать открытый ключ на сервер, которым вы хотите управлять.
Самый простой способ скопировать ваш открытый ключ на сервер — использовать команду . На вашем локальном машинном терминале введите:
Вам будет предложено ввести пароль :
После аутентификации пользователя открытый ключ будет добавлен в файл удаленного пользователя, и соединение будет закрыто.
Если по какой-либо причине недоступна на вашем локальном компьютере, вы можете использовать следующую команду для копирования открытого ключа:
-
Войдите на свой сервер с помощью ключей SSH
После выполнения описанных выше действий вы сможете войти на удаленный сервер без запроса пароля.
Чтобы проверить это, просто попробуйте войти на свой сервер через SSH:
Если все прошло успешно, вы сразу же войдете в систему.
Шаблоны в файле настроек SSH
Шаблон состоит из нуля или более символов, которые не являются белыми пробелами, ‘*’ (подстановочного символа, который соответствует нулю или более символам), а также ‘?’ (подстановочный символ, который соответствует ровно одному любому символу). Например, чтобы охарактеризовать любой хост в наборе доменов «.co.uk» можно использовать следующий шаблон:
Host *.co.uk
Следующий шаблон будет соответствовать любому хосту в сетевом диапазоне 192.168.0.:
Host 192.168.0.?
Список шаблонов — это несколько шаблонов, разделённых запятой. Шаблоны внутри списка могут иметь противоположное значение если перед ними стоит восклицательный знак («!»). Например, для разрешения ключа использовать откуда угодно внутри организации, кроме пула «dialup», можно использовать следующее (в authorized_keys):
from="!*.dialup.example.com,*.example.com"
Помните, что отрицательное совпадение никогда само по себе не даст положительных результатов. Например, попытка сопоставить хост «host3» следующими списку шаблонов не найдёт совпадений:
from="!host1,!host2"
Решением для предыдущей ситуации является включение термина, который приведёт к положительному совпадению, им может быть подстановочный символ:
from="!host1,!host2,*"
Дополнительные настройки безопасности
Есть и другие рекомендуемые конфигурации, чтобы избежать нежелательных подключений к нашему SSH-серверу. Эти соединения:
- Войти : Мы установим время, необходимое для ввода пароля, чтобы злоумышленнику не приходилось «много думать».
- MaxAuthTries : Количество разрешенных попыток при вводе пароля перед отключением.
- MaxStartups : Количество одновременных входов в систему с IP-адреса, чтобы избежать использования грубой силы в нескольких сеансах одновременно.
- AllowUsers : Это для создания белого списка пользователей. Этот параметр позволяет нам настроить пользователей, которые смогут подключиться. Это очень ограничительная мера, но в то же время очень безопасная, поскольку она блокирует все подключения пользователей, которых нет в списке. Пользователи, которые у нас здесь, смогут подключиться, а остальные — нет.
- DenyUsers : Аналогично предыдущему, но теперь мы создаем черный список. Пользователи, которые у нас здесь, не смогут подключиться, а остальные подключатся.
- AllowGroups / DenyUsers : Точно так же, как указано выше, но вместо создания черного / белого списка пользователей это группы пользователей.
Например, файл конфигурации для sshd_config будет следующим:
Дополнительной мерой безопасности является настройка алгоритмов обмена ключами, симметричного шифрования, а также конфигурации HMAC для проверки целостности. В настоящее время рекомендуется применять следующую конфигурацию для обеспечения очень высокой безопасности:
С этой конфигурацией у нас будут лучшие криптографические наборы для сервера, однако старые клиенты могут не иметь возможности подключиться, поскольку они не поддерживают эти алгоритмы
Мы должны принять во внимание эту деталь и проверить, какие алгоритмы совместимы, а какие нет
Если мы создали новые ключи RSA или DSA для ключей с большей битовой длиной, мы должны поместить их в файл конфигурации (или заменить предыдущие, и, таким образом, нам не придется трогать файл конфигурации), таким образом мы получим дополнительная безопасность, если, например, мы используем ключи RSA длиной 4096 бит или выше.
Чтобы сгенерировать новые 4096-битные ключи RSA, нам просто нужно выполнить следующую команду:
Если мы хотим сгенерировать новые ключи ECDSA (с максимальной длиной 512 бит) или ED25519, нам нужно будет ввести следующие команды:
5.12 Почему ssh зацикливается с сообщением «Secure connection refused»?
Ssh пытается вернуться к методу «r» команд когда не может соединиться с
sshd демоном удаленной машины и в результате пытается запустить старый rsh для
использования старого протокола.
Существуют всего два предположения почему это происходит:
-
Возможно вы установили ssh как rsh и забыли задать опцию при конфигурировании
--with-rsh=PATH и в результате поисков rsh, ssh находит вместо него
себя и снова запускает. Просто перекомпилируйте ssh с учетом сказанного. -
Вы переместили старые rsh и rlogin в другую директорию, отличную от оригинального
места расположения, но при этом вызов осуществляете корректно, те из того места
куда положили. Но при этом не учли что старый исполняемый модуль rsh содержит в
своем теле жестко-привязанный путь к rlogin.
В этом случае вы можете перенести старые бинарники rsh и rlogin в /usr/old, отпатчить их с запустив Perl скрипт
perl -pi.orig -e 's+/usr/(bin|ucb)/rlogin+/usr/old/rlogin+g ;' /usr/old/rsh
/usr/old/rsh.orig
И теперь осталось переконфигурировать ssh с --with-rsh=/usr/old/rsh.
Для плохо понимающих, в последнем варианте учитывается что путь в бинарнике имеет конкретную длинну, те чревато заменять например /usr/bin/rlogin на /usr/local/old/rlogin.
Определение ключей
Если вы используете SSH-ключи, эти параметры помогут вам управлять ключами для каждого хоста.
IdentityFile: Эта опция может использоваться для указания расположения ключа каждого хоста. Если ваши ключи находятся в местах по умолчанию, каждый из них будет проверен автоматически. Если у вас есть несколько ключей, и все они используются для разных целей, эта опция укажет точный путь, где можно найти правильный ключ.IdentitiesOnly: Благодаря этой опции SSH будет полагаться только на тождества, предоставленные в файле конфигурации. Она может быть необходима, если у агента SSH в памяти есть альтернативные ключи, которые недействительны для данного хоста.
Эти параметры особенно полезны, если вам нужно отслеживать большое количество ключей разных хостов и использовать один или несколько агентов SSH.
Тест на практике
Прежде всего, нам нужен пакет OpenSSH версии 8.2 на клиентской и серверной машинах. И здесь кроется основная проблема с этим решением на момент написания этого материала (май 2020). Поскольку 8.2 — это новейшая версия, выпущенная в феврале 2020 года, во многих ОС пока еще используются предыдущие версии.
Хорошая новость в том, что эта ситуация естественным образом будет улучшаться с течением времени, и все больше ОС будут добавлять поддержку нужной нам версии. Однако мы очень хотели испытать этот функционал на практике и поэтому нашли сочетание клиентских и серверных ОС для нашего практического теста.
По состоянию на май 2020 только несколько популярных дистрибутивов Linux имеют версию OpenSSH 8.2 в своих репозиториях. Среди них Fedora 32, Ubuntu 20.04 LTS и Kali Linux.
Создание ключей SSH
Первый шаг для настройки аутентификации ключей SSH на сервере заключается в том, чтобы сгенерировать пару ключей SSH на локальном компьютере.
Для этого мы можем использовать специальную утилиту , которая входит в стандартный набор инструментов OpenSSH. По умолчанию она создает пару 2048-битных ключей RSA, что подходит для большинства сценариев использования.
Сгенерируйте на локальном компьютере пару ключей SSH, введя следующую команду:
Утилита предложит вам выбрать место размещения генерируемых ключей. По умолчанию ключи хранятся в каталоге внутри домашнего каталога вашего пользователя. Закрытый ключ будет иметь имя , а соответствующий открытый ключ будет иметь имя .
На этом этапе лучше всего использовать каталог по умолчанию. Это позволит вашему клиенту SSH автоматически находить ключи SSH при попытке аутентификации. Если вы хотите выбрать нестандартный каталог, введите его сейчас, а в ином случае нажмите ENTER, чтобы принять значения по умолчанию.
Если ранее вы сгенерировали пару ключей SSH, вы можете увидеть следующий диалог:
Если вы решите перезаписать ключ на диске, вы больше не сможете выполнять аутентификацию с помощью предыдущего ключа. Будьте осторожны при выборе варианта yes, поскольку этот процесс уничтожает ключи, и его нельзя отменить.
Далее вам будет предложено ввести парольную фразу для ключа. Это опциональная парольная фраза, которую можно использовать для шифрования файла закрытого ключа на диске.
Возможно вам будет интересно, в чем заключаются преимущества ключа SSH, если вам все равно нужна парольная фраза. Вот некоторые его преимущества:
- Закрытый ключ SSH (защищенная паролем часть) никогда не доступен через сеть. Парольная фраза используется только для расшифровки ключа на локальном компьютере. Это означает, что парольную фразу нельзя взломать через сеть методом прямого подбора.
- Закрытый ключ хранится в каталоге с ограниченным доступом. Клиент SSH не принимает закрытые ключи, хранящиеся в каталогах, доступ к которым не ограничен. У самого ключа могут быть ограниченные разрешения (чтение и запись доступны только владельцу). Это означает, что другие пользователи системы не смогут создать уязвимость.
- Для попытки взлома защищенного парольной фразой закрытого ключа SSH злоумышленнику уже необходим доступ к системе. Это означает, что у него уже должен быть доступ к учетной записи пользователя или учетной записи root. Если вы окажетесь в такой ситуации, парольная фраза может помешать злоумышленнику сразу же попасть на ваши другие серверы. Это может дать вам достаточно времени, чтобы создать и внедрить новую пару ключей SSH и запретить доступ с взломанным ключом.
Поскольку закрытый ключ недоступен через сеть и защищен системой разрешений, доступ к этому файлу будет только у вас (и у пользователя root). Парольная фраза служит дополнительным уровнем защиты на случай взлома одной из этих учетных записей.
Парольная фраза представляет собой необязательное дополнение. Если вы решите ее использовать, вам нужно будет вводить ее при каждом использовании соответствующего ключа (если вы не используете программный агент SSH, хранящий зашифрованный ключ). Мы рекомендуем использовать парольную фразу, но если вы не хотите ее задавать, вы можете просто нажать ENTER, чтобы пропустить этот диалог.
Теперь у вас есть открытый и закрытый ключи, которые вы можете использовать для аутентификации. Следующим шагом будет размещение открытого ключа на сервере, что позволит использовать аутентификацию SSH для входа в систему.
Настройка брандмауэра
Как известно, брандмауэры могут блокировать определённые порты и/или сетевые сервисы. Брандмауэров существует множество и в разных дистрибутивах Linux используются разные брандмауэры. Так, для Ubuntu это UFW, а для CentOS – FirewallD. Также можно использовать стандартный сервис iptables.
В зависимости от того, какой порт используется для подключения по SSH, необходимо настроить соответствующее подключение для обслуживания брандмауэром. Для начала нужно узнать, какие правила используются в данный момент. Для iptables это позволяет сделать команда:
$ iptables -nL Chain INPUT (policy ACCEPT) target prot opt source destination Chain FARWARD (policy ACCEPT) target prot opt source destination Chain OUTPUT (policy ACCEPT) target prot opt source destination
Если политика iptables по-умолчанию DROP (или REJECT), то необходимо для правил цепочки INPUT задать разрешение для порта, используемого для SSH.
Для брандмауэра FirewallD получить список используемых правил позволяет команда:
$ firewall-cmd --list-services
Для работы SSH в выводе должно быть правило «dhcpv6-client http ssh». Также необходимо проверить и порт, заданный для SSH. Для этого вместо опции «—list-services» нужно использовать «—list-ports».
Для брандмауэра UFW нужно выполнить:
$ ufw status Status: active To Action From -- ------- ------ 22 LIMIT Anywhere 443 ALLOW Anywhere . . . 22 (v6) LIMIT Anywhere (v6)
Как видно, в списке должен присутствовать порт SSH, в данном случае 22. Он может быть и другим, в зависимости от того, что задано в настройках сервера SSH.
Параметры командной строки SSH
Давайте рассмотрим некоторые параметры, доступные с помощью команды ssh.
ssh -C
Используйте опцию -C с ssh для запроса сжатия всех данных, полученных или переданных с удаленного сервера. Синтаксис команды ниже
например
ssh -v
Параметр -v используется с командой ssh для отладки ssh-клиента. Ниже приведен синтаксис:
например:
Для отладки ssh-клиента используйте параметр -v
ssh -b
Опция -b используется для привязки IP-адреса к SSH-соединению. IP — адрес будет использоваться в качестве исходного адреса SSH-соединения. Это применяется, когда у клиента более двух IP-адресов, и вы можете не знать, какой IP-адрес используется для создания соединения с сервером SSH.
Например:
Команда свяжет IP-адрес с удаленным сервером. Мы можем проверить это, используя команду для проверки соединения.
Привязка IP-адреса к SSH-соединению
ssh -F
Параметр -F используется вместе с командой ssh для указания конфигурации для каждого пользователя. Файл конфигурации по умолчанию ~/. ssh/config.
Чтобы использовать определенный файл конфигурации, используйте параметр -F следующим образом.
Например:
ssh -L
Опция -L используется для переадресации локальных портов. Переадресация локальных портов позволяет нам перенаправлять трафик с нашего хоста в порт назначения через прокси-сервер.
Основной синтаксис для переадресации локальных портов такой.
Например выполните следующую команду для подключения к удаленному хосту на порт 3306, пользователя kali с IP 192.168.239.134 с локального хоста 192.168.239.133 на порту 3336.
![Ssh (secure shell) faq - frequently asked questions [russian edition]](https://fuzeservers.ru/wp-content/uploads/e/0/8/e084eaf75f5087acbab30316858f389f.png)
Переадресация локальных портов SSH
ssh -R
Опция -R используется вместе с командой SSH для включения удаленной переадресации портов. Это означает, что вы можете перенаправить порт на удаленном сервере на порт локального компьютера, который затем будет перенаправлен на порт конечного компьютера.
Основной синтаксис для переадресации удаленных портов следующий.
Например:
Команда заставит ssh прослушивать ssh-сервер порт 3336 и перенаправлять весь трафик на порт 3000.
Синтаксис для переадресации удаленных портов SSH
ssh -C -D
Опция -D включает динамическую переадресацию портов. Обычный порт SOCKS-1001, однако можно использовать любой номер порта; тем не менее, некоторые программы будут работать только на порту 1001.
Основной синтаксис динамической пересылки выглядит следующим образом.
Например
Параметр -D указывает динамическую переадресацию портов на 1001 порт, а опция -C включает сжатие.
Динамическая переадресация портов SSH
ssh -X
Опция -X используется вместе с ssh для пересылки X11. Ниже приведен синтаксис для пересылки X11.
Используйте следующую команду, чтобы включить переадресацию X11 для пользователя kali с IP-адресом 192.168.239.134.
SSH -Y
Параметр -Y используется вместе с ssh для доверенной переадресации X11. Это означает, что удаленный X11 будет иметь полный доступ к исходному дисплею X11.
Используйте следующую команду, чтобы включить доверенную переадресацию. X11 для пользователя kali с IP-адресом 192.168.239.134.
Параметр -Y для доверенной переадресации X11 SSH
ssh -o
Параметр -o можно использовать с другими параметрами.
Например:
Если вы используете ssh -o «batchmode=yes», команда успешно выполнится на удаленной машине, если включено подключение без пароля, в противном случае команда вернет ошибку.
ssh -o «batchmode=yes»
Некоторые из наиболее важных параметров командной строки показаны в следующей таблице.
| SSH Параметр (опция) | Описание |
| -А | Позволяет перенаправлять соединение агента аутентификации. |
| -а | Этот параметр отключает перенаправляемое соединение агента аутентификации. |
| -b | Параметр используется для привязки адресов источников. |
| -С | Этот параметр используется для сжатия данных. |
| -c cipher_spec | Параметр выбирает спецификацию шифра для шифрования сеанса. |
| -d | Эта опция отвечает за динамическую переадресацию портов на уровне приложений. |
| -E log_file | Параметр добавляет журналы отладки в файл log_file вместо стандартной ошибки. |
| -F config file | Этот параметр указывает файл конфигурации для каждого пользователя. |
| -g | Эта опция позволяет удаленным хостам подключаться к локальным перенаправленным портам. |
| -i identity_file | Опция считывает закрытый ключ для аутентификации с открытым ключом. |
| -j | Параметр определяет директиву конфигурации ProxyJump. |
| -l login_name | В этом параметре указывается пользователь для входа на удаленный компьютер. |
| -p port | Параметр используется для указания порта для подключения к удаленному хосту. |
| -q | Это тихий режим. |
| -V | Подробный режим. |
| -Х | Параметр позволяет переадресовать X11 |
| -Y | Эта опция обеспечивает надежную переадресацию X11 |
Использование ключа
Ввод пароля для подключения через SSH — раздражающая процедура. У меня почти никогда не получалось ввести его правильно с первого раза. Поэтому я начал искать информацию о том, как подключиться к серверу через SSH без пароля. Простое и безопасное решение — использование ключа. Почему это безопаснее? Потому что пароль можно подобрать. Чтобы исключить такую вероятность, многие пользователи выбирают авторизацию с помощью ключа.
Суть процедуры в формировании двух ключей: публичного и приватного. Первый копируется на сервер, а второй остается на компьютере пользователя и не передается по сети. В таком случае пароль при подключении не требуется. Когда вы подключаетесь к серверу через SSH, публичный ключ взаимодействует с приватным и открывает доступ к удаленному управлению.
Генерирование ключа и подключение на Windows
Для удобства используем программу PuTTy. Вместе с ней устанавливается утилита PuTTYgen — в ней можно сгенерировать публичный и приватный ключи.
- Запустите программу PuTTYgen.
- Нажмите на кнопку Gengerate.
- Водите курсором мышки по рабочему столу, чтобы сгенерировать случайные значения ключей.
- Нажмите на кнопку Save private key, чтобы сохранить на жестком диске приватный ключ. Место хранения может быть любым — его нужно указать в параметрах PuTTY. Сделаем это позже.
- Скопируйте публичный ключ в буфер обмена (Ctrl + C) и закройте генератор ключей.
Теперь нужно перенести публичный ключ на сервер. Запустите программу PuTTY и подключитесь к серверу с помощью пароля. Затем последовательно введите следующие команды:
mkdir ~/.ssh chmod 0700 ~/.ssh touch ~/.ssh/authorized_keys chmod 0644 ~/.ssh/authorized_keys
Эти команды создают на сервере папку и файл для хранения ключей, а также ограничивают к ним доступ — получить его может только владелец.
Следующий шаг — вставка публичного ключа из буфера обмена в файл authorized_keys. Для этого используется команда cat > .ssh/authorized_keys. После ввода команды щелкните по окну терминала правой кнопкой, чтобы вставить скопированный ранее публичный ключ. Для завершения ввода нажмите на сочетание клавиш Ctrl+D.
Вернитесь в настройки PuTTY. Перейдите в раздел Connection — SSH — Auth. Нажмите на кнопку Browse и укажите путь к приватному ключу, который вы ранее сохранили на жестком диске.
Теперь для подключения к серверу через SSH пароль не нужен — достаточно указать логин и IP-адрес сервера.
Генерирование ключа и подключение на Linux и macOS
Теперь посмотрим, как подключиться через SSH ключи на Linux и macOS.
- Запустите терминал на локальном компьютере.
- Выполните команду ssh-keygen, чтобы сгенерировать ключи.
- Нажмите на Enter, чтобы сохранить ключи.
Генератор предложит также задать кодовую фразу для ключа. Это дополнительная мера безопасности: если кто-то получит доступ к вашей локальной машине, то все равно не сможет подключиться к серверу через SSH. Минус один — вам тоже придется постоянно вводить ключевую фразу. Можно отказаться от этой меры защиты, просто нажав на клавишу Enter.
На этом процедура создания ключей завершена. Файлы d_rsa (приватный ключ) и id_rsa.pub (публичный ключ) хранятся в папке ~/.ssh/. Осталось скопировать открытую часть ключа на сервер.
- Вернитесь в терминал.
- Выполните команду ssh-copy-id [email protected], где root — логин для подключения к серверу по SSH, а 185.104.114.90 — IP-адрес или хост сервера.
После выполнения этой команды публичный ключ будет скопирован на сервер. Теперь вы можете подключаться к удаленной машине с помощью логина и IP-адреса — например, ssh [email protected]. Ключи будут сопоставляться автоматически.
Отключение запроса пароля
Суть приватных ключей в том, что они хранятся на локальных компьютерах. Если вы попытаетесь подключиться к серверу с другой машины, на которой нет ключа, то снова увидите запрос на ввод пароля. Чтобы авторизоваться можно было только по ключу, запретите использование пароля.
- Подключитесь к удаленному серверу.
- Выполните команду sudo nano /etc/ssh/sshd_config. Файл sshd_config откроется во встроенном текстовом редакторе.
- Найдите строку PasswordAuthentication yes и измените ее на PasswordAuthentication no.
- Сохраните изменения и перезапустите службу SSH командой sudo service ssh restart.
Авторизация по паролю отключена. Теперь подключиться к серверу можно только с помощью пары ключей.
Пример файла конфигурации общего SSH
Этот пример дает более подробную информацию о шаблонах хоста и приоритетах опций.
Возьмем следующий пример файла:
-
Когда вы вводите , клиент ssh читает файл и применяет параметры из первого совпадения, то есть . Затем он проверяет следующие строфы одну за другой на соответствие шаблону. Следующим подходящим является (то есть все хосты, кроме ), и он применит параметр подключения из этой строфы. Последнее определение также совпадает, но клиент ssh будет использовать только параметр поскольку параметр уже определен в разделе .
Полный список параметров, используемых при выглядит следующим образом:
-
-
При запуске подходящими шаблонами хоста являются: , , и . В этом случае используются следующие параметры:
-
Если вы запустите , соответствующие шаблоны хостов будут следующими: , и . В этом случае используются следующие параметры:
-
Для всех остальных подключений клиент ssh будет использовать параметры, указанные в разделах и .
Другие важные опции командной строки сервера SSH
-c host_certificate_file
Указывает путь к файлу сертификата для идентификации sshd во время обмена ключами. Файл сертификата должен соответствовать файлу ключа хоста, указанному с помощью параметра -h или директивы конфигурации HostKey.
-h host_key_file
Указывает файл, из которого читается ключ хоста. Эта опция должна быть указана, если sshd не запускается от имени пользователя root (поскольку обычные файлы ключей хоста как правило не читаются никем, кроме root). По умолчанию это /etc/ssh/ssh_host_ecdsa_key, /etc/ssh/ssh_host_ed25519_key и /etc/ssh/ssh_host_rsa_key. Можно иметь несколько файлов ключей хоста для разных алгоритмов ключей хоста.
-E файл_журнала
Добавить журналы отладки в файл_журнала вместо системного журнала.
-e
Записывать журналы отладки в стандартный вывод ошибок вместо системного журнала.
-o опция
Может использоваться для задания параметров в формате, используемом в файле конфигурации (sshd_config). Это полезно для указания параметров, для которых нет отдельного флага командной строки. Самые важные директивы конфигурационного файла рассмотрены выше.
-p порт
Указывает порт, на котором сервер прослушивает соединения (по умолчанию 22). Допускается использование нескольких портов. Порты, указанные в файле конфигурации с параметром «Port», игнорируются, если указан порт командной строки. Порты, указанные с помощью параметра ListenAddress, переопределяют порты командной строки.
-q
Тихий режим. Ничего не отправляется в системный журнал. Без этой опции обычно запуск, аутентификация и завершение каждого соединения регистрируются.
