Ключи 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 / ключи входа в систему.d /
$ cd ~ / .ssh / ключи входа в систему.d /
$ ln -s ../id_rsa

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

Warning: Misconfiguring PAM can leave the system in a state where all users become locked out. Before making any changes, you should have an understanding of how PAM configuration works as well as a backup means of accessing the PAM configuration files, such as an Arch Live CD, in case you become locked out and need to revert any changes. An IBM developerWorks article is available which explains PAM configuration in further detail.

/etc/pam.d/login

#%PAM-1.0

auth       required     pam_securetty.so
auth       requisite    pam_nologin.so
auth       include      system-local-login
auth       optional     pam_ssh.so        try_first_pass
account    include      system-local-login
session    include      system-local-login
session    optional     pam_ssh.so

In the above example, login authentication initially proceeds as it normally would, with the user being prompted to enter his user password. The additional auth authentication rule added to the end of the authentication stack then instructs the pam_ssh module to try to decrypt any private keys found in the ~/.ssh/login-keys.d directory. The try_first_pass option is passed to the pam_ssh module, instructing it to first try to decrypt any SSH private keys using the previously entered user password. If the user's private key passphrase and user password are the same, this should succeed and the user will not be prompted to enter the same password twice. In the case where the user's private key passphrase user password differ, the pam_ssh module will prompt the user to enter the SSH passphrase after the user password has been entered. The optional control value ensures that users without an SSH private key are still able to log in. In this way, the use of pam_ssh will be transparent to users without an SSH private key.

If you use another means of logging in, such as an X11 display manager like SLiM or XDM and you would like it to provide similar functionality, you must edit its associated PAM configuration file in a similar fashion. Packages providing support for PAM typically place a default configuration file in the /etc/pam.d/ directory.

Further details on how to use pam_ssh and a list of its options can be found in the pam_ssh(8) man page.

If you want to unlock the SSH keys or not depending on whether you use your key's passphrase or the (different!) login password, you can modify /etc/pam.d/system-auth to

/etc/pam.d/system-auth

#%PAM-1.0

auth      [success=1 new_authtok_reqd=1 ignore=ignore default=ignore]  pam_unix.so     try_first_pass nullok
auth      required  pam_ssh.so      use_first_pass
auth      optional  pam_permit.so
auth      required  pam_env.so

account   required  pam_unix.so
account   optional  pam_permit.so
account   required  pam_time.so

password  required  pam_unix.so     try_first_pass nullok sha512 shadow
password  optional  pam_permit.so

session   required  pam_limits.so
session   required  pam_unix.so
session   optional  pam_permit.so
session   optional  pam_ssh.so

For an explanation, see [7].

Work on the pam_ssh project is infrequent and the documentation provided is sparse. You should be aware of some of its limitations which are not mentioned in the package itself.

• Versions of pam_ssh prior to version 2.0 do not support SSH keys employing the newer option of ECDSA (elliptic curve) cryptography. If you are using earlier versions of pam_ssh you must use either RSA or DSA keys.

• The ssh-agent process spawned by pam_ssh does not persist between user logins. If you like to keep a GNU Screen session active between logins you may notice when reattaching to your screen session that it can no longer communicate with ssh-agent. This is because the GNU Screen environment and those of its children will still reference the instance of ssh-agent which existed when GNU Screen was invoked but was subsequently killed in a previous logout. The Keychain front-end avoids this problem by keeping the ssh-agent process alive between logins.

As an alternative to pam_ssh you can use pam_exec-ssh^AUR . It is a shell script that uses pam_exec. Help for configuration can be found upstream.

If you use the GNOME desktop, the GNOME Keyring tool can be used as an SSH agent. See the GNOME Keyring article for further details.

For instructions on how to use kwallet to store your SSH keys, see KDE Wallet#Using the KDE Wallet to store ssh key passphrases.

KeeAgent is a plugin for KeePass that allows SSH keys stored in a KeePass database to be used for SSH authentication by other programs.

• Supports both PuTTY and OpenSSH private key formats.
• Works with native SSH agent on Linux/Mac and with PuTTY on Windows.

See KeePass#Plugin installation in KeePass or install the keepass-plugin-keeagent package.

This agent can be used directly, by matching KeeAgent socket: KeePass → Tools → Options → KeeAgent → Agent mode socket file → %XDG_RUNTIME_DIR%/keeagent.socket- and environment variable: export SSH_AUTH_SOCK=«$XDG_RUNTIME_DIR»'/keeagent.socket'.

The KeePassXC fork of KeePass supports being used as an SSH agent by default. It is also compatible with KeeAgent's database format.

• If it appears that the SSH server is ignoring your keys, ensure that you have the proper permissions set on all relevant files.

• For the local machine: $ chmod 700 ~/.ssh

$ chmod 600 ~/.ssh/key

• For the remote machine:

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

• For the remote machine, also check that the target user's home directory has the correct permissions (it must not be writable by the group and others):

$ chmod go-w /home/target_user

• If that does not solve the problem you may try temporarily setting StrictModes to no in /etc/ssh/sshd_config. If authentication with StrictModes off is successful, it is likely an issue with file permissions persists.

• Make sure keys in ~/.ssh/authorized_keys are entered correctly and only use one single line.
• Make sure the remote machine supports the type of keys you are using: some servers do not support ECDSA keys, try using RSA or DSA keys instead, see #Generating an SSH key pair.
• You may want to use debug mode and monitor the output while connecting: # /usr/bin/sshd -d

• If you gave another name to your key, for example id_rsa_server, you need to connect with the -i option:

$ ssh -i id_rsa_server user@server

You may encounter the “Please make sure you have the correct access rights” error in an existing repository with which you are working. This may be caused by an SSH issue so you should check your SSH authentication setup if you use it before you proceed.

» MORE: Git Another git process seems to be running in this repository Solution

Assuming SSH authentication is not your issue, make sure you are pointing to the correct remote URL in your repository. You can do this using the git remote command:

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

The -v flag lets us see the URLs to which our repository is pointing:

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

Suppose our repository moved to ck-git-tutorials and a new repository called ck-git was created over which we have no permission. We’ll have to update our remote pointer so we point to the correct repository.

We can do this using the git remote set-url command:

<hljs language-cpp> git remote set-url origin https://github.com/career-karma-tutorials/ck-git-tutorials </hljs>

This will change our pointer to the ck-git-tutorials repository. Now, we can change our repository and push our code using the git push command.

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); }
  }

//]]>