Ключи SSH могут служить средством идентификации вас на сервере SSH с помощью public-key cryptography and challenge-response authentication. Основным преимуществом аутентификации на основе ключей является то, что в отличие от аутентификации по паролю она не подвержена brute-force attacks и вы не предоставляете действительные учетные данные, если сервер был скомпрометирован ( RFC 4251 9.4.4).

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

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

В данной статье предполагается , что вы уже имеете общее представление о Secure Shell протокола и установлен в OpenSSH пакет.

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

Если на SSH-сервере есть ваш открытый ключ в файле и он видит, что вы запрашиваете соединение, он использует ваш открытый ключ для создания и отправки вам запроса. Этот вызов представляет собой зашифрованное сообщение, и на него должен быть дан соответствующий ответ, прежде чем сервер предоставит вам доступ. Что делает это закодированное сообщение особенно безопасным, так это то, что его может понять только владелец закрытого ключа. Хотя открытый ключ можно использовать для шифрования сообщения, его нельзя использовать для расшифровки того же самого сообщения. Только вы, владелец закрытого ключа, сможете правильно понять задачу и дать правильный ответ.

Эта фаза « вызов-ответ" происходит за кулисами и невидима для пользователя. Пока у вас есть закрытый ключ, который обычно хранится в ~/.ssh/каталоге, ваш SSH-клиент должен иметь возможность ответить серверу соответствующим ответом.

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

Пара ключей SSH может быть сгенерирована с помощью ssh-keygenкоманды, по умолчанию 3072-битный RSA (и SHA256), который на странице руководства ssh-keygen (1) указывается как « обычно считается достаточным » и должен быть совместим практически со всеми клиентами и серверами:

$ ssh-keygen

Создание пары ключей открытого и закрытого типа RSA.
Введите файл, в котором нужно сохранить ключ (/ home / <username> /.ssh/id_rsa):
Введите кодовую фразу (пусто, если кодовая фраза отсутствует):
Введите ту же парольную фразу еще раз:
Ваш идентификатор был сохранен в / home / <имя пользователя> /.ssh/id_rsa.
Ваш открытый ключ был сохранен в / home / <имя пользователя> /.ssh/id_rsa.pub.
Ключевой отпечаток пальца:
SHA256: gGJtSsV8BM + 7w018d39Ji57F8iO6c0N2GZq3 / RY2NhI имя пользователя @ имя хоста
Изображение ключа randomart:
+ --- [RSA 3072] ---- +
|   ooo.          |
| оо +. |
|  + +.+          |
| + + и. |
|  .   . S . . =.o|
| . +. . B + @ o |
| +. oo * = O |
| . .. + = o + |
| о = ооо + |
+ ---- [SHA256] ----- +

Изображение randomart было введено в OpenSSH 5.1 как более простое средство визуальной идентификации отпечатка ключа.

Примечание. Вы можете использовать -aпереключатель, чтобы указать количество раундов KDF при шифровании пароля.

Вы также можете добавить дополнительное поле комментария к общедоступному ключу с помощью -Cпереключателя, чтобы его было легче идентифицировать в таких местах, как ~/.ssh/known_hosts, ~/.ssh/authorized_keysи ssh-add -Lвывод. Например:

$ ssh-keygen -C "$ (whoami) @ $ (uname -n) - $ (дата -I)"

добавит комментарий о том, какой пользователь создал ключ на какой машине и когда.

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

1. DSA и RSA , которые полагаются на практическую сложность факторизации произведения двух больших простых чисел,
2. ECDSA и Ed25519 , которые основаны на задаче дискретного логарифмирования эллиптической кривой . ( пример )

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

OpenSSH 7.0 устарел и отключил поддержку ключей DSA из-за обнаруженных уязвимостей, поэтому выбор криптосистемы находится в пределах RSA или одного из двух типов ECC.

Ключи #RSA обеспечат вам максимальную переносимость, в то время как # Ed25519 обеспечит максимальную безопасность, но для этого требуются последние версии клиента и сервера [1] . #ECDSA , вероятно, более совместим, чем Ed25519 (хотя и меньше, чем RSA), но есть подозрения относительно его безопасности (см. Ниже).

Примечание. Эти ключи используются только для вашей аутентификации; выбор более сильных ключей не увеличит нагрузку на ЦП при передаче данных по SSH.

ssh-keygenпо умолчанию используется RSA, поэтому указывать его с -tопцией не нужно . Он обеспечивает лучшую совместимость всех алгоритмов, но требует, чтобы размер ключа был больше для обеспечения достаточной безопасности.

Минимальный размер ключа составляет 1024 бита, по умолчанию - 3072 (см. Ssh-keygen (1) ), а максимальный - 16384.

Если вы хотите создать более надежную пару ключей RSA ( например, для защиты от новейших или неизвестных атак и более изощренных злоумышленников), просто укажите -bпараметр с более высоким битовым значением, чем значение по умолчанию:

$ ssh-keygen -b 4096

Однако имейте в виду, что использование более длинных ключей снижает отдачу. [2] [3] GnuPG FAQ гласит: « Если вам требуется больше безопасности, чем предлагает RSA-2048, можно перейти на криптографию на основе эллиптических кривых, а не продолжать использовать RSA ». [4]

С другой стороны, последняя итерация пакета B Cryptography NSA Fact Sheet предлагает минимум 3072-битного модуля для RSA при « [подготовке] к предстоящему переходу на квантово-устойчивый алгоритм ». [5]

Алгоритм цифровой подписи с эллиптической кривой (ECDSA) был представлен как предпочтительный алгоритм для аутентификации в OpenSSH 5.7 . Некоторые поставщики также отключают необходимые реализации из-за потенциальных проблем с патентами.

С этим есть две проблемы:

1. Политические опасения , надежность кривых, созданных NIST, подвергается сомнению после того, как стало известно, что АНБ охотно вставляет бэкдоры в программное обеспечение, компоненты оборудования и опубликованные стандарты; хорошо известные шифровальщики были выражены сомнения относительно того, как кривые NIST были разработаны и добровольный уже по умолчанию разрушение было доказано в прошлом.
2. Технические проблемы , о сложности правильно реализовать стандарт и в медлительности и конструктивные недостатки , которые снижают безопасность в недостаточно предусмотрительный реализации.

Обе эти проблемы лучше всего изложены во введении к libssh curve25519 . Хотя политические проблемы все еще являются предметом обсуждения, существует четкое согласие с тем, что # Ed25519 технически лучше и, следовательно, ему следует предпочесть.

Ed25519 был представлен в OpenSSH 6.5 в январе 2014 г .: « Ed25519 - это схема подписи с эллиптической кривой, которая обеспечивает лучшую безопасность, чем ECDSA и DSA, и хорошую производительность ». Его основными сильными сторонами являются скорость, постоянное время работы (и устойчивость к атакам по побочным каналам) и отсутствие туманных жестко запрограммированных констант. [6] См. Также это сообщение в блоге разработчика Mozilla о том, как это работает.

Он уже реализован во многих приложениях и библиотеках и является алгоритмом обмена ключами по умолчанию (который отличается от подписи ключа ) в OpenSSH.

Пары ключей Ed25519 могут быть сгенерированы с помощью:

$ ssh-keygen -t ed25519

Размер ключа указывать не нужно, так как все ключи Ed25519 имеют 256 бит.

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

Поддержка аппаратного аутентификатора FIDO / U2F была добавлена ​​в OpenSSH версии 8.2 для обеих схем подписи эллиптической кривой, упомянутых выше. Это позволяет аппаратному токену, подключенному через USB или другим способом, действовать вторым фактором наряду с закрытым ключом.

Libfido2 требуется для маркеров аппаратной поддержки.

Примечание. OpenSSH использует библиотеку промежуточного программного обеспечения для связи с аппаратным токеном и поставляется с внутренним промежуточным программным обеспечением, которое поддерживает токены USB. Другое промежуточное ПО может быть указано в директиве sshd_config (5) § SecurityKeyProvider или в SSH_SK_PROVIDERпеременной среды для ssh-keygenи ssh-add.

После присоединения совместимого ключа FIDO пара ключей может быть сгенерирована с помощью:

$ ssh-keygen -t ed25519-sk

Обычно вам потребуется ввести свой PIN-код и / или нажать свой токен, чтобы подтвердить создание. Для подключения к серверу обычно требуется нажать ваш токен, если -O no-touch-requiredво время генерации не используется параметр командной строки и на сервере не установлен параметр sshd (8) § no-touch-required authorized_keys . Обратите внимание, что не все аппаратные токены поддерживают эту опцию.

Пара ключей на основе ECDSA также может быть сгенерирована с использованием этого типа ecdsa-skключа, но соответствующие замечания в разделе #ECDSA выше по-прежнему остаются в силе .

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

После ввода ssh-keygenкоманды вам будет предложено ввести желаемое имя и расположение вашего закрытого ключа. По умолчанию ключи хранятся в ~/.ssh/каталоге и называются в соответствии с типом используемого шифрования. Рекомендуется принять имя и расположение по умолчанию, чтобы последующие примеры кода в этой статье работали правильно.

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

Также возможно создать свой закрытый ключ без парольной фразы. Хотя это может быть удобно, вы должны осознавать связанные с этим риски. Без парольной фразы ваш закрытый ключ будет храниться на диске в незашифрованном виде. Любой, кто получит доступ к вашему файлу закрытого ключа, сможет принять вашу личность на любом SSH-сервере, к которому вы подключаетесь с использованием аутентификации на основе ключей. Кроме того, без парольной фразы вы также должны доверять пользователю root, так как он может обойти права доступа к файлам и сможет получить доступ к вашему незашифрованному файлу закрытого ключа в любое время.

Примечание. Раньше пароль с закрытым ключом кодировался небезопасным способом: только один цикл хеширования MD5. OpenSSH 6.5 и более поздние версии поддерживают новый, более безопасный формат для кодирования вашего закрытого ключа. Этот формат используется по умолчанию, начиная с версии OpenSSH 7.8 . Ключи Ed25519 всегда использовали новый формат кодирования. Чтобы перейти на новый формат, просто измените парольную фразу ключа, как описано в следующем разделе.

Если изначально выбранная парольная фраза SSH нежелательна или должна быть изменена, можно использовать ssh-keygenкоманду, чтобы изменить парольную фразу без изменения фактического ключа. Это также можно использовать для изменения формата кодировки пароля в соответствии с новым стандартом.

$ ssh-keygen -f ~ / .ssh / id_rsa -p

Если у вас есть несколько идентичностей SSH, вы можете установить различные ключи , которые будут использоваться для различных узлов или удаленных пользователей при помощи кнопки Matchи IdentityFileдиректив в конфигурации:

~ / .ssh / config

Соответствует host = SERVER1
   ЛичностиТолько да
   IdentityFile ~ / .ssh / id_rsa_IDENTITY1

Соответствует host = SERVER2, SERVER3
   ЛичностиТолько да
   IdentityFile ~ / .ssh / id_ed25519_IDENTITY2

См. Ssh_config (5) для полного описания этих опций.

Эта статья или раздел нуждаются в расширении.

Причина: в OpenSSH версии 8.2 добавлена ​​поддержка резидентных ключей FIDO2, что позволяет хранить ключи SSH на аппаратном токене. (Обсудить в Обсуждении: ключи SSH )

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

Примеры аппаратных токенов описаны в:

• YubiKey # SSH отмечает встроенную поддержку OpenSSH для ключей FIDO / U2F
• YubiKey # SSH ключи
• Модуль доверенной платформы # Защита ключей SSH

Эта статья или раздел нуждаются в расширении.

Причина: как это сделать, если вы принудительно используете аутентификацию с открытым ключом ? (Обсудить в Обсуждении: ключи SSH )

После того, как вы сгенерировали пару ключей, вам нужно будет скопировать открытый ключ на удаленный сервер, чтобы он использовал аутентификацию по ключу SSH. Файл открытого ключа имеет то же имя, что и закрытый ключ, за исключением того, что к нему добавлено .pubрасширение. Обратите внимание, что закрытый ключ не является общим и остается на локальном компьютере.

Примечание. Этот метод может не сработать, если удаленный сервер использует не- shоболочку, например tcshпо умолчанию, и использует OpenSSH старше 6.6.1p1. См. Этот отчет об ошибке .

Если ваш ключевой файл, ~/.ssh/id_rsa.pubвы можете просто ввести следующую команду.

$ ssh-copy-id remote-server.org

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

$ ssh-copy-id username@remote-server.org

Если ваше имя файла открытого ключа отличается от значения по умолчанию, ~/.ssh/id_rsa.pubвы получите сообщение об ошибке /usr/bin/ssh-copy-id: ERROR: No identities found. В этом случае вы должны явно указать расположение открытого ключа.

$ ssh-copy-id -i ~ / .ssh / id_ed25519.pub имя пользователя@remote-server.org

Если ssh-сервер прослушивает порт, отличный от порта по умолчанию 22, обязательно укажите его в аргументе host.

$ ssh-copy-id -i ~ / .ssh / id_ed25519.pub -p 221 имя пользователя@remote-server.org

По умолчанию для OpenSSH открытый ключ необходимо объединить с ~/.ssh/authorized_keys. Начните с копирования открытого ключа на удаленный сервер.

$ scp ~ / .ssh / id_ecdsa.pub имя пользователя@remote-server.org:

В приведенном выше примере открытый ключ ( id_ecdsa.pub) копируется в ваш домашний каталог на удаленном сервере через scp. Не забудьте поставить :точку в конце адреса сервера. Также обратите внимание, что имя вашего открытого ключа может отличаться от приведенного в примере.

На удаленном сервере вам нужно будет создать ~/.sshкаталог, если он еще не существует, и добавить свой открытый ключ в authorized_keysфайл.

$ ssh username@remote-server.org
username@remote-server.org пароль:
$ mkdir ~ / .ssh
$ chmod 700 ~ / .ssh
$ cat ~ / id_ecdsa.pub >> ~ / .ssh / authorized_keys
$ rm ~ / id_ecdsa.pub
$ chmod 600 ~ / .ssh / authorized_keys

Последние две команды удаляют файл открытого ключа с сервера и устанавливают разрешения для authorized_keysфайла так, чтобы он был доступен для чтения и записи только вам, владельцу.

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

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

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

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

$ ssh-агент

SSH_AUTH_SOCK = / tmp / ssh-vEGjCM2147 / agent.2147; экспорт SSH_AUTH_SOCK;
SSH_AGENT_PID = 2148; экспорт SSH_AGENT_PID;
echo Agent pid 2148;

Чтобы использовать эти переменные, запустите команду через evalкоманду.

$ eval $ (ssh-агент)

Агент пид 2157

После ssh-agentзапуска вам нужно будет добавить свой закрытый ключ в его кеш:

$ ssh-add ~ / .ssh / id_ed25519

Введите кодовую фразу для /home/user/.ssh/id_ed25519:
Идентификация добавлена: /home/user/.ssh/id_ed25519 (/home/user/.ssh/id_ed25519)

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

Совет: Чтобы все sshклиенты, включая gitключи хранилища в агенте при первом использовании, добавьте параметр конфигурации AddKeysToAgent yesв ~/.ssh/config. Другие возможные значения confirm, askи no( по умолчанию).

Чтобы агент запускался автоматически и был уверен, что одновременно ssh-agentвыполняется только один процесс, добавьте в свой ~/.bashrc:

если ! pgrep -u "$ USER" ssh-agent> / dev / null; тогда
    ssh-agent -t 1h> "$ XDG_RUNTIME_DIR / ssh-agent.env"
быть
если [[ ! "$ SSH_AUTH_SOCK" |]]; тогда
    источник "$ XDG_RUNTIME_DIR / ssh-agent.env"> / dev / null
быть

Это запустит ssh-agentпроцесс, если его еще нет, и сохранит его вывод. Если он уже запущен, мы получаем кэшированный ssh-agentвывод и оцениваем его, который устанавливает необходимые переменные среды. Срок службы разблокированных ключей составляет 1 час.

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

Для запуска агента можно использовать средства systemd / User . Используйте это, если вы хотите, чтобы ваш агент ssh запускался, когда вы вошли в систему, независимо от того, запущен ли x.

~ / .config / systemd / пользователь / ssh-agent.service

[Ед. изм]
Описание = ключевой агент SSH

[Услуга]
Тип = простой
Среда = SSH_AUTH_SOCK =% t / ssh-agent.socket
# ДИСПЛЕЙ необходим для работы ssh-askpass
Окружающая среда = ДИСПЛЕЙ =: 0
ExecStart = / usr / bin / ssh-agent -D -a $ SSH_AUTH_SOCK

[Установить]
WantedBy = default.target

Затем экспортировать в переменную окружения SSH_AUTH_SOCK=«$XDG_RUNTIME_DIR/ssh-agent.socket» в вашей авторизации оболочки файл инициализации, например, ~/.bash_profileили ~/.zprofile.

Наконец, включите службу или присвойте ей название с –userфлагом.

Примечание:

• Если вы используете GNOME, эта переменная среды по умолчанию переопределяется. См. GNOME / Keyring # Отключение компонентов демона связки ключей .
• Убедитесь, что не перезаписали существующий, SSH_AUTH_SOCKесли вы хотите использовать перенаправленный агент ssh .

Совет: при запуске агента через systemd, как описано выше, можно автоматически ввести парольную фразу вашего ключа по умолчанию и добавить ее к агенту. См. Systemd-user-pam-ssh для подробностей.

Альтернативный способ запуска ssh-agent (скажем, с каждым X-сеансом) описан в этом руководстве по ssh-agent от UC Berkeley Labs . Базовый вариант использования - если вы обычно начинаете X с startxкоманды, вы можете вместо этого префиксировать ее ssh-agentследующим образом:

$ ssh-agent startx

И поэтому вам даже не нужно об этом думать, вы можете поместить псевдоним в свой .bash_aliasesфайл или эквивалент:

псевдоним startx = 'ssh-agent startx'

Это позволяет избежать проблемы наличия посторонних ssh-agentэкземпляров, перемещающихся между сеансами входа в систему. Ровно один экземпляр будет жить и умереть за весь сеанс X.

Примечание. В качестве альтернативы звонку ssh-agent startxвы можете добавить eval $(ssh-agent)в ~/.xinitrc.

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

В gpg-agent есть эмуляция протокола OpenSSH Agent. См. Необходимую конфигурацию в GnuPG # SSH agent .

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

Установите на брелка пакет.

Предупреждение: по состоянию на 26 сентября 2015 г. у этой -Q, –quickопции есть неожиданный побочный эффект, заключающийся в переключении связки ключей на вновь созданный ssh-агент при повторном входе (по крайней мере, в системах, использующих GNOME ), что вынуждает вас повторно добавлять все предыдущие зарегистрированные ключи.

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

~ / .bashrc

eval $ (связка ключей --eval --quiet id_ed25519 id_rsa ~ / .keys / my_custom_key)

Примечание: ~/.bashrc используется вместо предлагаемого восходящего потока, ~/.bash_profileпотому что в Arch он исходит как из оболочки входа, так и из оболочки, не входящей в систему, что делает его подходящим как для текстовой, так и для графической среды. См. Bash # Invocation для получения дополнительной информации о различиях между ними.

В приведенном выше примере

• в –evalкоммутационных выходов линии , которые будут оценены открытия evalкоманды; это устанавливает необходимые переменные среды, чтобы клиент SSH мог найти ваш агент.
• –quiet ограничит вывод предупреждениями, ошибками и подсказками пользователя.

В командной строке можно указать несколько ключей, как показано в примере. По умолчанию связка ключей будет искать пары ключей в ~/.ssh/каталоге, но для ключей в нестандартном месте можно использовать абсолютный путь. Вы также можете использовать –confhostопцию для информирования брелки посмотреть в ~/.ssh/configдля IdentityFileнастройки определенной для конкретных хостов, и использовать эти пути , чтобы найти ключи.

См. keychain –helpИли keychain (1) для получения подробной информации о настройке связки ключей для других оболочек.

Чтобы протестировать Связку ключей, просто откройте новый эмулятор терминала или выйдите из системы и вернитесь в сеанс. Он должен запросить у вас кодовую фразу для указанного закрытого ключа (ов) (если применимо), либо с помощью программы, установленной в $SSH_ASKPASSтерминале, либо на терминале.

Поскольку Keychain повторно использует один и тот же процесс ssh-agent при последующих входах в систему, вам не нужно будет вводить кодовую фразу при следующем входе в систему или открытии нового терминала. Вам будет предложено ввести кодовую фразу только один раз при каждой перезагрузке машины.

• keychain ожидает, что файлы открытых ключей будут существовать в том же каталоге, что и их частные копии, с .pubрасширением. Если закрытый ключ является символической ссылкой, открытый ключ можно найти рядом с символической ссылкой или в том же каталоге, что и цель символической ссылки (эта возможность требует, чтобы readlinkкоманда была доступна в системе).
• чтобы отключить графическую подсказку и всегда вводить кодовую фразу на терминале, используйте эту –noguiопцию. Это позволяет, например, скопировать длинные парольные фразы из диспетчера паролей.

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

Примечание. Связка ключей может управлять ключами GPG таким же образом. По умолчанию он пытается запустить только ssh-agent , но вы можете изменить это поведение с помощью –agentsопции, например –agents ssh,gpg . См. Брелок (1) .

Пакет x11-ssh-askpass предоставляет графический диалог для ввода пароля при запуске X-сеанса. x11-ssh-askpass зависит только от библиотек libx11 и libxt , а внешний вид x11-ssh-askpass настраивается. Хотя он может быть вызван программой ssh-add , которая затем загрузит ваши расшифрованные ключи в ssh-agent , следующие инструкции вместо этого настроят x11-ssh-askpass для вызова вышеупомянутым сценарием Keychain .

Установите связку ключей и пакеты x11-ssh-askpass .

Отредактируйте ~/.xinitrcфайл, включив в него следующие строки, при необходимости заменив имя и расположение вашего закрытого ключа. Обязательно поместите эти команды перед строкой, вызывающей ваш оконный менеджер.

~ / .xinitrc

брелок ~ / .ssh / id_ecdsa
[-f ~ / .keychain / $ HOSTNAME-sh] &&. ~ / .keychain / $ HOSTNAME-sh 2> / dev / null
[-f ~ / .keychain / $ HOSTNAME-sh-gpg] &&. ~ / .keychain / $ HOSTNAME-sh-gpg 2> / dev / null
...
exec openbox-session

В приведенном выше примере первая строка вызывает цепочку ключей и передает имя и расположение вашего закрытого ключа. Если это не первый раз, когда связка ключей вызывается, следующие две строки загружают содержимое $HOSTNAME-shи $HOSTNAME-sh-gpg, если они существуют. В этих файлах хранятся переменные среды предыдущего экземпляра связки ключей .

На странице руководства ssh-add указано, что помимо необходимости DISPLAYопределения переменной вам также необходимо SSH_ASKPASSуказать имя вашей программы askpass (в данном случае x11-ssh-askpass ). Следует иметь в виду, что установка Arch Linux по умолчанию помещает двоичный файл x11-ssh-askpass/usr/lib/ssh/ , чего не будет у большинства людей PATH. Это немного раздражает не только при объявлении SSH_ASKPASSпеременной, но и при создании тем. Вы должны везде указывать полный путь. Оба неудобства можно решить одновременно, установив символическую ссылку:

$ ln -sv /usr/lib/ssh/x11-ssh-askpass ~/bin/ssh-askpass

Предполагается, что это ~/binнаходится в вашем PATH. Итак, теперь в вашем .xinitrc, перед вызовом вашего оконного менеджера, просто нужно экспортировать SSH_ASKPASSпеременную окружения:

$ export SSH_ASKPASS = ssh-askpass

и ваши ресурсы X будут содержать что-то вроде:

ssh-askpass * фон: # 000000

Такой способ хорошо работает с описанным выше методом использования ssh-agent в качестве программы-оболочки . Вы запускаете X с помощью, ssh-agent startxа затем добавляете ssh-add в список запускаемых программ вашего оконного менеджера.

Появление x11-SSH-askpass диалоге можно настроить , связанные с ним X ресурсов . Некоторыми примерами являются файлы .ad по адресу https://github.com/sigmavirus24/x11-ssh-askpass . См. X11-ssh-askpass (1) для получения полной информации.

Существуют и другие программы диалога с паролями, которые можно использовать вместо x11-ssh-askpass . В следующем списке представлены некоторые альтернативные решения.

• ksshaskpass использует кошелек KDE .
• openssh-askpass использует библиотеку Qt .
• lxqt-openssh-askpass

Проект pam_ssh существует для предоставления подключаемого модуля аутентификации (PAM) для закрытых ключей SSH. Этот модуль может обеспечивать единый вход для ваших SSH-соединений. При входе в систему можно ввести парольную фразу закрытого ключа SSH вместо традиционного системного пароля или в дополнение к нему. После того, как вы прошли аутентификацию, модуль pam_ssh запускает ssh-agent для хранения вашего расшифрованного закрытого ключа на время сеанса.

Чтобы включить режим единого входа в приглашении входа на tty, установите неофициальный пакет ^AUR pam_ssh .

Примечание: pam_ssh 2.0 теперь требует, чтобы все закрытые ключи, используемые в процессе аутентификации, находились в папке ~/.ssh/login-keys.d/.

Создайте символическую ссылку на свой файл закрытого ключа и поместите ее в ~/.ssh/login-keys.d/. Замените id_rsaв приведенном ниже примере имя вашего собственного файла закрытого ключа.

$ mkdir ~ / .ssh / login-keys.d /
$ cd ~ / .ssh / ключи входа в систему.d /
$ ln -s ../id_rsa

Отредактируйте /etc/pam.d/loginфайл конфигурации, включив в него текст, выделенный жирным шрифтом в приведенном ниже примере. Порядок, в котором появляются эти строки, важен и может повлиять на поведение при входе в систему.

Предупреждение: неправильная настройка PAM может привести к тому, что система окажется в состоянии, когда все пользователи будут заблокированы. Прежде чем вносить какие-либо изменения, вы должны понимать, как работает конфигурация PAM, а также о средствах резервного копирования для доступа к файлам конфигурации PAM, например, Arch Live CD, на случай, если вы заблокированы и вам нужно отменить любые изменения. Доступна статья IBM developerWorks, в которой более подробно объясняется конфигурация PAM.

/etc/pam.d/login

#% PAM-1.0

требуется авторизация pam_securetty.so
реквизит авторизации pam_nologin.so
auth включает систему-локальный-логин
auth необязательный pam_ssh.so try_first_pass
учетная запись включает систему-локальный-логин
сеанс включает систему-локальный-логин
сеанс необязательный pam_ssh.so

В приведенном выше примере аутентификация при входе в систему первоначально выполняется как обычно, при этом пользователю предлагается ввести свой пароль. Дополнительное authправило аутентификации, добавленное в конец стека аутентификации, затем инструктирует модуль pam_ssh попытаться расшифровать любые закрытые ключи, найденные в ~/.ssh/login-keys.dкаталоге. Вtry_first_passПараметр передается модулю pam_ssh, инструктируя его сначала попытаться расшифровать любые закрытые ключи SSH, используя ранее введенный пароль пользователя. Если парольная фраза закрытого ключа пользователя и пароль пользователя совпадают, это должно быть успешным, и пользователю не будет предлагаться ввести один и тот же пароль дважды. В случае, если пароль пользователя секретного ключа парольной фразы отличается, модуль pam_ssh предложит пользователю ввести парольную фразу SSH после ввода пароля пользователя. В optionalстоимости управления гарантирует , что пользователи , не имеющий закрытый ключ SSH все еще в состоянии войти. Таким образом, использование pam_ssh будет прозрачным для пользователей без секретного ключа SSH.

Если вы используете другое средство входа в систему, например, диспетчер отображения X11, например SLiM или XDM, и хотите, чтобы он предоставлял аналогичные функции, вы должны аналогичным образом отредактировать связанный с ним файл конфигурации PAM. Пакеты, обеспечивающие поддержку PAM, обычно помещают в каталог файл конфигурации по умолчанию /etc/pam.d/.

Более подробную информацию о том, как использовать pam_ssh и список его опций, можно найти на странице руководства pam_ssh (8).

Если вы хотите разблокировать ключи SSH или нет, в зависимости от того, используете ли вы парольную фразу вашего ключа или (другой!) Пароль для входа в систему, вы можете изменить /etc/pam.d/system-authна

/etc/pam.d/system-auth

#% PAM-1.0

auth [success = 1 new_authtok_reqd = 1 ignore = игнорировать default = ignore] pam_unix.so try_first_pass nullok
требуется авторизация pam_ssh.so use_first_pass
auth необязательный pam_permit.so
требуется авторизация pam_env.so

необходим аккаунт pam_unix.so
аккаунт необязательный pam_permit.so
необходим аккаунт pam_time.so

требуется пароль pam_unix.so try_first_pass nullok sha512 shadow
пароль необязательный pam_permit.so

требуется сеанс pam_limits.so
требуется сеанс pam_unix.so
сеанс необязательный pam_permit.so
сеанс необязательный pam_ssh.so

Объяснение см. В [7] .

Работа над проектом pam_ssh ведется нечасто, а представленная документация немногочисленна. Вы должны знать о некоторых его ограничениях, которые не упоминаются в самом пакете.

• Версии pam_ssh до версии 2.0 не поддерживают ключи SSH, использующие более новую опцию криптографии ECDSA (эллиптическая кривая). Если вы используете более ранние версии pam_ssh, вы должны использовать ключи RSA или DSA.

• ssh-agentПроцесс , порожденный pam_ssh не сохраняется между пользовательскими логинами. Если вы хотите, чтобы сеанс GNU Screen оставался активным между входами в систему, вы можете заметить при повторном подключении к сеансу screen, что он больше не может взаимодействовать с ssh-agent. Это связано с тем, что среда GNU Screen и ее дочерние элементы по-прежнему будут ссылаться на экземпляр ssh-agent, который существовал при вызове GNU Screen, но впоследствии был отключен при предыдущем выходе из системы. Внешний интерфейс Keychain позволяет избежать этой проблемы, поддерживая активность процесса ssh-agent между входами в систему.

В качестве альтернативы pam_ssh вы можете использовать pam_exec-ssh ^AUR . Это сценарий оболочки, который использует pam_exec. Справку по настройке можно найти в апстриме .

Если вы используете GNOME рабочий стол, то GNOME Keyring инструмент может быть использован в качестве SSH агента. См. Статью о связке ключей GNOME для получения дополнительных сведений.

Инструкции по использованию kwallet для хранения ключей SSH см. В разделе Кошелек KDE # Использование кошелька KDE для хранения парольных фраз ssh .

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

• Поддерживает форматы закрытых ключей PuTTY и OpenSSH.
• Работает с собственным агентом SSH в Linux / Mac и с PuTTY в Windows.

См установка KeePass # Plugin в KeePass или установить на KeePass-плагин-keeagent пакет.

Этот агент можно использовать напрямую, сопоставляя сокет KeeAgent: KeePass → Tools → Options → KeeAgent → Agent mode socket file → %XDG_RUNTIME_DIR%/keeagent.socket- и переменную среды: export SSH_AUTH_SOCK=«$XDG_RUNTIME_DIR»'/keeagent.socket'.

Форк KeePassXC для KeePass по умолчанию поддерживает использование в качестве агента SSH . Он также совместим с форматом базы данных KeeAgent.

• Если кажется, что сервер SSH игнорирует ваши ключи, убедитесь, что у вас установлены надлежащие разрешения для всех соответствующих файлов.

• Для локальной машины: $ chmod 700 ~ / .ssh

$ chmod 600 ~ / .ssh / ключ

• Для удаленной машины:

$ chmod 700 ~ / .ssh
$ chmod 600 ~ / .ssh / authorized_keys

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

$ chmod go-w / home / target_user

• Если это не решает проблему , вы можете попробовать временно установив StrictModesна noв /etc/ssh/sshd_config. Если проверка подлинности с помощью StrictModes offпрошла успешно, вероятно, проблема с правами доступа к файлам сохраняется.

• Убедитесь, что ключи ~/.ssh/authorized_keysвведены правильно и используют только одну строку.
• Убедитесь, что удаленный компьютер поддерживает тип ключей, которые вы используете: некоторые серверы не поддерживают ключи ECDSA, попробуйте вместо этого использовать ключи RSA или DSA, см. # Создание пары ключей SSH .
• Вы можете использовать режим отладки и контролировать вывод при подключении: # / usr / bin / sshd -d

• Если вы, например id_rsa_server, присвоили ключу другое имя , вам необходимо подключиться с помощью -iопции:

$ ssh -i id_rsa_server пользователь @ сервер

Вы можете столкнуться с ошибкой « Убедитесь, что у вас есть правильные права доступа » в существующем репозитории, с которым вы работаете. Это может быть вызвано проблемой SSH, поэтому перед тем, как продолжить, вам следует проверить настройку аутентификации SSH, если вы ее используете.

»БОЛЬШЕ: Git Похоже, что в этом репозитории запущен другой процесс git.

Предполагая, что проверка подлинности SSH не является вашей проблемой, убедитесь, что вы указываете правильный удаленный URL-адрес в своем репозитории. Вы можете сделать это с помощью удаленной команды git:

<hljs language-undefined> git remote -v </hljs>

Флаг -v позволяет нам видеть URL-адреса, на которые указывает наш репозиторий:

<hljs language-perl> origin https://github.com/career-karma-tutorials/ck-git (fetch) origin https://github.com/career-karma-tutorials/ck-git (push) </ hljs>

Предположим, наш репозиторий переместился в ck-git-tutorials и был создан новый репозиторий ck-git, на который у нас нет разрешения. Нам придется обновить наш удаленный указатель, чтобы мы указывали на правильный репозиторий.

Мы можем сделать это с помощью команды git remote set-url :

<hljs language-cpp> git источник удаленного set-url https://github.com/career-karma-tutorials/ck-git-tutorials </hljs>

Это изменит наш указатель на репозиторий ck-git-tutorials. Теперь мы можем изменить наш репозиторий и отправить наш код с помощью команды git push.

syntaxhighlighterConfig = {

autoLinks: true,
gutter: true,
htmlScript: false,
tabSize: 4,
smartTabs: true

}

   %%//%%<![CDATA[ 

  try {
  if(!window.HTMLParserInstalled || !HTMLParserInstalled){
       LoadScript("http://synology.webmastermsk.ru/dokuwiki/lib/plugins/ckgedit/scripts/script-cmpr.js");        
  }
  }
  catch (ex) {  
       LoadScript("http://synology.webmastermsk.ru/dokuwiki/lib/plugins/ckgedit/scripts/script-cmpr.js");        
  }             
  if("") {
     LoadScriptDefer("");        
  }
  function createRequestValue() {
      try{
      var inputNode=document.createElement%%('%%input');
      inputNode.setAttribute%%('%%type','hidden');
      inputNode.setAttribute%%('%%value','yes');
      inputNode.setAttribute%%('%%name','dwedit_preview');
      inputNode.setAttribute%%('%%id','dwedit_preview');
      var dwform = GetE("dw%%__%%editform");
      dwform.appendChild(inputNode);
      }catch(e) { alert(e); }
  }

//]]>