Продвинутое использование SSH

Rowan Puttergill Last review: 2026-06-12

В этой теме рассматриваются распространённые варианты использования SSH, которые сочетают конфигурацию на стороне сервера с командами на стороне клиента: аутентификация на основе сертификатов, перенаправление X11 и перенаправление портов. Основное внимание уделяется примерам конфигурации и командам для типичных сценариев — полные справочники по директивам и параметрам см. в Настройка сервера OpenSSH и Настройка клиента OpenSSH. Для получения общей информации о протоколе SSH см. О SSH и OpenSSH.

Статус: работа в процессе. Содержимое этого раздела находится на рассмотрении и обновляется. Отзывы приветствуются!

Вариант использования: аутентификация по SSH-сертификату

Введение в SSH-сертификаты

Использование криптографии с открытым ключом для аутентификации требует копирования открытого ключа с каждого клиента на каждый сервер, на который клиент намерен войти. Эта система плохо масштабируется и может стать административной нагрузкой. Использование открытого ключа от центра сертификации (CA) для аутентификации клиентских сертификатов устраняет необходимость копирования ключей между несколькими системами. Хотя система сертификатов инфраструктуры открытых ключей X.509 предоставляет решение этой проблемы, для подписания сертификата необходимо пройти процесс подачи и проверки с соответствующими сборами. В качестве альтернативы OpenSSH поддерживает создание простых сертификатов и связанной инфраструктуры CA.

Сертификаты OpenSSH содержат открытый ключ, информацию об идентичности и ограничения срока действия. Они подписываются стандартным открытым ключом SSH с помощью утилиты ssh-keygen. Формат сертификата описан в /usr/share/doc/openssh-version/PROTOCOL.certkeys.

Утилита ssh-keygen поддерживает два типа сертификатов: пользовательские и хостовые. Пользовательские сертификаты аутентифицируют пользователей на серверах, тогда как хостовые сертификаты аутентифицируют серверные хосты для пользователей. Чтобы сертификаты можно было использовать для аутентификации пользователя или хоста, sshd должен быть настроен на доверие открытому ключу CA.

Создание ключей подписи сертификатов SSH CA

Требуются два типа сертификатов: хостовые сертификаты и пользовательские сертификаты. Считается лучшим иметь два отдельных ключа для подписи двух сертификатов, например ca_user_key и ca_host_key, однако можно использовать всего один ключ CA для подписи обоих сертификатов. Также проще следовать процедурам, если используются отдельные ключи, поэтому в следующих примерах будут использоваться отдельные ключи.

Базовый формат команды для подписи открытого ключа пользователя с целью создания пользовательского сертификата следующий:

$ ssh-keygen -s ca_user_key -I certificate_ID id_rsa.pub

Где -s указывает закрытый ключ, используемый для подписи сертификата, -I указывает строку идентичности, certificate_ID, которая может быть любым буквенно-цифровым значением. Она хранится в сертификате как строка, завершающаяся нулём. certificate_ID записывается в журнал всякий раз, когда сертификат используется для идентификации, а также используется при отзыве сертификата. Длинное значение затруднило бы чтение журналов, поэтому использование имени хоста для хостовых сертификатов и имени пользователя для пользовательских сертификатов — безопасный выбор.

Чтобы подписать открытый ключ хоста и создать хостовый сертификат, добавьте параметр -h:

$ ssh-keygen -s ca_host_key -I certificate_ID -h ssh_host_rsa_key.pub

Ключи хоста по умолчанию создаются в системе; чтобы вывести их список, введите следующую команду:

$ ls -l /etc/ssh/ssh_host*
-rw-------. 1 root root  480 May 13 16:11 /etc/ssh/ssh_host_ecdsa_key
-rw-r--r--. 1 root root  162 May 13 16:11 /etc/ssh/ssh_host_ecdsa_key.pub
-rw-------. 1 root root  387 May 13 16:11 /etc/ssh/ssh_host_ed25519_key
-rw-r--r--. 1 root root   82 May 13 16:11 /etc/ssh/ssh_host_ed25519_key.pub
-rw-------. 1 root root 2578 May 13 16:11 /etc/ssh/ssh_host_rsa_key
-rw-r--r--. 1 root root  554 May 13 16:11 /etc/ssh/ssh_host_rsa_key.pub

Рекомендуется создавать и хранить ключи CA в безопасном месте, как и любой другой закрытый ключ. В этих примерах будет использоваться пользователь root. В реальной продуктивной среде рекомендуется использовать офлайн-компьютер с учётной записью администратора. Рекомендации по длине ключей см. в NIST Special Publication 800-131A Revision 1.

Создание ключей подписи сертификатов SSH CA

На сервере, назначенном в качестве CA, создайте два ключа для использования при подписывании сертификатов. Это ключи, которым должны доверять все остальные хосты. Выберите подходящие имена, например ca_user_key и ca_host_key. Чтобы создать ключ подписи пользовательских сертификатов, введите следующую команду:

sudo ssh-keygen -t rsa -f /root/.ssh/ca_user_key
Generating public/private rsa key pair.
Created directory '/root/.ssh'.
Enter passphrase (empty for no passphrase):
Enter same passphrase again:
Your identification has been saved in /root/.ssh/ca_user_key
Your public key has been saved in /root/.ssh/ca_user_key.pub
The key fingerprint is:
SHA256:y6f0DGlHe28YWotEypnhfk3WLYQ5TgaQwoSlOFwmmm0 root@host_name.example.com
The key's randomart image is:
---[RSA 3072]----
|       ..      o|
|       . o     +.|
|      o + .   . o|
|       o + . . ..|
|        S . ... *|
|        . . . .*.|
|         = E  .. |
|        . o .    |
|           .     |
+----[SHA256]-----

Создайте ключ подписи хостовых сертификатов, ca_host_key, следующим образом:

sudo ssh-keygen -t rsa -f /root/.ssh/ca_host_key
Generating public/private rsa key pair.
Enter passphrase (empty for no passphrase):
Enter same passphrase again:
Your identification has been saved in /root/.ssh/ca_host_key
Your public key has been saved in /root/.ssh/ca_host_key.pub
The key fingerprint is:
SHA256:y6f0DGlHe28YWotEypnhfk3WLYQ5TgaQwoSlOFwmmm0 root@host_name.example.com
The key's randomart image is:
---[RSA 3072]----
|            ..   |
|           . ....|
|        . . o oo|
|       o .   o *o|
|        S     = .|
|             o. .|
|            *.E. |
|           +o=   |
|          .oo.   |
+----[SHA256]-----

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

sudo ls -la /root/.ssh
total 40
drwxrwxrwx. 2 root root 4096 May 22 13:18 .
dr-xr-x---. 3 root root 4096 May  8 08:34 ..
-rw-------. 1 root root 1743 May 22 13:15 ca_host_key
-rw-r--r--. 1 root root  420 May 22 13:15 ca_host_key.pub
-rw-------. 1 root root 1743 May 22 13:14 ca_user_key
-rw-r--r--. 1 root root  420 May 22 13:14 ca_user_key.pub
-rw-r--r--. 1 root root  854 May  8 05:55 known_hosts
-r--------. 1 root root 1671 May  6 17:13 ssh_host_rsa
-rw-r--r--. 1 root root 1370 May  7 14:30 ssh_host_rsa-cert.pub
-rw-------. 1 root root  420 May  6 17:13 ssh_host_rsa.pub

Создайте собственный хостовый сертификат сервера CA, подписав открытый ключ хоста сервера вместе со строкой идентичности, такой как имя хоста — полностью определённое доменное имя (FQDN) сервера CA, но без конечной ., — и периодом действия. Команда имеет следующий вид:
```
# ssh-keygen -s ~/.ssh/ca_host_key -I certificate_ID -h -n host_name.example.com -V -start:+end /etc/ssh/ssh_host_rsa.pub
```
Параметр -n ограничивает этот сертификат конкретным хостом в домене. Параметр -V предназначен для добавления периода действия; это настоятельно рекомендуется. Если период действия предполагается равным одному году — пятидесяти двум неделям, — учитывайте необходимость времени на смену сертификатов и любые праздничные периоды вокруг времени истечения срока действия сертификата.

Например:
```
$ sudo ssh-keygen -s /root/.ssh/ca_host_key -I host_name -h -n host_name.example.com -V -1w:+54w5d /etc/ssh/ssh_host_rsa.pub
Enter passphrase:
Signed host key /root/.ssh/ssh_host_rsa-cert.pub: id "host_name" serial 0 for host_name.example.com valid from 2020-05-15T13:52:29 to 2021-06-08T13:52:29
```

Распространение открытых ключей SSH CA и доверие к ним

Хосты, которые должны разрешать вход пользователей с аутентификацией по сертификату, должны быть настроены на доверие открытому ключу CA, которым были подписаны пользовательские сертификаты, чтобы аутентифицировать сертификаты пользователей. В этом примере это ca_user_key.pub.

Опубликуйте ключ ca_user_key.pub и загрузите его на все хосты, которым требуется разрешать вход удалённым пользователям. В качестве альтернативы скопируйте открытый ключ пользователя CA на все хосты. В продуктивной среде рассмотрите возможность сначала скопировать открытый ключ в учётную запись администратора. Для копирования открытого ключа на удалённые хосты можно использовать команду безопасного копирования. Команда имеет следующий формат:

# scp  ~/.ssh/ca_user_key.pub root@host_name.example.com:/etc/ssh/

Где host_name — имя хоста сервера, которому требуется аутентифицировать сертификаты пользователей, предъявляемые в процессе входа. Убедитесь, что вы копируете открытый ключ, а не закрытый. Например:

$ sudo scp /root/.ssh/ca_user_key.pub root@host_name.example.com:/etc/ssh/
The authenticity of host 'host_name.example.com (192.0.2.1)' can't be established.
ED25519 key fingerprint is SHA256:ZYEUaevOAEASvYjm58PiPdMebxhhlaTZBjTMr/N2I3c.
This key is not known by any other names.
Are you sure you want to continue connecting (yes/no/[fingerprint])? yes
Warning: Permanently added 'host_name.example.com' (ED25519) to the list of known hosts.
root@host_name.example.com's password:
ca_user_key.pub                                       100%  420     0.4KB/s   00:00

Для аутентификации удалённого пользователя ключи CA можно пометить как доверенные для отдельного пользователя в файле ~/.ssh/authorized_keys с помощью директивы cert-authority или для глобального использования посредством директивы TrustedUserCAKeys в файле /etc/ssh/sshd_config. Для аутентификации удалённого хоста ключи CA можно пометить как доверенные глобально в файле /etc/ssh/known_hosts или для отдельного пользователя в файле ~/.ssh/ssh_known_hosts.

Доверие ключу подписи пользователя

Для пользовательских сертификатов, в которых перечислены один или несколько принципалов, и когда настройка должна иметь глобальный эффект, отредактируйте файл /etc/ssh/sshd_config следующим образом:
```
TrustedUserCAKeys /etc/ssh/ca_user_key.pub
```
Перезапустите sshd, чтобы изменения вступили в силу:
```
$ sudo systemctl restart sshd.service
```

Чтобы не получать предупреждение о неизвестном хосте, система пользователя должна доверять открытому ключу CA, которым были подписаны хостовые сертификаты. В этом примере это ca_host_key.pub.

Доверие ключу подписи хоста

Извлеките содержимое открытого ключа, использованного для подписи хостового сертификата. Например, на CA:
```
sudo cat /root/.ssh/ca_host_key.pub
sudo ssh-rsa  AAAAB5Wm.== root@ca-server.example.com
```
Чтобы настроить клиентские системы на доверие подписанным хостовым сертификатам серверов, добавьте содержимое ca_host_key.pub в глобальный файл known_hosts. Это будет автоматически проверять объявленный сертификат хоста сервера по открытому ключу CA для всех пользователей при каждом подключении к новой машине в домене *.example.com. Настройте файл /etc/ssh/ssh_known_hosts следующим образом:
```
$ sudo vi /etc/ssh/ssh_known_hosts
# Ключ CA, принимаемый для любого хоста в *.example.com
@cert-authority *.example.com ssh-rsa AAAAB5Wm.
```
Где ssh-rsa AAAAB5Wm. — содержимое ca_host_key.pub. Приведённая выше конфигурация настраивает систему на доверие открытому ключу хоста серверов CA. Это обеспечивает глобальную аутентификацию сертификатов, предъявляемых хостами удалённым пользователям.

Создание сертификатов SSH

Сертификат — это подписанный открытый ключ. Открытые ключи пользователя и хоста должны быть скопированы на сервер CA для подписи закрытым ключом сервера CA.

Копирование множества ключей на CA для подписи может вызвать путаницу, если они не имеют уникальных имён. Если всегда используется имя по умолчанию, то последний скопированный ключ перезапишет ранее скопированный ключ, что может быть приемлемым методом для одного администратора. В приведённом ниже примере используется имя по умолчанию. В продуктивной среде рассмотрите использование легко распознаваемых имён. Рекомендуется иметь на сервере CA специальный каталог, принадлежащий административному пользователю, для копирования в него ключей. Копирование этих ключей в каталог /etc/ssh/ пользователя root не рекомендуется. В приведённых ниже примерах будет использоваться учётная запись с именем admin с каталогом keys/.

Создайте учётную запись администратора, в этом примере admin, и каталог для приёма ключей пользователя. Например:

$ mkdir keys

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

$ chmod o+w keys
$ ls -la keys
total 8
drwxrwxrwx. 2 admin admin 4096 May 22 16:17 .
drwx------. 3 admin admin 4096 May 22 16:17 ..

Создание сертификатов SSH для аутентификации хостов

Команда для подписи хостового сертификата имеет следующий формат:

$ ssh-keygen -s ca_host_key -I host_name -h ssh_host_rsa_key.pub

Хостовый сертификат будет называться ssh_host_rsa_key-cert.pub.

Создание хостового сертификата

Чтобы аутентифицировать хост для пользователя, открытый ключ должен быть создан на хосте, передан на сервер CA, подписан CA, а затем возвращён обратно для хранения на хосте, чтобы предъявить его пользователю, пытающемуся войти на хост.

Ключи хоста создаются в системе автоматически. Чтобы вывести их список, введите следующую команду:

$ sudo ls -l /etc/ssh/ssh_host*
-rw-------. 1 root root  480 May 13 16:11 /etc/ssh/ssh_host_ecdsa_key
-rw-r--r--. 1 root root  162 May 13 16:11 /etc/ssh/ssh_host_ecdsa_key.pub
-rw-------. 1 root root  387 May 13 16:11 /etc/ssh/ssh_host_ed25519_key
-rw-r--r--. 1 root root   82 May 13 16:11 /etc/ssh/ssh_host_ed25519_key.pub
-rw-------. 1 root root 2578 May 13 16:11 /etc/ssh/ssh_host_rsa_key
-rw-r--r--. 1 root root  554 May 13 16:11 /etc/ssh/ssh_host_rsa_key.pub

Скопируйте выбранный открытый ключ на сервер, назначенный в качестве CA. Например, с хоста:

$ sudo scp /etc/ssh/ssh_host_rsa_key.pub admin@ca-server.example.com:~/keys/ssh_host_rsa_key.pub
The authenticity of host 'ca-server.example.com (192.0.2.2)' can't be established.
ED25519 key fingerprint is SHA256:ZYEUaevOAEASvYjm58PiPdMebxhhlaTZBjTMr/N2I3c.
This key is not known by any other names.
Are you sure you want to continue connecting (yes/no/[fingerprint])? yes
Warning: Permanently added 'ca-server.example.com' (ED25519) to the list of known hosts.
admin@ca-server.example.com's password:
ssh_host_rsa_key.pub                           100%  382     0.4KB/s   00:00

В качестве альтернативы с CA:

$ sudo scp  root@host_name.example.com:/etc/ssh/ssh_host_rsa_key.pub ~/keys/ssh_host_rsa_key.pub

На сервере CA подпишите открытый ключ хоста. Например:

$ sudo ssh-keygen -s ~/.ssh/ca_host_key -I host_name -h -n host_name.example.com -V -1d:+54w /home/admin/keys/ssh_host_rsa_key.pub
Enter passphrase:
Signed host key /home/admin/keys/ssh_host_rsa_key-cert.pub: id "host_name" serial 0 for host_name.example.com valid from 2020-05-26T12:21:54 to 2021-06-08T12:21:54

Где host_name — имя хоста системы, которой требуется сертификат.

Скопируйте сертификат на хост. Например, с CA:

$ sudo scp /home/admin/keys/ssh_host_rsa_key-cert.pub root@host_name.example.com:/etc/ssh/
root@host_name.example.com's password:
ssh_host_rsa_key-cert.pub                      100% 1384     1.5KB/s   00:00

Настройте хост на предъявление сертификата системе пользователя, когда пользователь инициирует процесс входа. От имени root отредактируйте файл /etc/ssh/sshd_config следующим образом:
```
HostCertificate /etc/ssh/ssh_host_rsa_key-cert.pub
```
Перезапустите sshd, чтобы изменения вступили в силу:
```
$ sudo systemctl restart sshd.service
```
В системах пользователей удалите ключи, принадлежащие хостам, из файла ~/.ssh/known_hosts, если пользователь ранее входил на хост, настроенный выше. Когда пользователь входит на хост, ему больше не должно выдаваться предупреждение о подлинности хоста.

Чтобы проверить хостовый сертификат, на клиентской системе убедитесь, что клиент настроил глобальный файл /etc/ssh/known_hosts, как описано в Доверие ключу подписи хоста, и что открытый ключ сервера отсутствует в файле ~/.ssh/known_hosts. Затем попытайтесь войти на сервер по SSH как удалённый пользователь. Вы не должны увидеть предупреждение о подлинности хоста. При необходимости добавьте параметр -v к команде SSH, чтобы увидеть информацию журнала.

Создание сертификатов SSH для аутентификации пользователей

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

$ ssh-keygen -s ca_user_key -I user_name -n user_name -V -start:+end id_rsa.pub

Полученный сертификат будет называться id_rsa-cert.pub.

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

Добавьте больше имён пользователей в сертификат во время процесса подписи, используя параметр -n:
```
-n "name1[,name2,...]"
```
В системе пользователя добавьте открытый ключ CA в файл ~/.ssh/authorized_keys, используя директиву cert-authority, и перечислите имена принципалов следующим образом:
```
$ vi ~/.ssh/authorized_keys
# Ключ CA, принимаемый для любого хоста в *.example.com
@cert-authority principals="name1,name2" *.example.com ssh-rsa AAAAB5Wm.
```
На сервере создайте файл AuthorizedPrincipalsFile, либо для отдельного пользователя, либо глобально, и добавьте в файл имена принципалов для тех пользователей, которым разрешён вход. Затем в файле /etc/ssh/sshd_config укажите этот файл с помощью директивы AuthorizedPrincipalsFile.

Создание пользовательского сертификата

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

В клиентских системах войдите как пользователь, которому требуется сертификат. Проверьте доступные ключи следующим образом:
```
$ ls -l ~/.ssh/
```
Если подходящего открытого ключа не существует, создайте его и установите права доступа к каталогу, если каталог не является каталогом по умолчанию. Например, введите следующую команду:
```
$ ssh-keygen -t rsa
Generating public/private rsa key pair.
Enter file in which to save the key (/home/user1/.ssh/id_rsa):
Created directory '/home/user1/.ssh'.
Enter passphrase (empty for no passphrase):
Enter same passphrase again:
Your identification has been saved in /home/user1/.ssh/id_rsa
Your public key has been saved in /home/user1/.ssh/id_rsa.pub
The key fingerprint is:
SHA256:y6f0DGlHe28YWotEypnhfk3WLYQ5TgaQwoSlOFwmmm0 user1@host1.example.com
The key's randomart image is:
---[RSA 3072]----
|    oo+.        |
|   o.o.o.        |
|   .o o .        |
|    oo . o       |
|   . oo.S        |
|     o=..        |
|     .Eo        |
|      .=         |
|     ..          |
----[SHA256]-----
```
По умолчанию права доступа к каталогу для ключей пользователя — drwx------., или восьмеричное 0700. При необходимости убедитесь, что права доступа корректны:
```
$ ls -la ~/.ssh
total 16
drwx------. 2 user1 user1 4096 May  7 12:37 .
drwx------. 3 user1 user1 4096 May  7 12:37 ..
-rw-------. 1 user1 user1 1679 May  7 12:37 id_rsa
-rw-r--r--. 1 user1 user1  421 May  7 12:37 id_rsa.pub
```
См. Создание пар ключей в Настройка клиента OpenSSH для других примеров создания ключей и инструкций по установке правильных прав доступа к каталогу.
Выбранный открытый ключ должен быть скопирован на сервер, назначенный в качестве CA, чтобы быть подписанным. Для этого можно использовать команду безопасного копирования; команда имеет следующий формат:
```
$ scp  ~/.ssh/id_protocol.pub admin@ca_server.example.com:~/keys/
```
Где protocol — часть имени файла, указывающая протокол, использованный для создания ключа, например rsa, admin — учётная запись на сервере CA, а /keys/ — каталог, настроенный для приёма ключей на подпись.

Скопируйте выбранный открытый ключ на сервер, назначенный в качестве CA. Например:
```
$ scp ~/.ssh/id_rsa.pub admin@ca-server.example.com:~/keys/
admin@ca-server.example.com's password:
id_rsa.pub                                  100%  421     0.4KB/s   00:00
```
Если вы настроили клиентскую систему на доверие ключу подписи хоста, как описано в Доверие ключу подписи хоста, то вы не должны увидеть предупреждение о подлинности удалённого хоста.

На сервере CA подпишите открытый ключ пользователя. Например, от имени root:

$ sudo ssh-keygen -s /root/.ssh/ca_user_key -I user1 -n user1 -V -1d:+54w /home/admin/keys/id_rsa.pub
Enter passphrase:
Signed user key /home/admin/keys/id_rsa-cert.pub: id "user1" serial 0 for host_name.example.com valid from 2020-05-21T16:43:17 to 2021-06-03T16:43:17

Скопируйте полученный сертификат в каталог ~/.ssh/ пользователя в его системе. Например:

sudo scp /home/admin/keys/id_rsa-cert.pub user1@host_name.example.com:~/.ssh/
user1@host_name.example.com's password:
id_rsa-cert.pub                             100%  1498    1.5KB/s   00:00

При использовании стандартных имён файлов и расположения дополнительная конфигурация не требуется, так как демон SSH будет искать пользовательские сертификаты с окончанием -cert.pub и автоматически использовать их, если найдёт. Обратите внимание, что расположение и имена файлов по умолчанию для ключей SSH версии 2: ~/.ssh/id_ecdsa, ~/.ssh/id_ed25519 и ~/.ssh/id_rsa, как объясняется на странице руководства ssh_config(5). Если вы используете эти расположения и соглашения об именовании, то нет необходимости редактировать файлы конфигурации, чтобы sshd мог предъявить сертификат. Они будут использоваться автоматически при входе в удалённую систему. В этом случае перейдите к шагу 6.

Если требуется использовать нестандартный каталог или соглашение об именовании файлов, то от имени root добавьте следующую строку в файлы /etc/ssh/ssh_config или ~/.ssh/config:
```
IdentityFile ~/path/key_file
```
Обратите внимание, что это должно быть имя закрытого ключа, не добавляйте .pub или -cert.pub. Убедитесь, что права доступа к файлу корректны. Например:
```
$ ls -la ~/.ssh/config
-rw-rw-r--. 1 user1 user1 36 May 27 21:49 /home/user1/.ssh/config
$ chmod 700 ~/.ssh/config
$ ls -la ~/.ssh/config
-rwx------. 1 user1 user1 36 May 27 21:49 /home/user1/.ssh/config
```
Это позволит пользователю этой системы аутентифицироваться по пользовательскому сертификату при входе в удалённую систему, настроенную на доверие ключу подписи пользовательских сертификатов CA.
Чтобы проверить пользовательский сертификат, попытайтесь войти на сервер по SSH из учётной записи пользователя. Вам следует делать это как пользователь, указанный в качестве принципала в сертификате, если таковые указаны. У вас не должен запрашиваться пароль. При необходимости добавьте параметр -v к команде SSH, чтобы увидеть информацию журнала.

Подписание SSH-сертификата с использованием токена PKCS#11

Можно подписать ключ хоста с использованием ключа CA, хранящегося в токене PKCS#11, указав библиотеку токена с помощью -D и идентифицировав ключ CA, передав его открытую половину в качестве аргумента параметру -s:

$ ssh-keygen -s ca_host_key.pub -D libpkcs11.so -I certificate_ID host_key.pub

Во всех случаях certificate_ID — это «идентификатор ключа», который записывается в журнал сервером, когда сертификат используется для аутентификации.

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

$ ssh-keygen -s ca_user_key.pub -D libpkcs11.so -I certificate_ID -n user1,user2 id_rsa.pub

и для хостов:

$ ssh-keygen -s ca_host_key.pub -D libpkcs11.so -I certificate_ID -h -n host.domain ssh_host_rsa_key.pub

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

Сертификаты могут быть определены как действительные в течение определённого срока. Параметр -V позволяет указать время начала и окончания действия сертификата. Например:

$ ssh-keygen -s ca_user_key -I certificate_ID -V "-1w:+54w5d" id_rsa.pub

Сертификат, предъявленный вне этого диапазона, не будет считаться действительным. По умолчанию сертификаты действительны бессрочно начиная с эпохи UNIX.

Просмотр сертификата SSH CA

Чтобы просмотреть сертификат, используйте -L для вывода его содержимого. Например, для пользовательского сертификата:

$ ssh-keygen -L -f ~/.ssh/id_rsa-cert.pub
/home/user1/.ssh/id_rsa-cert.pub:
        Type: ssh-rsa-cert-v01@openssh.com user certificate
        Public key: RSA-CERT SHA256:y6f0DGlHe28YWotEypnhfk3WLYQ5TgaQwoSlOFwmmm0
        Signing CA: RSA SHA256:y6f0DGlHe28YWotEypnhfk3WLYQ5TgaQwoSlOFwmmm0
        Key ID: "user1"
        Serial: 0
        Valid: from 2020-05-27T00:09:16 to 2021-06-09T00:09:16
        Principals:
                user1
        Critical Options: (none)
        Extensions:
                permit-X11-forwarding
                permit-agent-forwarding
                permit-port-forwarding
                permit-pty
                permit-user-rc

Чтобы просмотреть хостовый сертификат:

$ sudo ssh-keygen -L -f /etc/ssh/ssh_host_rsa_key-cert.pub
/etc/ssh/ssh_host_rsa_key-cert.pub:
        Type: ssh-rsa-cert-v01@openssh.com host certificate
        Public key: RSA-CERT SHA256:y6f0DGlHe28YWotEypnhfk3WLYQ5TgaQwoSlOFwmmm0
        Signing CA: RSA SHA256:y6f0DGlHe28YWotEypnhfk3WLYQ5TgaQwoSlOFwmmm0
        Key ID: "host_name"
        Serial: 0
        Valid: from 2020-05-26T17:19:01 to 2021-06-08T17:19:01
        Principals:
                host_name.example.com
        Critical Options: (none)
        Extensions: (none)

Отзыв сертификата SSH CA

Если сертификат украден, его следует отозвать. Хотя OpenSSH не предоставляет механизма для распространения списка отзыва, всё же проще создать список отзыва и распространить его другими способами, чем менять ключи CA и все ранее созданные и распространённые хостовые и пользовательские сертификаты.

Ключи можно отозвать, добавив их в файл revoked_keys и указав имя файла в файле sshd_config следующим образом:

RevokedKeys /etc/ssh/revoked_keys

Обратите внимание, что если этот файл недоступен для чтения, то аутентификация по открытому ключу будет отклонена для всех пользователей.

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

$ ssh-keygen -kf  /etc/ssh/revoked_keys -z 1 ~/.ssh/id_rsa.pub

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

$ ssh-keygen -ukf /etc/ssh/revoked_keys -z integer ~/.ssh/id_rsa.pub

где integer — номер строки.

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

$ ssh-keygen -Qf  /etc/ssh/revoked_keys ~/.ssh/id_rsa.pub

Пользователь может отозвать сертификат CA, изменив директиву cert-authority на revoke в файле known_hosts.

Вариант использования: перенаправление X11 и портов

Безопасный интерфейс командной строки — это лишь начало множества способов использования SSH. При достаточной пропускной способности сеансы X11 можно направлять через канал SSH. Или, используя перенаправление TCP/IP, ранее небезопасные портовые соединения между системами можно отобразить на определённые каналы SSH.

Перенаправление X11

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

$ ssh -Y username@hostname

Например, чтобы войти на удалённую машину с именем penguin.example.com под именем пользователя USER, введите:

$ ssh -Y USER@penguin.example.com
USER@penguin.example.com's password:

Когда X-программа запускается из командной строки защищённой оболочки, клиент и сервер SSH создают новый защищённый канал, и данные X-программы прозрачно передаются по этому каналу на клиентскую машину.

Чтобы перенаправление X11 работало, сервер SSH должен его разрешать. Убедитесь, что в /etc/ssh/sshd_config установлено X11Forwarding yes (см. Настройка сервера OpenSSH)

Удалённая система также должна иметь возможность запускать приложения X11 и аутентифицировать сеансы X11. Для этой цели требуется пакет xorg-x11-xauth.

$ sudo dnf install xorg-x11-xauth

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

$ ssh -Y user@penguin.example.com firefox

Приложение Firefox открывается, позволяя вам просматривать веб-страницы с помощью приложения firefox, как будто вы находитесь на удалённой системе. Когда вы закрываете браузер, SSH-соединение прерывается. Вы также можете войти на удалённую систему по SSH и затем запустить любое графическое приложение из командной строки и использовать параметр & для перевода процесса в фоновый режим. Если вы сделаете это, SSH-соединение останется открытым после закрытия графического приложения, и вы сможете запускать несколько графических приложений в одном сеансе.

Обратите внимание, что хотя Wayland заменяет устаревший сервер X11 в качестве сервера дисплея в Fedora, перенаправление приложений X11 по SSH по-прежнему работает.

Локальное перенаправление портов (-L)

SSH может защитить иначе небезопасные протоколы TCP/IP посредством перенаправления портов. При использовании этой техники сервер SSH становится шифрованным каналом для клиента SSH.

Перенаправление портов работает путём отображения локального порта на клиенте на удалённый порт на сервере. SSH может отобразить любой порт с сервера на любой порт на клиенте. Для работы этой техники номера портов не обязательно должны совпадать.

Использование зарезервированных номеров портов

Настройка перенаправления портов для прослушивания портов ниже 1024 требует доступа уровня root.

Чтобы создать канал перенаправления портов TCP/IP, который прослушивает соединения на localhost, используйте команду следующего вида:

$ ssh -L local-port:remote-hostname:remote-port username@hostname

Например, чтобы проверить электронную почту на сервере с именем mail.example.com с использованием POP3 через шифрованное соединение, используйте следующую команду:

$ ssh -L 1100:mail.example.com:110 mail.example.com

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

Если на mail.example.com не работает сервер SSH, но он работает на другой машине в той же сети, SSH всё ещё можно использовать для защиты части соединения. Однако необходима немного другая команда:

$ ssh -L 1100:mail.example.com:110 other.example.com

В этом примере запросы POP3 с порта 1100 на клиентской машине перенаправляются через SSH-соединение на порту 22 на сервер SSH other.example.com. Затем other.example.com подключается к порту 110 на mail.example.com для проверки новой почты. Обратите внимание, что при использовании этой техники безопасным является только соединение между клиентской системой и сервером SSH other.example.com.

Перенаправление портов также можно использовать для безопасного получения информации через сетевые брандмауэры. Если брандмауэр настроен на разрешение трафика SSH через свой стандартный порт (то есть порт 22), но блокирует доступ к другим портам, соединение между двумя хостами с использованием заблокированных портов всё ещё возможно путём перенаправления их обмена данными через установленное SSH-соединение.

Соединение настолько безопасно, насколько безопасна клиентская система

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

Системные администраторы, обеспокоенные перенаправлением портов, могут отключить эту функциональность на сервере, указав параметр No для строки AllowTcpForwarding в /etc/ssh/sshd_config и перезапустив службу sshd.

См. также

О SSH и OpenSSH — концептуальная основа протокола SSH.
Настройка сервера OpenSSH — полный справочник по sshd и конфигурации на стороне сервера.
Настройка клиента OpenSSH — полный справочник по ssh, scp, sftp и конфигурации на стороне клиента.

Want to help? Learn how to contribute to Fedora Docs ›