SSH: различия между версиями

Материал из ALT Linux Wiki
 
(не показаны 24 промежуточные версии 13 участников)
Строка 1: Строка 1:
{{Stub}}
{{Stub}}
{{span|font-size: 180%|Создание и настройка входа через ssh}}
{{span|font-size: 180%|Создание и настройка входа через ssh}}
{{W}}


Рассматривается вопрос создания ключа пользователя и настройки для авторизации на сервере в ssh через ключ.
Рассматривается вопрос создания ключа пользователя и настройки для авторизации на сервере в ssh через ключ.
Строка 8: Строка 10:
ssh (secure shell) — программа для входа на удалённую машину и выполнения на ней команд.
ssh (secure shell) — программа для входа на удалённую машину и выполнения на ней команд.


== Создание ключа ==
== Использование ==
В ssh используется асимметричное шифрование, соответственно используется пара из закрытого и открытого ключа.
 
Для создания ключа на компьютере пользователя нужно выполнить
Для подключения к удалённой системе используется команда {{cmd|ssh}}. В базовом виде команда имеет следующую форму:
<pre>$ ssh-keygen -t dsa</pre>
<syntaxhighlight lang="bash">$ ssh host</syntaxhighlight>
где ''host'' — IP-адрес или имя узла, к которому осуществляется подключение.
 
Эта команда предполагает, что имя пользователя на удалённой системе совпадает с именем текущего пользователя в локальной системе. Если это не так, можно указать имя пользователя на удалённой системе, используя следующий синтаксис:
<syntaxhighlight lang="bash">$ ssh user@host</syntaxhighlight>
 
Для подключения к серверу, потребуется ввести пароль. Ниже рассмотрено, как сгенерировать ключи, которые можно использовать вместо паролей.
 
Чтобы завершить сеанс ssh и вернуться в сеанс локальной оболочки, следует ввести команду:
<syntaxhighlight lang="bash">$ exit</syntaxhighlight>
 
== Аутентификация на основе ключей ==
Применяется для повышения безопасности при доступе к удалённым системам, поскольку при работе с ключами не требуется передавать пароли по недоверенным каналам (или искать варианты доверенных), но достаточно передать -- хоть опубликовать -- открытую часть ключа.
 
{{note|безопасность ключа с пустым паролем может оказаться даже ниже, чем при доступе по паролю, в сценарии получения атакующим доступа к аккаунту/данным/бэкапам ''пользователя'' и содержимому {{path|~/.ssh}}; поэтому рекомендуется (и в ALT поддерживается "из коробки") применение ключей с паролем, его кэшированием средствами ssh-agent и указанием при помощи {{cmd|*-ssh-askpass}} при запуске сессии.}}
 
=== Создание ключей ===
Ключи SSH необходимо генерировать на компьютере, откуда будет происходить подключение. Как правило, это ваш локальный компьютер.
 
В ssh используется асимметричное шифрование, соответственно используется пара из закрытого и открытого ключа. Открытый ключ копируется на сервер и служит для проверки идентичности пользователя.
 
Для создания ключа на компьютере пользователя нужно выполнить команду:
<syntaxhighlight lang="bash">$ ssh-keygen -t ed25519</syntaxhighlight>


На вопрос о файле для сохранения ключа нажать Enter (по умолчанию). Далее будет задан вопрос о пароле к ключу. Пароль нужно указать.
На вопрос о файле для сохранения ключа можно нажать Enter, чтобы принять значения по умолчанию. Далее будет задан вопрос о пароле к ключу. Для защиты файла ключа нужно указать пароль.


В каталоге {{path|~/.ssh}}
В каталоге {{path|~/.ssh}} появятся файлы:
появляются файлы
* id_ed25519 — секретный ключ
* id_dsa — секретный ключ
* id_ed25519.pub — публичный ключ
* id_dsa.pub — публичный ключ
<div style="display: inline; color: red;">Внимание! Никогда никому не пересылайте '''секретный''' ключ.</div>
<div style="display: inline; color: red;">Внимание! Никогда никому не пересылайте '''секретный''' ключ.</div>


== Настройка входа (на сервере) ==
=== Передача открытого ключа на сервер ===
Для того, чтобы пользователь мог авторизоваться в системе через ssh-ключ, нужно в файл {{path|~/.ssh/authorized_keys}} добавить содержимое файла {{path|id_dsa.pub}}. Если пользователь будет один входить под этой учётной записью, файл {{path|id_dsa.pub}} можно просто скопировать, назвав authorized_keys.
Чтобы пользователь мог авторизоваться в системе по ssh-ключу, нужно в файл {{path|~/.ssh/authorized_keys}} добавить содержимое файла {{path|id_ed25519.pub}}. Если пользователь будет один входить под этой учётной записью, файл {{path|id_ed25519.pub}} можно просто скопировать, назвав authorized_keys.
Также можно воспользоваться утилитой {{prg|ssh-copy-id}}, если копировать вручную не хочется: {{cmd|ssh-copy-id user@host}}
 
Для передачи открытого ключа на сервер можно воспользоваться утилитой {{prg|ssh-copy-id}}: {{cmd|ssh-copy-id -i <путь до ключа>id_ed25519.pub user@host}}. Например:
<syntaxhighlight lang="bash">$ ssh-copy-id -i ~/.ssh/id_ed25519.pub user@192.168.0.120</syntaxhighlight>
 
В результате выполнения данной команды в файл авторизованных ключей сервера ({{path|~/.ssh/authorized_keys}}) будет добавлен открытый ключ пользователя.
 
После того как открытый ключ скопирован на сервер, следует убедиться, что при подключении для проверки подлинности используется ключ, а не пароль:
<syntaxhighlight lang="bash">[test@home ~]$ ssh user@192.168.0.120
Enter passphrase for key '/home/test/.ssh/id_ed25519':
Last login: Wed Feb 15 13:18:53 2023 from 192.168.0.102
user@work ~ $ </syntaxhighlight>
 
Чтобы не указывать пароль каждый раз при обращении к серверу, можно запустить команду:
<syntaxhighlight lang="bash">$ ssh-add</syntaxhighlight>
Будет спрошен пароль и расшифрованный ключ запомнится на время вашего сеанса. Это сработает если запущен ssh-agent (в ALT Linux он запускается автоматически при графическом входе в систему).


'''Данные изменения проводятся в каталоге пользователя ''на сервере'''''.
ssh-agent — это менеджер ключей для SSH. Он хранит ключи и сертификаты пользователя в памяти, незашифрованные и готовые к использованию ssh. Это избавляет от необходимости вводить пароль каждый раз, когда происходит подключение к серверу.
<div style="display: inline; color: red;">Обратите внимание на права файлов:</div>
<pre>-rw------- authorized_keys
-rw-r--r-- config</pre>
и на каталог
<pre>drwx------ .ssh</pre>
принадлежать файлы должны пользователю и его группе.


Затем выполнить команду
Пример добавления ключа в ssh-agent и подключение без ввода пароля к ключу:
{{path|$ xfconf-query -c xfce4-session -p /startup/ssh-agent/type -s "ssh-agent" -t string -n}}
потом перелогиниться.


Проверка того, что ключ работает:<br />
<syntaxhighlight lang="bash">[test@home ~]$ ssh-add
1. $ ssh-add<br />
Enter passphrase for key '/home/test/.ssh/id_ed25519':
2. $ ssh другая_машина<br />
Identity added: /home/test/.ssh/id_ed25519 (test@home)
При подключении не должен запрашиваться пароль.
[test@home ~]$ ssh user@192.168.0.120
Last login: Wed Feb 15 13:43:53 2023 from 192.168.0.102
user@work ~ $ </syntaxhighlight>


== Использование ==
{{Note|При запуске команды {{cmd|ssh-add}} без параметров, домашний каталог пользователя будет просканирован на наличие некоторых стандартных ключей и найденные ключи будут добавлены в агент. По умолчанию происходит поиск следующих ключей:
$ ssh user@host.name
*{{path|~/.ssh/id_rsa}}
*{{path|~/.ssh/id_ed25519}}
*{{path|~/.ssh/id_dsa}}
*{{path|~/.ssh/id_ecdsa}} }}
 
{{Note|Пользователям XFCE [https://bugzilla.altlinux.org/27342 может потребоваться] включить явный запуск ssh-agent, чтобы его использовать:
<syntaxhighlight lang="bash">$ xfconf-query -c xfce4-session -p /startup/ssh-agent/type -s "ssh-agent" -t string -n</syntaxhighlight>
 
Изменение вступит в силу после перелогина.
}}
 
== Конфигурационный файл пользователя ==
 
Если необходимо подключаться к множеству различных удалённых систем по SSH, можно для таких систем создать алиасы (псевдонимы) SSH. Это позволит не запоминать различные параметры доступа (имена пользователей, имена хостов, номера портов ssh и IP-адреса и т.д.) и не вводить многократно одни и те же параметры при каждом использовании SSH.


== Конфигурационный файл (у пользователя) ==
Пример файла конфигурации {{path|~/.ssh/config}}:
Для удобства в файле ~/.ssh/config можно указать сокращение
<syntaxhighlight lang="ini">
<pre>Host   myserv
Host myserv
        HostName host.name</pre>
    User user
    Protocol 2
    Port 2213
    ForwardX11 yes
    ForwardAgent yes
    Compression yes


и вызывать просто как
Host edu
$ ssh myserv
    HostName 192.168.0.117
    Port 222
    User user
    IdentityFile ~/.ssh/ravada2
</syntaxhighlight>


Можно добавить ещё настроек:
В этом случае для подключения можно использовать команду:
<pre>Host myserv
<syntaxhighlight lang="bash">$ ssh edu</syntaxhighlight>
...
вместо:
        User user
<syntaxhighlight lang="bash">$ ssh -i ~/.ssh/ravada2 -p 222 user@192.168.0.117</syntaxhighlight>
        Protocol 2
        ForwardX11 yes
        ForwardAgent yes
        Compression yes</pre>


Чтобы не указывать пароль каждый раз при обращении к серверу, можно запустить
В файле {{path|~/.ssh/config}} хранятся настройки для одного пользователя, а в {{path|/etc/ssh/ssh_config}} глобально для всех пользователей системы.
$ ssh-add
Будет спрошен пароль и расшифрованный ключ запомнится на время вашего сеанса. Это сработает если запущен ssh-agent (в ALT Linux он запускается автоматически при графическом входе в систему).


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


=== Инструкция по установке и настройке сервера ssh для администратора ===
=== Установка сервера OpenSSH ===
Нужно установить пакет '''openssh-server''', включить автоматический запуск при загрузке системы:
В ОС Альт сервер и клиент OpenSSH установлены и запущены по умолчанию.  
# chkconfig sshd on</pre>
В файле /etc/openssh/sshd_config укажите строку [[Документация/AllowUsers|AllowUsers]] с перечислением пользователей, имеющих право подключаться к системе.


Например
{{Note|В [[Simply Linux]] сервер OpenSSH по умолчанию не запущен}}.
AllowUsers guest test best


А также рекомендуется выключить аутентификацию по паролю (исправить строчку [[Документация/PasswordAuthentication|PasswordAuthentication]] на):
Для установки сервера OpenSSH необходимо установить пакет {{pkgL|openssh-server}}:
PasswordAuthentication no
<syntaxhighlight lang="bash"># apt-get install openssh-server </syntaxhighlight>


Для вступления настроек в силу:
Запустить сервер OpenSSH и включить автоматический запуск при загрузке системы:
# service sshd reload
<syntaxhighlight lang="bash"># systemctl enable --now sshd</syntaxhighlight>


=== [[OpenLDAP|LDAP]] ===
=== Файл конфигурации сервера ===
Чтобы sshd мог пускать пользователей из LDAP, нужно выполнить
 
control system-auth ldap
{{path|/etc/openssh/sshd_config}} — файл конфигурации сервера OpenSSH. Для применения изменений, внесённых в этот файл, необходимо перезапустить сервер:
<syntaxhighlight lang="bash"># systemctl restart sshd</syntaxhighlight>
 
=== Control ===
 
Для управления настройками sshd можно использовать подсистему [[control]].
 
Например, для исключения возможности подбора паролей локальных пользователей можно выключить аутентификацию по паролю (обратите внимание: создать, разложить и проверить ключи следует ''заранее''):
<syntaxhighlight lang="bash"># control sshd-password-auth disabled</syntaxhighlight>
 
Включить контроль доступа по группам для службы удаленного доступа OpenSSH:
<syntaxhighlight lang="bash"># control sshd-allow-groups enabled</syntaxhighlight>
 
Задать режим аутентификации для суперпользователя (root) на сервере OpenSSH (должен быть установлен пакет {{pkgL|control-sshd-permit-root-login}}):
* without_password — суперпользователю разрешена только беспарольная аутентификация на сервере OpenSSH
* enabled — суперпользователю разрешена аутентификация на сервере OpenSSH
* disabled — суперпользователю запрещена аутентификация на сервере OpenSSH
* default — сбросить режим аутентификации для суперпользователя на значение по умолчанию в пакете
 
<syntaxhighlight lang="bash"># control sshd-permit-root-login without_password</syntaxhighlight>
 
После изменения настроек, необходимо перезапустить сервер:
<syntaxhighlight lang="bash"># systemctl restart sshd</syntaxhighlight>
 
==== [[OpenLDAP|LDAP]] ====
Чтобы sshd мог пускать пользователей из LDAP, нужно выполнить:
<syntaxhighlight lang="bash"># control system-auth ldap</syntaxhighlight>


== Управление сессиями ==
== Управление сессиями ==
Строка 107: Строка 177:
  iptables -A INPUT -p TCP --syn --dport 22 -m recent --name ssh_rate_limit --update --seconds 60 --hitcount 4 -j DROP
  iptables -A INPUT -p TCP --syn --dport 22 -m recent --name ssh_rate_limit --update --seconds 60 --hitcount 4 -j DROP
Для оптимизации этого дела настроятельно рекомендуется завести цель LOGDROP.
Для оптимизации этого дела настроятельно рекомендуется завести цель LOGDROP.
* Настроить {{pkg|fail2ban}}:
В файл /etc/fail2ban/jail.d/customisation.local записать
<pre>
[sshd]
enabled  = true
filter  = sshd
logpath  = /var/log/auth/messages
maxretry = 3
</pre>
В файле /etc/openssh/sshd_config параметру '''UseDNS''' задать значение <tt>no</tt>.
* Либо настроить {{pkg|sshutout}}, см. [http://www.techfinesse.com/sshutout/sshutout.html описание].
=== Смена порта у сервера ===
По умолчанию протокол ssh использует 22 порт, но для предотвращения попыток входа всяких ботов по 22 порту, можно сменить этот порт на любой,  не используемый на сервере
Для этого надо в Файле /etc/openssh/sshd_config задать "нестандартный" порт
<source lang=txt>
...
Port 2213
...
</source>


=== Настройка второго sshd ===
=== Настройка второго sshd ===
Строка 117: Строка 210:
Например:
Например:
  $ ssh-copy-id -i friends_pub_key myserver
  $ ssh-copy-id -i friends_pub_key myserver
=== Cisco IOS и SSH 6.6p1 ===
Ошибка при подключении:
SSH2 0:  Client DH key range mismatch with max built-in DH key on server!
в ~/.ssh/config (что бы не переопределять глобально у остальных пользователей) добавить:
<pre>
Host 192.168.1.*
    KexAlgorithms diffie-hellman-group14-sha1,curve25519-sha256@libssh.org,ecdh-sha2-nistp521,ecdh-sha2-nistp384,ecdh-sha2-nistp256,\
diffie-hellman-group-exchange-sha256,diffie-hellman-group-exchange-sha1,diffie-hellman-group1-sha1
</pre>
т.е.  diffie-hellman-group14-sha1 - на первое место.
== Настройка входа по одноразовому паролю ==
Вход по ключу — это, конечно хорошо (особенно если ключ ещё и защищён паролем), однако при входе из общественного места может не быть возможности использовать ключ (запрещено использовать свои флешки). А если такая возможность есть, то не факт, что ваш ключ не будет скопирован, а его пароль перехвачен во время ввода. В общем ключ — это просто более надёжный пароль: его тоже можно украсть и потом невозбранно использовать для входа под вашей учётной записью.
Для общественных мест хочется иметь такую технологию входа, чтобы потенциальная компрометация ''всех'' учётных данных не дала возможности злоумышленнику войти в систему. И такая технология есть — это [http://ru.wikipedia.org/wiki/%D0%9E%D0%B4%D0%BD%D0%BE%D1%80%D0%B0%D0%B7%D0%BE%D0%B2%D1%8B%D0%B9_%D0%BF%D0%B0%D1%80%D0%BE%D0%BB%D1%8C одноразовые пароли]. Подробнее о том, как это работает можно прочитать в [http://habrahabr.ru/post/154229/ этой статье]. Для вас же их использование будут означать, что при входе в систему, помимо пароля, нужно будет вводить некий числовой код, который будет каждый раз разным.
{{Note|На время настройки, для того, чтобы не заблокировать доступ к серверу, откройте второй сеанс SSH.}}
В качестве инфраструктуры для одноразовых паролей мы возьмём [https://code.google.com/p/google-authenticator/ Google Authenticator], ибо всё необходимое уже есть в репозиториях.
'''Шаг 1.''' Установить пакеты: {{pkg|libpam-google-authenticator}} и {{pkg|libqrencode4}} ({{pkg|libqrencode}} в [[p8]]):
<syntaxhighlight lang="bash"># apt-get install libpam-google-authenticator libqrencode4</syntaxhighlight>
'''Шаг 2.''' Создать необходимые файлы у пользователя, который будет входить с одноразовым паролем. Для этого под учётной записью пользователя выполнить команду:
<syntaxhighlight lang="bash">$ google-authenticator</syntaxhighlight>
Будут заданы следующие вопросы:
* Сделать токены основанными на времени? — y;
* Если установлен пакет {{pkg|libqrencode4}}, будет показан QR-код. В приложении Google Authenticator на телефоне нужно создать новый аккаунт и отсканировать код (если QR-код слишком велик для сканирования, можно использовать URL-ссылку над QR-кодом, чтобы получить уменьшенную версию). Если библиотека не установлена, нужно вручную ввести секретный ключ. В результате будет сгенерирован текущий одноразовый пароль;
* Обновить файл {{path|~/.google_authenticator}}? — y;
* Запретить использование одного кода несколько раз — y;
* Расширить время действия кода с 1,5 минут до 4? — n;
* Запретить попытки входа чаще, чем 3 раза за 30 сек? — y.
Всё, настройка для пользователя закончена.
{{Note|Следует сохранить секретный ключ, код подтверждения и коды восстановления в надежном месте, например в диспетчере паролей. Коды восстановления — это единственный способ восстановить доступ, если, например, потерян доступ к приложению TOTP.}}
'''Шаг 3.''' Настроить OpenSSH для поддержки этого типа аутентификации. Для этого в файле {{path|/etc/openssh/sshd_config}} включить опцию (пароли типа «запрос-ответ»):
<syntaxhighlight lang="ini">ChallengeResponseAuthentication yes</syntaxhighlight>
Перезагрузить файлы конфигурации OpenSSH:
<syntaxhighlight lang="bash"># service sshd reload</syntaxhighlight>
'''Шаг 4.'''  Настроить PAM для комбинирования пользовательских паролей и PIN-кодов, генерируемых Google Authenticator. Для этого необходимо внести правки в соответствующие настройки PAM ({{path|/etc/pam.d/sshd}}). Обычно рекомендуют просто добавить гугловый пам в начало файла. В нашем случае это не заработает. Проблема в том, что модуль pam_userpass не хочет нормально работать в паре с гуглом. Если просто добавить гугл в {{path|/etc/pam.d/sshd}}, то независимо от порядка следования модулей, будет выводиться только запрос на одноразовый пароль и всегда будет access denied.
Однако, не смотря на название, userpass не проверяет логин/пароль, он просто запрашивает их и сохраняет внутри стека pam. А проверяет их pam_tcb (см. {{cmd|man pam_tcb}}), причём он и сам умеет запрашивать пароль!
Решение очень простое — удалить userpass, вставить на его место tcb без параметра use_first_pass. После этих манипуляций файл {{path|/etc/pam.d/sshd}} должен выглядеть так:
<syntaxhighlight lang="ini">#auth      required    pam_userpass.so
auth        required    pam_tcb.so shadow fork prefix=$2y$ count=8 nullok
auth        required    pam_google_authenticator.so echo_verification_code nullok
#auth      include    common-login-use_first_pass
account    include    common-login
password    include    common-login
session    include    common-login
</syntaxhighlight>
{{Note|Параметр ''echo_verification_code'' включает отображение цифр одноразового кода при их вводе. Параметр ''nullok'' разрешает вход без одноразового кода для тех пользователей, у которых не настроен Google Authenticator.}}
Порядок следования модулей auth важен, при таком как в примере, сначала запрашивается пароль, затем одноразовый код:
<syntaxhighlight lang="bash">$ ssh user@192.168.0.122
(user@192.168.0.122) Password:
(user@192.168.0.122) Verification code: 956946
Last login: Tue Feb 14 21:40:25 2023 from 192.168.0.102</syntaxhighlight>
Так невозможно понять, что именно неверно, и это хорошо для безопасности. Если необходимо, чтобы авторизация завершалась сразу, замените required на requisite у pam_tcb.
{{Note| Чтобы включить авторизацию по ключу SSH в качестве одного фактора и одноразовый код в качестве второго, нужно указать SSH, какие факторы использовать. Для этого в файл {{path|/etc/openssh/sshd_config}} нужно добавить строку:
<syntaxhighlight lang="ini">AuthenticationMethods publickey,password publickey,keyboard-interactive</syntaxhighlight>
Эта строка сообщает SSH, что для аутентификации нужно использовать ключ SSH и либо пароль, либо код подтверждения (или все три).
Перезагрузить файлы конфигурации OpenSSH:
<syntaxhighlight lang="bash"># service sshd reload</syntaxhighlight>
Чтобы не запрашивался пароль пользователя, следует в файле {{path|/etc/pam.d/sshd}} закомментировать строку с pam_tcb.
Пример подключения с использованием ключа и одноразового пароля:
<syntaxhighlight lang="bash">$ ssh -i .ssh/mykey 'test@192.168.0.122'
Enter passphrase for key '.ssh/mykey':
(test@192.168.0.122) Verification code: 984977
Last login: Wed Feb 15 12:21:35 2023 from 192.168.0.102</syntaxhighlight>
}}


== Ссылки ==
== Ссылки ==
Строка 132: Строка 310:


[[Категория:Admin]]
[[Категория:Admin]]
{{Category navigation|title=Системному администратору|category=Admin|sortkey={{SUBPAGENAME}}}}
{{Category navigation|title=Удалённый доступ|category=Удалённый доступ|sortkey={{SUBPAGENAME}}}}

Текущая версия от 16:04, 29 июля 2024

Stub.png
Данная страница находится в разработке.
Эта страница ещё не закончена. Информация, представленная здесь, может оказаться неполной или неверной.

Создание и настройка входа через ssh


Логотип Википедии
В Википедии есть обзорная статья по теме «SSH».

Рассматривается вопрос создания ключа пользователя и настройки для авторизации на сервере в ssh через ключ. Предполагается что ssh-сервер запущен и имеет настройки, принятые по умолчанию в ALT Linux.

Введение

ssh (secure shell) — программа для входа на удалённую машину и выполнения на ней команд.

Использование

Для подключения к удалённой системе используется команда ssh. В базовом виде команда имеет следующую форму: 

$ ssh host

где host — IP-адрес или имя узла, к которому осуществляется подключение.

Эта команда предполагает, что имя пользователя на удалённой системе совпадает с именем текущего пользователя в локальной системе. Если это не так, можно указать имя пользователя на удалённой системе, используя следующий синтаксис: 

$ ssh user@host

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

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

$ exit

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

Применяется для повышения безопасности при доступе к удалённым системам, поскольку при работе с ключами не требуется передавать пароли по недоверенным каналам (или искать варианты доверенных), но достаточно передать -- хоть опубликовать -- открытую часть ключа.

Примечание: безопасность ключа с пустым паролем может оказаться даже ниже, чем при доступе по паролю, в сценарии получения атакующим доступа к аккаунту/данным/бэкапам пользователя и содержимому ~/.ssh; поэтому рекомендуется (и в ALT поддерживается "из коробки") применение ключей с паролем, его кэшированием средствами ssh-agent и указанием при помощи *-ssh-askpass при запуске сессии.


Создание ключей

Ключи SSH необходимо генерировать на компьютере, откуда будет происходить подключение. Как правило, это ваш локальный компьютер.

В ssh используется асимметричное шифрование, соответственно используется пара из закрытого и открытого ключа. Открытый ключ копируется на сервер и служит для проверки идентичности пользователя.

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

$ ssh-keygen -t ed25519

На вопрос о файле для сохранения ключа можно нажать Enter, чтобы принять значения по умолчанию. Далее будет задан вопрос о пароле к ключу. Для защиты файла ключа нужно указать пароль.

В каталоге ~/.ssh появятся файлы:

  • id_ed25519 — секретный ключ
  • id_ed25519.pub — публичный ключ
Внимание! Никогда никому не пересылайте секретный ключ.

Передача открытого ключа на сервер

Чтобы пользователь мог авторизоваться в системе по ssh-ключу, нужно в файл ~/.ssh/authorized_keys добавить содержимое файла id_ed25519.pub. Если пользователь будет один входить под этой учётной записью, файл id_ed25519.pub можно просто скопировать, назвав authorized_keys.

Для передачи открытого ключа на сервер можно воспользоваться утилитой ssh-copy-id: ssh-copy-id -i <путь до ключа>id_ed25519.pub user@host. Например: 

$ ssh-copy-id -i ~/.ssh/id_ed25519.pub user@192.168.0.120

В результате выполнения данной команды в файл авторизованных ключей сервера (~/.ssh/authorized_keys) будет добавлен открытый ключ пользователя.

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

[test@home ~]$ ssh user@192.168.0.120
Enter passphrase for key '/home/test/.ssh/id_ed25519': 
Last login: Wed Feb 15 13:18:53 2023 from 192.168.0.102
user@work ~ $

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

$ ssh-add

Будет спрошен пароль и расшифрованный ключ запомнится на время вашего сеанса. Это сработает если запущен ssh-agent (в ALT Linux он запускается автоматически при графическом входе в систему).

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

Пример добавления ключа в ssh-agent и подключение без ввода пароля к ключу: 

[test@home ~]$ ssh-add
Enter passphrase for key '/home/test/.ssh/id_ed25519': 
Identity added: /home/test/.ssh/id_ed25519 (test@home) 
[test@home ~]$ ssh user@192.168.0.120
Last login: Wed Feb 15 13:43:53 2023 from 192.168.0.102
user@work ~ $
Примечание: При запуске команды ssh-add без параметров, домашний каталог пользователя будет просканирован на наличие некоторых стандартных ключей и найденные ключи будут добавлены в агент. По умолчанию происходит поиск следующих ключей:
  • ~/.ssh/id_rsa
  • ~/.ssh/id_ed25519
  • ~/.ssh/id_dsa
  • ~/.ssh/id_ecdsa


Примечание: Пользователям XFCE может потребоваться включить явный запуск ssh-agent, чтобы его использовать: 
$ xfconf-query -c xfce4-session -p /startup/ssh-agent/type -s "ssh-agent" -t string -n

Изменение вступит в силу после перелогина.


Конфигурационный файл пользователя

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

Пример файла конфигурации ~/.ssh/config: 

Host myserv
     User user
     Protocol 2
     Port 2213
     ForwardX11 yes
     ForwardAgent yes
     Compression yes

Host edu
     HostName 192.168.0.117
     Port 222
     User user
     IdentityFile ~/.ssh/ravada2

В этом случае для подключения можно использовать команду: 

$ ssh edu

вместо: 

$ ssh -i ~/.ssh/ravada2 -p 222 user@192.168.0.117

В файле ~/.ssh/config хранятся настройки для одного пользователя, а в /etc/ssh/ssh_config глобально для всех пользователей системы.

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

Установка сервера OpenSSH

В ОС Альт сервер и клиент OpenSSH установлены и запущены по умолчанию.

Примечание: В Simply Linux сервер OpenSSH по умолчанию не запущен

.

Для установки сервера OpenSSH необходимо установить пакет openssh-server: 

# apt-get install openssh-server

Запустить сервер OpenSSH и включить автоматический запуск при загрузке системы: 

# systemctl enable --now sshd

Файл конфигурации сервера

/etc/openssh/sshd_config — файл конфигурации сервера OpenSSH. Для применения изменений, внесённых в этот файл, необходимо перезапустить сервер: 

# systemctl restart sshd

Control

Для управления настройками sshd можно использовать подсистему control.

Например, для исключения возможности подбора паролей локальных пользователей можно выключить аутентификацию по паролю (обратите внимание: создать, разложить и проверить ключи следует заранее): 

# control sshd-password-auth disabled

Включить контроль доступа по группам для службы удаленного доступа OpenSSH: 

# control sshd-allow-groups enabled

Задать режим аутентификации для суперпользователя (root) на сервере OpenSSH (должен быть установлен пакет control-sshd-permit-root-login):

  • without_password — суперпользователю разрешена только беспарольная аутентификация на сервере OpenSSH
  • enabled — суперпользователю разрешена аутентификация на сервере OpenSSH
  • disabled — суперпользователю запрещена аутентификация на сервере OpenSSH
  • default — сбросить режим аутентификации для суперпользователя на значение по умолчанию в пакете
# control sshd-permit-root-login without_password

После изменения настроек, необходимо перезапустить сервер: 

# systemctl restart sshd

LDAP

Чтобы sshd мог пускать пользователей из LDAP, нужно выполнить: 

# control system-auth ldap

Управление сессиями

PAM session management в openssh той версии, которая находится в Сизифе и дистрибутивах, использует privilege separation и потому исполняется с правами пользователя, а не root. Как следствие,

  • pam_mktemp не сможет создать подкаталог в /tmp/.private/ с нужными правами, если его там нет;
  • pam_mkhomedir не сможет создать подкаталог с нужными правами, если его там нет;
  • pam_limits не сможет увеличить лимиты сверх тех, что есть у процесса openssh.

В качестве объезда можно помещать эти модули в PAM account management.

Полезные советы

Предотвращение брутфорс-атак

  • Можно пересадить sshd на нестандартный порт
  • Целесообразно ограничить число «ожидающих» соединений, когда пароль еще не введен. Для этого, в файле /etc/openssh/sshd_config укажите строку
MaxStartups 2:70:10

В этом случае у вас будут разрешены только 2 «ожидающих» соединения, и каждое следующее будет сброшено с вероятностью 70 %

  • Для особо изощрённой защиты можно использовать knock.
  • Можно ограничить число попыток средствами iptables:
iptables -A INPUT -p TCP --syn --dport 22 -m recent --name ssh_rate_limit --set
iptables -A INPUT -p TCP --syn --dport 22 -m recent --name ssh_rate_limit --update --seconds 60 --hitcount 4 -j LOG
iptables -A INPUT -p TCP --syn --dport 22 -m recent --name ssh_rate_limit --update --seconds 60 --hitcount 4 -j DROP

Для оптимизации этого дела настроятельно рекомендуется завести цель LOGDROP.

  • Настроить fail2ban:

В файл /etc/fail2ban/jail.d/customisation.local записать 

[sshd]
enabled  = true
filter   = sshd
logpath  = /var/log/auth/messages
maxretry = 3

В файле /etc/openssh/sshd_config параметру UseDNS задать значение no.

Смена порта у сервера

По умолчанию протокол ssh использует 22 порт, но для предотвращения попыток входа всяких ботов по 22 порту, можно сменить этот порт на любой, не используемый на сервере

Для этого надо в Файле /etc/openssh/sshd_config задать "нестандартный" порт 

...
Port 2213
...

Настройка второго sshd

Копируем /etc/init.d/sshd и указываем через -f другой конфигурационный файл? Практика показывает, что надо менять весь набор: копировать /etc/init.d/sshd, /etc/sysconfig/sshd; (факультативно делать ссылки или копировать сам sshd, /etc/pam.d/sshd); изменять посредством /etc/sysconfig/sshd переменные PIDFILE, LOCKFILE, EXTRAOPTIONS.

Копирование ключа на сервер

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

$ ssh-copy-id

Например: 

$ ssh-copy-id -i friends_pub_key myserver

Cisco IOS и SSH 6.6p1

Ошибка при подключении: SSH2 0: Client DH key range mismatch with max built-in DH key on server!

в ~/.ssh/config (что бы не переопределять глобально у остальных пользователей) добавить: 

Host 192.168.1.*
    KexAlgorithms diffie-hellman-group14-sha1,curve25519-sha256@libssh.org,ecdh-sha2-nistp521,ecdh-sha2-nistp384,ecdh-sha2-nistp256,\
diffie-hellman-group-exchange-sha256,diffie-hellman-group-exchange-sha1,diffie-hellman-group1-sha1

т.е. diffie-hellman-group14-sha1 - на первое место.

Настройка входа по одноразовому паролю

Вход по ключу — это, конечно хорошо (особенно если ключ ещё и защищён паролем), однако при входе из общественного места может не быть возможности использовать ключ (запрещено использовать свои флешки). А если такая возможность есть, то не факт, что ваш ключ не будет скопирован, а его пароль перехвачен во время ввода. В общем ключ — это просто более надёжный пароль: его тоже можно украсть и потом невозбранно использовать для входа под вашей учётной записью.

Для общественных мест хочется иметь такую технологию входа, чтобы потенциальная компрометация всех учётных данных не дала возможности злоумышленнику войти в систему. И такая технология есть — это одноразовые пароли. Подробнее о том, как это работает можно прочитать в этой статье. Для вас же их использование будут означать, что при входе в систему, помимо пароля, нужно будет вводить некий числовой код, который будет каждый раз разным.

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


В качестве инфраструктуры для одноразовых паролей мы возьмём Google Authenticator, ибо всё необходимое уже есть в репозиториях.

Шаг 1. Установить пакеты: libpam-google-authenticator и libqrencode4 (libqrencode в p8): 

# apt-get install libpam-google-authenticator libqrencode4

Шаг 2. Создать необходимые файлы у пользователя, который будет входить с одноразовым паролем. Для этого под учётной записью пользователя выполнить команду: 

$ google-authenticator

Будут заданы следующие вопросы:

  • Сделать токены основанными на времени? — y;
  • Если установлен пакет libqrencode4, будет показан QR-код. В приложении Google Authenticator на телефоне нужно создать новый аккаунт и отсканировать код (если QR-код слишком велик для сканирования, можно использовать URL-ссылку над QR-кодом, чтобы получить уменьшенную версию). Если библиотека не установлена, нужно вручную ввести секретный ключ. В результате будет сгенерирован текущий одноразовый пароль;
  • Обновить файл ~/.google_authenticator? — y;
  • Запретить использование одного кода несколько раз — y;
  • Расширить время действия кода с 1,5 минут до 4? — n;
  • Запретить попытки входа чаще, чем 3 раза за 30 сек? — y.

Всё, настройка для пользователя закончена.

Примечание: Следует сохранить секретный ключ, код подтверждения и коды восстановления в надежном месте, например в диспетчере паролей. Коды восстановления — это единственный способ восстановить доступ, если, например, потерян доступ к приложению TOTP.


Шаг 3. Настроить OpenSSH для поддержки этого типа аутентификации. Для этого в файле /etc/openssh/sshd_config включить опцию (пароли типа «запрос-ответ»): 

ChallengeResponseAuthentication yes

Перезагрузить файлы конфигурации OpenSSH: 

# service sshd reload

Шаг 4. Настроить PAM для комбинирования пользовательских паролей и PIN-кодов, генерируемых Google Authenticator. Для этого необходимо внести правки в соответствующие настройки PAM (/etc/pam.d/sshd). Обычно рекомендуют просто добавить гугловый пам в начало файла. В нашем случае это не заработает. Проблема в том, что модуль pam_userpass не хочет нормально работать в паре с гуглом. Если просто добавить гугл в /etc/pam.d/sshd, то независимо от порядка следования модулей, будет выводиться только запрос на одноразовый пароль и всегда будет access denied.

Однако, не смотря на название, userpass не проверяет логин/пароль, он просто запрашивает их и сохраняет внутри стека pam. А проверяет их pam_tcb (см. man pam_tcb), причём он и сам умеет запрашивать пароль!

Решение очень простое — удалить userpass, вставить на его место tcb без параметра use_first_pass. После этих манипуляций файл /etc/pam.d/sshd должен выглядеть так: 

#auth       required    pam_userpass.so
auth        required    pam_tcb.so shadow fork prefix=$2y$ count=8 nullok
auth        required    pam_google_authenticator.so echo_verification_code nullok
#auth       include     common-login-use_first_pass
account     include     common-login
password    include     common-login
session     include     common-login
Примечание: Параметр echo_verification_code включает отображение цифр одноразового кода при их вводе. Параметр nullok разрешает вход без одноразового кода для тех пользователей, у которых не настроен Google Authenticator.


Порядок следования модулей auth важен, при таком как в примере, сначала запрашивается пароль, затем одноразовый код: 

$ ssh user@192.168.0.122
(user@192.168.0.122) Password: 
(user@192.168.0.122) Verification code: 956946
Last login: Tue Feb 14 21:40:25 2023 from 192.168.0.102

Так невозможно понять, что именно неверно, и это хорошо для безопасности. Если необходимо, чтобы авторизация завершалась сразу, замените required на requisite у pam_tcb.

Примечание: Чтобы включить авторизацию по ключу SSH в качестве одного фактора и одноразовый код в качестве второго, нужно указать SSH, какие факторы использовать. Для этого в файл /etc/openssh/sshd_config нужно добавить строку: 
AuthenticationMethods publickey,password publickey,keyboard-interactive

Эта строка сообщает SSH, что для аутентификации нужно использовать ключ SSH и либо пароль, либо код подтверждения (или все три).

Перезагрузить файлы конфигурации OpenSSH: 

# service sshd reload

Чтобы не запрашивался пароль пользователя, следует в файле /etc/pam.d/sshd закомментировать строку с pam_tcb.

Пример подключения с использованием ключа и одноразового пароля: 

$ ssh -i .ssh/mykey 'test@192.168.0.122'
Enter passphrase for key '.ssh/mykey': 
(test@192.168.0.122) Verification code: 984977
Last login: Wed Feb 15 12:21:35 2023 from 192.168.0.102


Ссылки

Системному администратору
AltHa • Apache2 • Api.php • APT в ALT Linux • Azure • BackUp/DayOfDayBackUp • Biarch • BIND • BIND SEC • Bootflash (VirtualBoot) • Capabilities • Changes/rpm • Compact3 (HostingInstallHowto) • Control • Control++ • Control++:Blacklist/Whitelist • CVE-Manager • DDNS • DhcpBind • EC2 • Egroupware • EjabberdJit • Enterprise Software • Etckeeper • Etcnet • Evmctl • Evms inside initrd • Features • Features/ChrootedServices • Firewall • Flussonic • Ganeti • Hadoop • Hbase • High Availability • IKVM • Infiniband • InstallOnFlash • IPMI • Ipmitool • Iptables • IPTV • Участник:IvanZakharyaschev/Что делать, если забыл имена пользователей • Участник:IvanZakharyaschev/Что делать, если забыл пароли (в т.ч. пароль root-а) • Участник:IvanZakharyaschev/Что делать, если затёр загрузчик системы • IvmanAutomount • Jupyter Notebook • LargeFiles • LDAP • Lotus • LXC • Mailman • Mailman and lighttpd • Utf8/MigrateToKoi8 • Migration • Moodle • Motion • MSSQL • Multipath • MultiSeat systemd • Multistation • MySQL • Nagios-plugins-smartmon • Netconsole • NetInstall • Netplan • NextCloud в контейнере • OpenLDAP • OpenNMS • OpenVZ • OpenVZ7 • Oracle10g • OracleALS40 • Starterkits/p7 • Starterkits/p8 • Polkit • Pppoptions • Pptpd • Puppet/Запуск puppetry (пример с libvirt) • PVE • RAID • Replace disk online • RoCE • Roundcube • S5000PAL • Samba • SCOM • Security • SelinuxOff • SerialLogin • SerialPortOverIP • Server Security • SharedTmpfsMaintainance • Sisyphus changes • Sisyphus-mirror • SMART-оповещения через Telegram • SPICE • SQLite • SSD • SSH • Starterkits • SwitchToSisyphus • Sysadmin • Systemd • SystemImager • Sysvinit • Tcb • TeXLivePackaging • UFW • Vargus • VideoMost • Web-cyradm • Wi-fi • WireGuard • Xen • Xymon • Zabbix • Zarafa • Zimbra • ZRAM/ZSWAP • Аутентификация по ключу • Безграничный DNS • Бот Telegram • Восстановление • Выявление сессий по ключу SSH • Двухфакторная аутентификация • Домен на openldap (устаревшее) • Доступ по SSH за NAT через TOR • Загрузочная USB Flash • Загрузочные флешки • Загрузчики • Задачи администратора • Задний ход в DarkWeb • Запрет командной строки • Контейнеры systemd-nspawn • Настройка FTP • Настройка rsync-сервера • НастройкаСервераПриложений • Обновление • Обновление ОС • Оборудование • Ограничение использования консолей • Ограничения интерфейса KDE • Отключение интерактивного входа • Переменные bash • ПроблемыДоступностиРазделов • Программы • Прозрачный прокси-сервер • РазбиениеДиска • Ресолвер • Синхронизация времени • Скачивание расширений Chromium • Таймеры systemd вместо crond • ТестированиеКомпьютера • Управление вентилятором Radeon RX-6xx0 • Управление пакетами • Установка UniFi Controller в контейнер LXC • УчётТрафика • Файловые системы • Шаблоны для развёртывания CT в PVE • Категория:Active Directory • Категория:Alterator • Категория:APT • Категория:Backup • Категория:DhcpBind • Категория:Etcnet • Категория:Features • Категория:FileSystems • Категория:FreeIPA • Категория:High Availability • Категория:Kernel • Категория:LDAP • Категория:Make-initrd • Категория:Monitoring • Категория:MySQL • Категория:Oracle • Категория:Power Management • Категория:Samba • Категория:Systemd • Категория:VPN • Категория:Xen • Категория:ZABBIX • Категория:Автомонтирование • Категория:Виртуализация • Категория:Загрузчики • Категория:Использование оборудования • Категория:Синхронизация времени • Категория:Шрифты
 
Удалённый доступ
AnyDesk • Connector • Guacamole • Rdesktop • Remmina • SPICE • SSH • TeamViewer • VNC • X2Go • Xpra • Xrdp