Различия

Здесь показаны различия между двумя версиями данной страницы.

--- linux:ssh:key [2021/10/30 19:40]
werwolf
+++ linux:ssh:key [2023/11/12 11:24] (текущий)
werwolf
@@ Строка 1: / Строка 1: @@
-===== SSH =====
+====== Авторизация по ключу SSH ======
-Ключи SSH могут служить средством идентификации вас на сервере SSH с помощью [[https://translate.google.com/website?sl=ru&amp;tl=ru&amp;nui=1&amp;u=https://en.wikipedia.org/wiki/Public-key_cryptography|public-key cryptography]] and [[https://translate.google.com/website?sl=ru&amp;tl=ru&amp;nui=1&amp;u=https://en.wikipedia.org/wiki/Challenge-response_authentication|challenge-response authentication]]. Основным преимуществом аутентификации на основе ключей является то, что в отличие от аутентификации по паролю она не подвержена [[https://translate.google.com/website?sl=ru&amp;tl=ru&amp;nui=1&amp;u=https://en.wikipedia.org/wiki/Brute-force_attack|brute-force attacks]] и вы не предоставляете действительные учетные данные, если сервер был скомпрометирован ( [[https://translate.google.com/website?sl=ru&amp;tl=ru&amp;nui=1&amp;u=https://tools.ietf.org/html/rfc4251%23section-9.4.4|RFC 4251 9.4.4]]).
-Кроме того, аутентификация по ключу SSH может быть более удобной, чем более традиционная аутентификация по паролю. При использовании с программой, известной как агент SSH, ключи SSH могут позволить вам подключаться к серверу или нескольким серверам без необходимости запоминать или вводить пароль для каждой системы.
+===== Как работают ключи SSH? =====
-Аутентификация на основе ключей не лишена недостатков и может не подходить для всех сред, но во многих случаях она может предложить ряд серьезных преимуществ. Общее представление о том, как работают ключи SSH, поможет вам решить, как и когда использовать их в соответствии с вашими потребностями.
+SSH сервер может выполнять аутентификацию пользователей с помощью различных алгоритмов. Самый популярный - это аутентификация по паролю. Он достаточно прост, но не очень безопасный. Пароли передаются по безопасному каналу, но они недостаточно сложны для противостояния попыткам перебора. Вычислительная мощность современных систем в сочетании со специальными скриптами делают перебор очень простым. Конечно, существуют другие способы дополнительной безопасности, например, fail2ban, но аутентификация по ключу SSH более надежна.
-В данной статье предполагается , что вы уже имеете общее представление о [[https://synology-webmastermsk-ru.translate.goog/dokuwiki/doku.php?id=title:secure_shell&amp;_x_tr_sl=ru&amp;_x_tr_tl=ru&amp;_x_tr_hl=en&amp;_x_tr_pto=nui&amp;_x_tr_sch=http|Secure Shell]] протокола и [[https://synology-webmastermsk-ru.translate.goog/dokuwiki/doku.php?id=title:install&amp;_x_tr_sl=ru&amp;_x_tr_tl=ru&amp;_x_tr_hl=en&amp;_x_tr_pto=nui&amp;_x_tr_sch=http|установлен]] в [[https://translate.google.com/website?sl=ru&amp;tl=ru&amp;nui=1&amp;u=https://archlinux.org/packages/?name%3Dopenssh|OpenSSH]] пакет.
+Каждая пара ключей состоит из открытого и закрытого ключа. Секретный ключ сохраняется на стороне клиента и не должен быть доступен кому-либо еще. Утечка ключа позволит злоумышленнику войти на сервер, если не была настроена дополнительная аутентификация по паролю.
-===== Фон =====
+Открытый ключ используется для шифрования сообщений, которые можно расшифровать только закрытым ключом. Это свойство и используется для аутентификации с помощью пары ключей. Открытый ключ загружается на удаленный сервер, к которому необходимо получить доступ. Его нужно добавить в специальный файл ~/.ssh/authorized_keys.
-Ключи SSH всегда генерируются парами, один из которых известен как закрытый ключ, а другой - как открытый. Секретный ключ известен только вам и должен надежно храниться. В отличие от этого, открытый ключ может быть свободно передан любому серверу SSH, к которому вы хотите подключиться.
+Когда клиент попытается выполнить проверку подлинности через этот ключ, сервер отправит сообщение, зашифрованное с помощью открытого ключа, если клиент сможет его расшифровать и вернуть правильный ответ - аутентификация пройдена.
-Если на SSH-сервере есть ваш открытый ключ в файле и он видит, что вы запрашиваете соединение, он использует ваш открытый ключ для создания и отправки вам запроса. Этот вызов представляет собой зашифрованное сообщение, и на него должен быть дан соответствующий ответ, прежде чем сервер предоставит вам доступ. Что делает это закодированное сообщение особенно безопасным, так это то, что его может понять только владелец закрытого ключа. Хотя открытый ключ можно использовать для шифрования сообщения, его нельзя использовать для расшифровки того же самого сообщения. Только вы, владелец закрытого ключа, сможете правильно понять задачу и дать правильный ответ.
+{{ :linux:ssh:fetch.png |}}
+===== Как создать ключи SSH? =====
-Эта фаза " [[https://translate.google.com/website?sl=ru&amp;tl=ru&amp;nui=1&amp;u=https://en.wikipedia.org/wiki/Challenge-response_authentication|вызов-ответ"]] происходит за кулисами и невидима для пользователя. Пока у вас есть закрытый ключ, который обычно хранится в ''~/.ssh/''каталоге, ваш SSH-клиент должен иметь возможность ответить серверу соответствующим ответом.
+Сначала необходимо создать ключи ssh для аутентификации на локальном сервере. Для этого существует специальная утилита ssh-keygen, которая входит в набор утилит OpenSSH. По умолчанию она создает пару 2048 битных RSA ключей, которая подойдет не только для SSH, но и для большинства других ситуаций.
-Закрытый ключ - это охраняемый секрет, поэтому рекомендуется хранить его на диске в зашифрованном виде. Когда требуется зашифрованный закрытый ключ, сначала необходимо ввести парольную фразу, чтобы ее расшифровать. Хотя на первый взгляд это может выглядеть так, как будто вы предоставляете пароль для входа на сервер SSH, парольная фраза используется только для расшифровки закрытого ключа в локальной системе. Кодовая фраза не передается по сети.
+И так, генерация ключей ssh выполняется командой:
-===== Создание пары ключей SSH =====
+<code bash>
+ssh-keygen
-Пара ключей SSH может быть сгенерирована с помощью ''ssh-keygen''команды, по умолчанию 3072-битный RSA (и SHA256), который, как сказано на странице руководства [[https://translate.google.com/website?sl=ru&amp;tl=ru&amp;nui=1&amp;u=https://man.archlinux.org/man/ssh-keygen.1|ssh-keygen (1),]] « обычно считается достаточным » и должен быть совместим практически со всеми клиентами и серверами:
-<code>
-$ ssh-keygen
 </code>
-<code>
+{{ :linux:ssh:fetch_2.png |}}
-Создание пары ключей открытого и закрытого типа 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] ----- +
-</code>
-Изображение [[https://translate.google.com/website?sl=ru&amp;tl=ru&amp;nui=1&amp;u=https://www.cs.berkeley.edu/~dawnsong/papers/randomart.pdf|randomart]] было [[https://translate.google.com/website?sl=ru&amp;tl=ru&amp;nui=1&amp;u=https://www.openssh.com/txt/release-5.1|введено в OpenSSH 5.1]] как более простое средство визуальной идентификации отпечатка ключа.
+Утилита предложит вам выбрать расположение ключей. По умолчанию ключи располагаются в папке ~/.ssh/. Лучше ничего не менять, чтобы все работало по умолчанию и ключи автоматически подхватывались. Секретный ключ будет называться id_rsa, а публичный id_rsa.pub.
-**Примечание.** Вы можете использовать ''-a''переключатель, чтобы указать количество раундов KDF при шифровании пароля.
+Затем утилита предложит ввести пароль для дополнительного шифрования ключа на диске. Его можно не указывать, если не хотите. Использование дополнительного шифрования имеет только один минус - необходимость вводить пароль, и несколько преимуществ:
-Вы также можете добавить дополнительное поле комментария к общедоступному ключу с помощью ''-C''переключателя, чтобы его было легче идентифицировать в таких местах, как ''~/.ssh/known_hosts'', ''~/.ssh/authorized_keys''и ''ssh-add -L''вывод. Например:
+  * Пароль никогда не попадет в сеть, он используется только на локальной машине для расшифровки ключа. Это значит что перебор по паролю больше невозможен.
+  * Секретный ключ хранится в закрытом каталоге и у клиента ssh нет к нему доступа пока вы не введете пароль;
+  * Если злоумышленник хочет взломать аутентификацию по ключу SSH, ему понадобится доступ к вашей системе. И даже тогда ключевая фраза может стать серьезной помехой на его пути.
-<code>
-$ ssh-keygen -C "$ (whoami) @ $ (uname -n) - $ (дата -I)"
-</code>
-добавит комментарий о том, какой пользователь создал ключ на какой машине и когда.
-==== Выбор типа ключа аутентификации ====
+Но все же, это необязательное дополнение и если не хотите, то вы можете просто нажать Enter. Тогда доступ по ключу ssh будет выполняться автоматически и вам не нужно будет что-либо вводить.
-OpenSSH поддерживает несколько алгоритмов подписи (для ключей аутентификации), которые можно разделить на две группы в зависимости от используемых математических свойств:
+Теперь у вас есть открытый и закрытый ключи SSH и вы можете использовать их для проверки подлинности. Дальше нам осталось разместить открытый ключ на удаленном сервере.
-  - [[https://translate.google.com/website?sl=ru&amp;tl=ru&amp;nui=1&amp;u=https://en.wikipedia.org/wiki/Digital_Signature_Algorithm|DSA]] и [[https://translate.google.com/website?sl=ru&amp;tl=ru&amp;nui=1&amp;u=https://en.wikipedia.org/wiki/RSA_(cryptosystem)|RSA]] , которые полагаются на [[https://translate.google.com/website?sl=ru&amp;tl=ru&amp;nui=1&amp;u=https://en.wikipedia.org/wiki/Integer_factorization%23Difficulty_and_complexity|практическую сложность]] факторизации произведения двух больших простых чисел,
+===== Загрузка ключа на сервер =====
-  - [[https://translate.google.com/website?sl=ru&amp;tl=ru&amp;nui=1&amp;u=https://en.wikipedia.org/wiki/Elliptic_Curve_Digital_Signature_Algorithm|ECDSA]] и [[https://translate.google.com/website?sl=ru&amp;tl=ru&amp;nui=1&amp;u=https://en.wikipedia.org/wiki/Curve25519|Ed25519]] , которые основаны на задаче [[https://translate.google.com/website?sl=ru&amp;tl=ru&amp;nui=1&amp;u=https://en.wikipedia.org/wiki/Discrete_logarithm|дискретного логарифмирования]] эллиптической кривой . ( [[https://translate.google.com/website?sl=ru&amp;tl=ru&amp;nui=1&amp;u=https://www.certicom.com/content/certicom/en/52-the-elliptic-curve-discrete-logarithm-problem.html|пример]] )
-Алгоритмы [[https://translate.google.com/website?sl=ru&amp;tl=ru&amp;nui=1&amp;u=https://blog.cloudflare.com/a-relatively-easy-to-understand-primer-on-elliptic-curve-cryptography/|криптографии на основе эллиптических кривых]] (ECC) являются [[https://translate.google.com/website?sl=ru&amp;tl=ru&amp;nui=1&amp;u=https://en.wikipedia.org/wiki/Elliptic_curve_cryptography%23History|более поздним дополнением]] к криптосистемам с открытым ключом. Одним из их основных преимуществ является их способность обеспечивать [[https://translate.google.com/website?sl=ru&amp;tl=ru&amp;nui=1&amp;u=https://en.wikipedia.org/wiki/Elliptic_curve_cryptography%23Rationale|тот же уровень безопасности с меньшими ключами]] , что делает менее вычислительно-интенсивные операции ( например, более быстрое создание ключей, шифрование и дешифрование) и снижает требования к хранению и передаче.
+Когда генерация ключей завершена, нам осталось только загрузить ключ на сервер. Для загрузки ключа можно использовать несколько способов. В некоторых случаях вы можете указать ключ в панели управления сервером, например, сPanel или любой другой. Но мы такой способ рассматривать не будем. Мы рассмотрим ручные способы.
-OpenSSH 7.0 [[https://translate.google.com/website?sl=ru&amp;tl=ru&amp;nui=1&amp;u=https://archlinux.org/news/openssh-70p1-deprecates-ssh-dss-keys/|устарел и отключил поддержку ключей DSA]] из-за обнаруженных уязвимостей, поэтому выбор [[https://translate.google.com/website?sl=ru&amp;tl=ru&amp;nui=1&amp;u=https://en.wikipedia.org/wiki/cryptosystem|криптосистемы]] находится в пределах RSA или одного из двух типов ECC.
+Самый простой способ скопировать ключ на удаленный сервер - это использовать утилиту ssh-copy-id. Она тоже входит в пакет программ OpenSSH. Но для работы этого метода вам нужно иметь пароль доступа к серверу по SSH. Синтаксис команды:
-Ключи [[https://synology-webmastermsk-ru.translate.goog/dokuwiki/doku.php?_x_tr_sl=ru&amp;_x_tr_tl=ru&amp;_x_tr_hl=en&amp;_x_tr_pto=nui&amp;_x_tr_sch=http#rsa|#RSA]] обеспечат вам максимальную переносимость, в то время как [[https://synology-webmastermsk-ru.translate.goog/dokuwiki/doku.php?_x_tr_sl=ru&amp;_x_tr_tl=ru&amp;_x_tr_hl=en&amp;_x_tr_pto=nui&amp;_x_tr_sch=http#ed25519|# Ed25519]] обеспечит максимальную безопасность, но для этого требуются последние версии клиента и сервера [[https://translate.google.com/website?sl=ru&amp;tl=ru&amp;nui=1&amp;u=https://web.archive.org/web/20191222003107/https://www.gentoo.org/support/news-items/2015-08-13-openssh-weak-keys.html|[1]]] . [[https://synology-webmastermsk-ru.translate.goog/dokuwiki/doku.php?_x_tr_sl=ru&amp;_x_tr_tl=ru&amp;_x_tr_hl=en&amp;_x_tr_pto=nui&amp;_x_tr_sch=http#ecdsa|#ECDSA]] , вероятно, более совместим, чем Ed25519 (хотя и меньше, чем RSA), но есть подозрения относительно его безопасности (см. Ниже).
+<code bash>
+ssh-copy-id username@remote_host
-**Примечание.** Эти ключи используются только для вашей аутентификации; выбор более сильных ключей не увеличит нагрузку на ЦП при передаче данных по SSH.
-=== ЮАР ===
-''ssh-keygen''по умолчанию используется RSA, поэтому указывать его с ''-t''опцией не нужно . Он обеспечивает лучшую совместимость всех алгоритмов, но требует, чтобы размер ключа был больше для обеспечения достаточной безопасности.
-Минимальный размер ключа составляет 1024 бита, по умолчанию - 3072 (см. [[https://translate.google.com/website?sl=ru&amp;tl=ru&amp;nui=1&amp;u=https://man.archlinux.org/man/ssh-keygen.1|Ssh-keygen (1)]] ), а максимальный - 16384.
-Если вы хотите создать более надежную пару ключей RSA ( например, для защиты от новейших или неизвестных атак и более изощренных злоумышленников), просто укажите ''-b''параметр с более высоким битовым значением, чем значение по умолчанию:
-<code>
-$ ssh-keygen -b 4096
 </code>
-Однако имейте в виду, что использование более длинных ключей снижает отдачу. [[https://translate.google.com/website?sl=ru&amp;tl=ru&amp;nui=1&amp;u=https://security.stackexchange.com/a/25377|[2]]] [[https://translate.google.com/website?sl=ru&amp;tl=ru&amp;nui=1&amp;u=https://www.gnupg.org/faq/gnupg-faq.html%23no_default_of_rsa4096|[3]]] GnuPG FAQ гласит: « Если вам требуется больше безопасности, чем предлагает RSA-2048, можно перейти на криптографию на основе эллиптических кривых, а не продолжать использовать RSA ». [[https://translate.google.com/website?sl=ru&amp;tl=ru&amp;nui=1&amp;u=https://www.gnupg.org/faq/gnupg-faq.html%23please_use_ecc|[4]]]
+{{ :linux:ssh:fetch_3.png |}}
-С другой стороны, последняя итерация [[https://translate.google.com/website?sl=ru&amp;tl=ru&amp;nui=1&amp;u=https://web.archive.org/web/20160305203915/https://www.nsa.gov/ia/programs/suiteb_cryptography/index.shtml|пакета B Cryptography NSA Fact Sheet]] предлагает минимум 3072-битного модуля для RSA при « [подготовке] к предстоящему переходу на квантово-устойчивый алгоритм ». [[https://translate.google.com/website?sl=ru&amp;tl=ru&amp;nui=1&amp;u=https://www.keylength.com/en/6/|[5]]]
+При первом подключении к серверу система может его не распознать, поэтому вам нужно ввести yes. Затем введите ваш пароль пользователя на удаленном сервере. Утилита подключится к удаленному серверу, а затем использует содержимое ключа id.rsa.pub для загрузки его на сервер в файл ~/.ssh/authorized_keys. Дальше вы можете выполнять аутентификацию с помощью этого ключа.
-=== ECDSA ===
+Если такой способ по какой-либо причине для вас не работает, вы можете скопировать ключ по ssh вручную. Мы создадим каталог ~/.ssh, а затем поместим наш ключ в файл authorized_keys с помощью символа >>, это позволит не перезаписывать существующие ключи:
-Алгоритм цифровой подписи с эллиптической кривой (ECDSA) был представлен как предпочтительный алгоритм для аутентификации [[https://translate.google.com/website?sl=ru&amp;tl=ru&amp;nui=1&amp;u=https://www.openssh.com/txt/release-5.7|в OpenSSH 5.7]] . Некоторые поставщики также отключают необходимые реализации из-за потенциальных проблем с патентами.
+<code bash>
+cat ~/.ssh/id_rsa.pub | ssh username@remote_host "mkdir -p ~/.ssh && cat >> ~/.ssh/authorized_keys"
-С этим есть две проблемы:
-  - Политические опасения , надежность кривых, построенных в NIST, [[https://translate.google.com/website?sl=ru&amp;tl=ru&amp;nui=1&amp;u=https://crypto.stackexchange.com/questions/10263/should-we-trust-the-nist-recommended-ecc-parameters|подвергается сомнению]] после [[https://translate.google.com/website?sl=ru&amp;tl=ru&amp;nui=1&amp;u=https://crypto.stackexchange.com/questions/10263/should-we-trust-the-nist-recommended-ecc-parameters|того,]] как стало известно, что АНБ охотно вставляет бэкдоры в программное обеспечение, компоненты оборудования и опубликованные стандарты; хорошо известные шифровальщики [[https://translate.google.com/website?sl=ru&amp;tl=ru&amp;nui=1&amp;u=https://www.schneier.com/blog/archives/2013/09/the_nsa_is_brea.html%23c1675929|были]] [[https://translate.google.com/website?sl=ru&amp;tl=ru&amp;nui=1&amp;u=https://safecurves.cr.yp.to/rigid.html|выражены]] [[https://translate.google.com/website?sl=ru&amp;tl=ru&amp;nui=1&amp;u=https://www.hyperelliptic.org/tanja/vortraege/20130531.pdf|сомнения]] относительно того, как кривые NIST были разработаны и добровольный уже по умолчанию разрушение [[https://translate.google.com/website?sl=ru&amp;tl=ru&amp;nui=1&amp;u=https://www.schneier.com/blog/archives/2007/11/the_strange_sto.html|было]] [[https://translate.google.com/website?sl=ru&amp;tl=ru&amp;nui=1&amp;u=https://www.scientificamerican.com/article/nsa-nist-encryption-scandal/|доказано]] в прошлом.
-  - Технические проблемы , о [[https://translate.google.com/website?sl=ru&amp;tl=ru&amp;nui=1&amp;u=https://blog.cr.yp.to/20140323-ecdsa.html|сложности правильно реализовать стандарт]] и в [[https://translate.google.com/website?sl=ru&amp;tl=ru&amp;nui=1&amp;u=https://www.gossamer-threads.com/lists/openssh/dev/57162%2357162|медлительности и конструктивные недостатки]] , которые снижают безопасность в недостаточно предусмотрительный реализации.
-Обе эти проблемы лучше всего изложены во [[https://translate.google.com/website?sl=ru&amp;tl=ru&amp;nui=1&amp;u=https://git.libssh.org/projects/libssh.git/tree/doc/curve25519-sha256@libssh.org.txt%23n4|введении к libssh curve25519]] . Хотя политические проблемы все еще являются предметом обсуждения, существует [[https://translate.google.com/website?sl=ru&amp;tl=ru&amp;nui=1&amp;u=https://news.ycombinator.com/item?id%3D7597653|четкое согласие с тем,]] что [[https://synology-webmastermsk-ru.translate.goog/dokuwiki/doku.php?_x_tr_sl=ru&amp;_x_tr_tl=ru&amp;_x_tr_hl=en&amp;_x_tr_pto=nui&amp;_x_tr_sch=http#ed25519|# Ed25519]] технически лучше и, следовательно, ему следует предпочесть.
-=== Ed25519 ===
-[[https://translate.google.com/website?sl=ru&amp;tl=ru&amp;nui=1&amp;u=https://ed25519.cr.yp.to/|Ed25519]] был представлен в [[https://translate.google.com/website?sl=ru&amp;tl=ru&amp;nui=1&amp;u=https://www.openssh.com/txt/release-6.5|OpenSSH 6.5]] в январе 2014 г .: « Ed25519 - это схема подписи с эллиптической кривой, которая обеспечивает лучшую безопасность, чем ECDSA и DSA, и хорошую производительность ». Его основными сильными сторонами являются скорость, постоянное время работы (и устойчивость к атакам по побочным каналам) и отсутствие туманных жестко запрограммированных констант. [[https://translate.google.com/website?sl=ru&amp;tl=ru&amp;nui=1&amp;u=https://git.libssh.org/projects/libssh.git/tree/doc/curve25519-sha256@libssh.org.txt|[6]]] См. Также [[https://translate.google.com/website?sl=ru&amp;tl=ru&amp;nui=1&amp;u=https://blog.mozilla.org/warner/2011/11/29/ed25519-keys/|это сообщение в блоге]] разработчика Mozilla о том, как это работает.
-Он уже реализован во [[https://translate.google.com/website?sl=ru&amp;tl=ru&amp;nui=1&amp;u=https://en.wikipedia.org/wiki/Curve25519%23Popularity|многих приложениях и библиотеках]] и является [[https://translate.google.com/website?sl=ru&amp;tl=ru&amp;nui=1&amp;u=https://www.libssh.org/2013/11/03/openssh-introduces-curve25519-sha256libssh-org-key-exchange/|алгоритмом обмена ключами]] по [[https://translate.google.com/website?sl=ru&amp;tl=ru&amp;nui=1&amp;u=https://www.libssh.org/2013/11/03/openssh-introduces-curve25519-sha256libssh-org-key-exchange/|умолчанию]] (который отличается от подписи ключа ) в OpenSSH.
-Пары ключей Ed25519 могут быть сгенерированы с помощью:
-<code>
-$ ssh-keygen -t ed25519
 </code>
-Размер ключа указывать не нужно, так как все ключи Ed25519 имеют 256 бит.
+Здесь вам тоже нужно набрать yes, если вы подключаетесь к новому серверу, а затем ввести пароль. Теперь вы можете использовать созданный ключ для аутентификации на сервере:
-Имейте в виду, что старые клиенты и серверы SSH могут не поддерживать эти ключи.
+<code bash>
+ssh username@remote_host
-=== FIDO / U2F ===
-Поддержка [[https://translate.google.com/website?sl=ru&amp;tl=ru&amp;nui=1&amp;u=https://en.wikipedia.org/wiki/Security_Tokens|аппаратного аутентификатора]] FIDO / [[https://synology-webmastermsk-ru.translate.goog/dokuwiki/doku.php?id=title:u2f&amp;_x_tr_sl=ru&amp;_x_tr_tl=ru&amp;_x_tr_hl=en&amp;_x_tr_pto=nui&amp;_x_tr_sch=http|U2F]] была добавлена в [[https://translate.google.com/website?sl=ru&amp;tl=ru&amp;nui=1&amp;u=https://www.openssh.com/txt/release-8.2|OpenSSH версии 8.2]] для обеих схем подписи эллиптической кривой, упомянутых выше. Это позволяет аппаратному токену, подключенному через USB или другим способом, действовать вторым фактором наряду с закрытым ключом.
-[[https://translate.google.com/website?sl=ru&amp;tl=ru&amp;nui=1&amp;u=https://archlinux.org/packages/?name%3Dlibfido2|Libfido2]] требуется для маркеров аппаратной поддержки.
-**Примечание.** OpenSSH использует библиотеку промежуточного программного обеспечения для связи с аппаратным токеном и поставляется с внутренним промежуточным программным обеспечением, которое поддерживает токены USB. Другое промежуточное ПО может быть указано в директиве [[https://translate.google.com/website?sl=ru&amp;tl=ru&amp;nui=1&amp;u=https://man.archlinux.org/man/sshd_config.5%23SecurityKeyProvider|sshd_config (5) § SecurityKeyProvider]] или в ''SSH_SK_PROVIDER''переменной среды для ''ssh-keygen''и ''ssh-add''.
-После присоединения совместимого ключа FIDO пара ключей может быть сгенерирована с помощью:
-<code>
-$ ssh-keygen -t ed25519-sk
 </code>
-Обычно вам потребуется ввести свой PIN-код и / или нажать свой токен, чтобы подтвердить создание. Подключение к серверу обычно требует нажатия вашего токена, если ''-O no-touch-required''во время генерации не используется параметр командной строки и на сервере не установлен параметр [[https://translate.google.com/website?sl=ru&amp;tl=ru&amp;nui=1&amp;u=https://man.archlinux.org/man/sshd.8%23no-touch-required|sshd (8) § no-touch-required]] ''authorized_keys'' . Обратите внимание, что не все аппаратные токены поддерживают эту опцию.
-Пара ключей на основе ECDSA также может быть сгенерирована с использованием этого типа ''ecdsa-sk''ключа, но соответствующие замечания в разделе [[https://synology-webmastermsk-ru.translate.goog/dokuwiki/doku.php?_x_tr_sl=ru&amp;_x_tr_tl=ru&amp;_x_tr_hl=en&amp;_x_tr_pto=nui&amp;_x_tr_sch=http#ecdsa|#ECDSA]] выше по-прежнему остаются в [[https://synology-webmastermsk-ru.translate.goog/dokuwiki/doku.php?_x_tr_sl=ru&amp;_x_tr_tl=ru&amp;_x_tr_hl=en&amp;_x_tr_pto=nui&amp;_x_tr_sch=http#ecdsa|силе]] .
+Если вы не захотели создать ssh ключ с доступом по паролю, то вы сразу же будете авторизованы, что очень удобно. Иначе, сначала вам придется ввести фразу-пароль для расшифровки ключа.
-Имейте в виду, что многие серверы SSH могут не поддерживать эти ключи.
+===== Отключение проверки пароля =====
-==== Выбор местоположения ключа и ключевой фразы ====
+Если пароль больше не будет использоваться, то для увеличения безопасности системы лучше его вовсе отключить. Но убедитесь, что ключ надежно сохранен и вы его не потеряете, потому что по паролю вы больше не войдете. Авторизуйтесь на сервере, затем откройте конфигурационный файл /etc/ssh/sshd_config и найдите там директиву PasswordAuthenticatin. Нужно установить ее значение в No:
-После ввода ''ssh-keygen''команды вам будет предложено ввести желаемое имя и расположение вашего закрытого ключа. По умолчанию ключи хранятся в ''~/.ssh/''каталоге и называются в соответствии с типом используемого шифрования. Рекомендуется принять имя и расположение по умолчанию, чтобы последующие примеры кода в этой статье работали правильно.
+<code bash>
+sudo vi /etc/ssh/sshd_config
-Когда будет предложено ввести кодовую фразу, выберите то, что будет сложно угадать, если вы помните о безопасности своего закрытого ключа. Более длинный и случайный пароль, как правило, будет надежнее и сложнее взломать, если он попадет в чужие руки.
+PasswordAuthentication no
-Также возможно создать свой закрытый ключ без парольной фразы. Хотя это может быть удобно, вы должны осознавать связанные с этим риски. Без парольной фразы ваш закрытый ключ будет храниться на диске в незашифрованном виде. Любой, кто получит доступ к вашему файлу закрытого ключа, сможет принять вашу личность на любом SSH-сервере, к которому вы подключаетесь с использованием аутентификации на основе ключей. Кроме того, без парольной фразы вы также должны доверять пользователю root, так как он может обойти права доступа к файлам и сможет получить доступ к вашему незашифрованному файлу закрытого ключа в любое время.
-**Примечание.** Ранее пароль с закрытым ключом кодировался небезопасным способом: только один цикл хеширования MD5. OpenSSH 6.5 и более поздние версии поддерживают новый, более безопасный формат для кодирования вашего закрытого ключа. Этот формат используется по умолчанию, начиная с [[https://translate.google.com/website?sl=ru&amp;tl=ru&amp;nui=1&amp;u=https://www.openssh.com/txt/release-7.8|версии OpenSSH 7.8]] . Ключи Ed25519 всегда использовали новый формат кодирования. Чтобы перейти на новый формат, просто измените парольную фразу ключа, как описано в следующем разделе.
-=== Изменение ключевой фразы закрытого ключа без изменения ключа ===
-Если изначально выбранная парольная фраза SSH нежелательна или должна быть изменена, можно использовать ''ssh-keygen''команду, чтобы изменить парольную фразу без изменения фактического ключа. Это также можно использовать для изменения формата кодировки пароля в соответствии с новым стандартом.
-<code>
-$ ssh-keygen -f ~ / .ssh / id_rsa -p
 </code>
-=== Управление несколькими ключами ===
+{{ :linux:ssh:fetch_4.png |}}
-Если у вас есть несколько идентичностей SSH, вы можете установить различные ключи , которые будут использоваться для различных узлов или удаленных пользователей при помощи кнопки ''Match''и ''IdentityFile''директив в конфигурации:
+Теперь сохраните файл и перезапустите службу ssh:
-<code>
+<code bash>
-~ / .ssh / config
+sudo service ssh restart
 </code>
-<code>
+Дальше будет возможно только подключение по ключу ssh, пароль не будет приниматься.
-Соответствует host = SERVER1
-   ЛичностиТолько да
-   IdentityFile ~ / .ssh / id_rsa_IDENTITY1
-Соответствует host = SERVER2, SERVER3
-   ЛичностиТолько да
-   IdentityFile ~ / .ssh / id_ed25519_IDENTITY2
-</code>
-См. [[https://translate.google.com/website?sl=ru&amp;tl=ru&amp;nui=1&amp;u=https://man.archlinux.org/man/ssh_config.5|Ssh_config (5)]] для полного описания этих опций.
-=== Хранение ключей SSH на аппаратных токенах ===
-[[https://synology-webmastermsk-ru.translate.goog/dokuwiki/doku.php?id=title:file:tango-view-fullscreen&amp;_x_tr_sl=ru&amp;_x_tr_tl=ru&amp;_x_tr_hl=en&amp;_x_tr_pto=nui&amp;_x_tr_sch=http|{{https://translate.google.com/website?sl=ru&amp;tl=ru&amp;nui=1&amp;u=http://synology.webmastermsk.ru/dokuwiki/lib/exe/fetch.php?w%3D48%26h%3D48%26tok%3Df75d99%26media%3Dimages:3:38:tango-view-fullscreen.png?48x48|Танго-просмотр-fullscreen.png}}]]**Эта статья или раздел нуждаются в расширении.** [[https://synology-webmastermsk-ru.translate.goog/dokuwiki/doku.php?id=title:file:tango-view-fullscreen&amp;_x_tr_sl=ru&amp;_x_tr_tl=ru&amp;_x_tr_hl=en&amp;_x_tr_pto=nui&amp;_x_tr_sch=http|{{https://translate.google.com/website?sl=ru&amp;tl=ru&amp;nui=1&amp;u=http://synology.webmastermsk.ru/dokuwiki/lib/exe/fetch.php?w%3D48%26h%3D48%26tok%3Df75d99%26media%3Dimages:3:38:tango-view-fullscreen.png?48x48|Танго-просмотр-fullscreen.png}}]]
-**Причина: в** [[https://translate.google.com/website?sl=ru&amp;tl=ru&amp;nui=1&amp;u=https://www.openssh.com/txt/release-8.2|OpenSSH версии 8.2]] добавлена поддержка резидентных ключей FIDO2, что позволяет хранить ключи SSH на аппаратном токене. (Обсудить в [[https://translate.google.com/website?sl=ru&amp;tl=ru&amp;nui=1&amp;u=https://wiki.archlinux.org/title/Talk:SSH_keys|Обсуждении: ключи SSH]] )
-Ключи SSH также могут храниться на токене безопасности, таком как смарт-карта или USB-токен. Это имеет то преимущество, что закрытый ключ надежно хранится на токене, а не на диске. При использовании токена безопасности конфиденциальный закрытый ключ также никогда не присутствует в оперативной памяти ПК; криптографические операции выполняются с самим токеном. Криптографический токен имеет дополнительное преимущество, заключающееся в том, что он не привязан к одному компьютеру; его можно легко снять с компьютера и носить с собой для использования на других компьютерах.
-Примеры аппаратных токенов описаны в:
-  * [[https://synology-webmastermsk-ru.translate.goog/dokuwiki/doku.php?id=title:yubikey&amp;_x_tr_sl=ru&amp;_x_tr_tl=ru&amp;_x_tr_hl=en&amp;_x_tr_pto=nui&amp;_x_tr_sch=http#ssh_notes|YubiKey # SSH отмечает встроенную]] поддержку OpenSSH для ключей FIDO / U2F
-  * [[https://synology-webmastermsk-ru.translate.goog/dokuwiki/doku.php?id=title:yubikey&amp;_x_tr_sl=ru&amp;_x_tr_tl=ru&amp;_x_tr_hl=en&amp;_x_tr_pto=nui&amp;_x_tr_sch=http#ssh_keys|YubiKey # SSH ключи]]
-  * [[https://synology-webmastermsk-ru.translate.goog/dokuwiki/doku.php?id=title:trusted_platform_module&amp;_x_tr_sl=ru&amp;_x_tr_tl=ru&amp;_x_tr_hl=en&amp;_x_tr_pto=nui&amp;_x_tr_sch=http#securing_ssh_keys|Модуль доверенной платформы # Защита ключей SSH]]
-===== Копирование открытого ключа на удаленный сервер =====
-[[https://synology-webmastermsk-ru.translate.goog/dokuwiki/doku.php?id=title:file:tango-view-fullscreen&amp;_x_tr_sl=ru&amp;_x_tr_tl=ru&amp;_x_tr_hl=en&amp;_x_tr_pto=nui&amp;_x_tr_sch=http|{{https://translate.google.com/website?sl=ru&amp;tl=ru&amp;nui=1&amp;u=http://synology.webmastermsk.ru/dokuwiki/lib/exe/fetch.php?w%3D48%26h%3D48%26tok%3Df75d99%26media%3Dimages:3:38:tango-view-fullscreen.png?48x48|Танго-просмотр-fullscreen.png}}]]**Эта статья или раздел нуждаются в расширении.** [[https://synology-webmastermsk-ru.translate.goog/dokuwiki/doku.php?id=title:file:tango-view-fullscreen&amp;_x_tr_sl=ru&amp;_x_tr_tl=ru&amp;_x_tr_hl=en&amp;_x_tr_pto=nui&amp;_x_tr_sch=http|{{https://translate.google.com/website?sl=ru&amp;tl=ru&amp;nui=1&amp;u=http://synology.webmastermsk.ru/dokuwiki/lib/exe/fetch.php?w%3D48%26h%3D48%26tok%3Df75d99%26media%3Dimages:3:38:tango-view-fullscreen.png?48x48|Танго-просмотр-fullscreen.png}}]]
-**Причина:** как это сделать, если вы [[https://synology-webmastermsk-ru.translate.goog/dokuwiki/doku.php?id=title:openssh&amp;_x_tr_sl=ru&amp;_x_tr_tl=ru&amp;_x_tr_hl=en&amp;_x_tr_pto=nui&amp;_x_tr_sch=http#force_public_key_authentication|принудительно используете аутентификацию с открытым ключом]] ? (Обсудить в [[https://translate.google.com/website?sl=ru&amp;tl=ru&amp;nui=1&amp;u=https://wiki.archlinux.org/title/Talk:SSH_keys|Обсуждении: ключи SSH]] )
-После того, как вы сгенерировали пару ключей, вам нужно будет скопировать открытый ключ на удаленный сервер, чтобы он использовал аутентификацию по ключу SSH. Файл открытого ключа имеет то же имя, что и закрытый ключ, за исключением того, что к нему добавлено ''.pub''расширение. Обратите внимание, что закрытый ключ не является общим и остается на локальном компьютере.
-==== Простой метод ====
-**Примечание.** Этот метод может не сработать, если удаленный сервер использует не- ''sh''оболочку, например ''tcsh''по умолчанию, и использует OpenSSH старше 6.6.1p1. См. [[https://translate.google.com/website?sl=ru&amp;tl=ru&amp;nui=1&amp;u=https://bugzilla.redhat.com/show_bug.cgi?id%3D1045191|Этот отчет об ошибке]] .
-Если ваш ключевой файл, ''~/.ssh/id_rsa.pub''вы можете просто ввести следующую команду.
-<code>
-$ ssh-copy-id remote-server.org
-</code>
-Если ваше имя пользователя на удаленном компьютере отличается, не забудьте добавить имя пользователя, за которым ''@''следует, перед именем сервера.
-<code>
-$ ssh-copy-id username@remote-server.org
-</code>
-Если ваше имя файла открытого ключа отличается от значения по умолчанию, ''~/.ssh/id_rsa.pub''вы получите сообщение об ошибке ''/usr/bin/ssh-copy-id: ERROR: No identities found''. В этом случае вы должны явно указать расположение открытого ключа.
-<code>
-$ ssh-copy-id -i ~ / .ssh / id_ed25519.pub имя пользователя@remote-server.org
-</code>
-Если ssh-сервер прослушивает порт, отличный от порта по умолчанию 22, обязательно укажите его в аргументе host.
-<code>
-$ ssh-copy-id -i ~ / .ssh / id_ed25519.pub -p 221 имя пользователя@remote-server.org
-</code>
-==== Ручной метод ====
-По умолчанию для OpenSSH открытый ключ необходимо объединить с ''~/.ssh/authorized_keys''. Начните с копирования открытого ключа на удаленный сервер.
-<code>
-$ scp ~ / .ssh / id_ecdsa.pub имя пользователя@remote-server.org:
-</code>
-В приведенном выше примере открытый ключ ( ''id_ecdsa.pub'') копируется в ваш домашний каталог на удаленном сервере через ''scp''. Не забудьте поставить '':''точку в конце адреса сервера. Также обратите внимание, что имя вашего открытого ключа может отличаться от приведенного в примере.
-На удаленном сервере вам нужно будет создать ''~/.ssh''каталог, если он еще не существует, и добавить свой открытый ключ в ''authorized_keys''файл.
-<code>
-$ 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
-</code>
-Последние две команды удаляют файл открытого ключа с сервера и устанавливают разрешения для ''authorized_keys''файла так, чтобы он был доступен для чтения и записи только вам, владельцу.
-===== Агенты SSH =====
-Если ваш закрытый ключ зашифрован парольной фразой, эту парольную фразу необходимо вводить каждый раз, когда вы пытаетесь подключиться к SSH-серверу с использованием аутентификации с открытым ключом. Каждый отдельный вызов ''ssh''или ''scp''будет нуждаться в парольной фразе, чтобы расшифровать ваш закрытый ключ перед тем, как можно будет продолжить аутентификацию.
-Агент SSH - это программа, которая кэширует ваши расшифрованные закрытые ключи и предоставляет их клиентским программам SSH от вашего имени. В этом случае вы должны указать свою парольную фразу только один раз, добавляя свой закрытый ключ в кэш агента. Это средство может быть очень удобным при частом подключении по SSH.
-Агент обычно настроен на автоматический запуск при входе в систему и сохранение в течение всего сеанса входа в систему. Для достижения этого эффекта существует множество агентов, интерфейсов и конфигураций. В этом разделе представлен обзор ряда различных решений, которые можно адаптировать к вашим конкретным потребностям.
-==== ssh-агент ====
-''ssh-agent''агент по умолчанию, включенный в OpenSSH. Его можно использовать напрямую или в качестве серверной части для некоторых интерфейсных решений, упомянутых далее в этом разделе. При ''ssh-agent''запуске он переходит в фоновый режим и печатает необходимые переменные среды. Например
-<code>
-$ ssh-агент
-</code>
-<code>
-SSH_AUTH_SOCK = / tmp / ssh-vEGjCM2147 / agent.2147; экспорт SSH_AUTH_SOCK;
-SSH_AGENT_PID = 2148; экспорт SSH_AGENT_PID;
-echo Agent pid 2148;
-</code>
-Чтобы использовать эти переменные, запустите команду через ''eval''команду.
-<code>
-$ eval $ (ssh-агент)
-</code>
-<code>
-Агент пид 2157
-</code>
-После ''ssh-agent''запуска вам нужно будет добавить свой закрытый ключ в его кеш:
-<code>
-$ ssh-add ~ / .ssh / id_ed25519
-</code>
-<code>
-Введите кодовую фразу для /home/user/.ssh/id_ed25519:
-Идентификация добавлена: /home/user/.ssh/id_ed25519 (/home/user/.ssh/id_ed25519)
-</code>
-Если ваш закрытый ключ зашифрован, ''ssh-add''вам будет предложено ввести кодовую фразу. После того, как ваш закрытый ключ будет успешно добавлен к агенту, вы сможете устанавливать SSH-соединения без необходимости вводить парольную фразу.
-**Совет:** чтобы все ''ssh''клиенты, включая ''git''ключи хранилища в агенте при первом использовании, добавили параметр конфигурации ''AddKeysToAgent yes''в ''~/.ssh/config''. Другие возможные значения ''confirm'', ''ask''и ''no''( по умолчанию).
-Чтобы агент запускался автоматически и был уверен, что одновременно ''ssh-agent''выполняется только один процесс, добавьте в свой ''~/.bashrc'':
-<code>
-если ! 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
-быть
-</code>
-Это запустит ''ssh-agent''процесс, если его еще нет, и сохранит его вывод. Если он уже запущен, мы получаем кэшированный ''ssh-agent''вывод и оцениваем его, который устанавливает необходимые переменные среды. Срок службы разблокированных ключей составляет 1 час.
-Также существует ряд внешних ''ssh-agent''и альтернативных агентов, описанных далее в этом разделе, которые позволяют избежать этой проблемы.
-=== Запустите ssh-agent с пользователем systemd ===
-Для запуска агента можно использовать средства [[https://synology-webmastermsk-ru.translate.goog/dokuwiki/doku.php?id=title:systemd:user&amp;_x_tr_sl=ru&amp;_x_tr_tl=ru&amp;_x_tr_hl=en&amp;_x_tr_pto=nui&amp;_x_tr_sch=http|systemd / User]] . Используйте это, если вы хотите, чтобы ваш агент ssh запускался, когда вы вошли в систему, независимо от того, запущен ли x.
-<code>
-~ / .config / systemd / пользователь / ssh-agent.service
-</code>
-<code>
-[Ед. изм]
-Описание = ключевой агент SSH
-[Услуга]
-Тип = простой
-Среда = SSH_AUTH_SOCK =% t / ssh-agent.socket
-# ДИСПЛЕЙ необходим для работы ssh-askpass
-Окружающая среда = ДИСПЛЕЙ =: 0
-ExecStart = / usr / bin / ssh-agent -D -a $ SSH_AUTH_SOCK
-[Установить]
-WantedBy = default.target
-</code>
-Затем экспортировать в [[https://synology-webmastermsk-ru.translate.goog/dokuwiki/doku.php?id=title:environment_variable&amp;_x_tr_sl=ru&amp;_x_tr_tl=ru&amp;_x_tr_hl=en&amp;_x_tr_pto=nui&amp;_x_tr_sch=http|переменную окружения]] ''SSH_AUTH_SOCK=«$XDG_RUNTIME_DIR/ssh-agent.socket»'' в вашей [[https://synology-webmastermsk-ru.translate.goog/dokuwiki/doku.php?id=title:login_shell&amp;_x_tr_sl=ru&amp;_x_tr_tl=ru&amp;_x_tr_hl=en&amp;_x_tr_pto=nui&amp;_x_tr_sch=http|авторизации оболочки]] файл инициализации, например, ''~/.bash_profile''или ''~/.zprofile''.
-Наконец, [[https://synology-webmastermsk-ru.translate.goog/dokuwiki/doku.php?id=title:enable&amp;_x_tr_sl=ru&amp;_x_tr_tl=ru&amp;_x_tr_hl=en&amp;_x_tr_pto=nui&amp;_x_tr_sch=http|включите]] службу или [[https://synology-webmastermsk-ru.translate.goog/dokuwiki/doku.php?id=title:enable&amp;_x_tr_sl=ru&amp;_x_tr_tl=ru&amp;_x_tr_hl=en&amp;_x_tr_pto=nui&amp;_x_tr_sch=http|присвойте ей]] [[https://synology-webmastermsk-ru.translate.goog/dokuwiki/doku.php?id=title:start&amp;_x_tr_sl=ru&amp;_x_tr_tl=ru&amp;_x_tr_hl=en&amp;_x_tr_pto=nui&amp;_x_tr_sch=http|название]] с ''--user''флагом.
-**Примечание:**
-  * Если вы используете GNOME, эта переменная среды по умолчанию переопределяется. См. [[https://synology-webmastermsk-ru.translate.goog/dokuwiki/doku.php?id=title:gnome:keyring&amp;_x_tr_sl=ru&amp;_x_tr_tl=ru&amp;_x_tr_hl=en&amp;_x_tr_pto=nui&amp;_x_tr_sch=http#disable_keyring_daemon_components|GNOME / Keyring # Отключение компонентов демона связки ключей]] .
-  * Убедитесь, что не перезаписали существующий, ''SSH_AUTH_SOCK''если вы хотите использовать [[https://synology-webmastermsk-ru.translate.goog/dokuwiki/doku.php?id=title:openssh&amp;_x_tr_sl=ru&amp;_x_tr_tl=ru&amp;_x_tr_hl=en&amp;_x_tr_pto=nui&amp;_x_tr_sch=http#agent_forwarding|перенаправленный агент ssh]] .
-**Совет:** при запуске агента через systemd, как описано выше, можно автоматически ввести парольную фразу вашего ключа по умолчанию и добавить ее к агенту. См. [[https://translate.google.com/website?sl=ru&amp;tl=ru&amp;nui=1&amp;u=https://github.com/capocasa/systemd-user-pam-ssh|Systemd-user-pam-ssh]] для подробностей.
-=== ssh-agent как программа-оболочка ===
-Альтернативный способ запуска ssh-agent (скажем, с каждым X-сеансом) описан в [[https://translate.google.com/website?sl=ru&amp;tl=ru&amp;nui=1&amp;u=https://upc.lbl.gov/docs/user/sshagent.shtml|этом руководстве по ssh-agent от UC Berkeley Labs]] . Базовый вариант использования - если вы обычно начинаете X с ''startx''команды, вы можете вместо этого префиксировать ее ''ssh-agent''следующим образом:
-<code>
-$ ssh-agent startx
-</code>
-И поэтому вам даже не нужно об этом думать, вы можете поместить псевдоним в свой ''.bash_aliases''файл или эквивалент:
-<code>
-псевдоним startx = 'ssh-agent startx'
-</code>
-Это позволяет избежать проблемы наличия посторонних ''ssh-agent''экземпляров, перемещающихся между сеансами входа в систему. Ровно один экземпляр будет жить и умереть за весь сеанс X.
-**Примечание.** В качестве альтернативы звонку ''ssh-agent startx''вы можете добавить ''eval $(ssh-agent)''в ''~/.xinitrc''.
-См. [[https://synology-webmastermsk-ru.translate.goog/dokuwiki/doku.php?_x_tr_sl=ru&amp;_x_tr_tl=ru&amp;_x_tr_hl=en&amp;_x_tr_pto=nui&amp;_x_tr_sch=http#calling_x11-ssh-askpass_with_ssh-add|Нижеприведенные примечания по использованию x11-ssh-askpass с ssh-add,]] чтобы узнать, как сразу добавить свой ключ к агенту.
-==== Агент GnuPG ====
-В [[https://synology-webmastermsk-ru.translate.goog/dokuwiki/doku.php?id=title:gnupg&amp;_x_tr_sl=ru&amp;_x_tr_tl=ru&amp;_x_tr_hl=en&amp;_x_tr_pto=nui&amp;_x_tr_sch=http#gpg-agent|gpg-agent]] есть эмуляция протокола OpenSSH Agent. См. Необходимую конфигурацию в [[https://synology-webmastermsk-ru.translate.goog/dokuwiki/doku.php?id=title:gnupg&amp;_x_tr_sl=ru&amp;_x_tr_tl=ru&amp;_x_tr_hl=en&amp;_x_tr_pto=nui&amp;_x_tr_sch=http#ssh_agent|GnuPG # SSH agent]] .
-==== Брелок ====
-[[https://translate.google.com/website?sl=ru&amp;tl=ru&amp;nui=1&amp;u=https://www.funtoo.org/Keychain|Связка ключей]] - это программа, разработанная, чтобы помочь вам легко управлять своими ключами SSH с минимальным вмешательством пользователя. Он реализован как сценарий оболочки, который управляет как ssh-agent, так и ssh-add . Примечательной особенностью Keychain является то, что он может поддерживать один процесс ssh-agent в течение нескольких сеансов входа в систему. Это означает, что вам нужно вводить кодовую фразу только один раз при каждой загрузке вашего локального компьютера.
-=== Установка ===
-[[https://synology-webmastermsk-ru.translate.goog/dokuwiki/doku.php?id=title:install&amp;_x_tr_sl=ru&amp;_x_tr_tl=ru&amp;_x_tr_hl=en&amp;_x_tr_pto=nui&amp;_x_tr_sch=http|Установите]] на [[https://translate.google.com/website?sl=ru&amp;tl=ru&amp;nui=1&amp;u=https://archlinux.org/packages/?name%3Dkeychain|брелка]] пакет.
-=== Конфигурация ===
-**Предупреждение: по** состоянию на 26 сентября 2015 г. у этой ''-Q, --quick''опции есть неожиданный побочный эффект, заключающийся в переключении связки ключей на вновь созданный ssh-агент при повторном входе (по крайней мере, в системах, использующих [[https://synology-webmastermsk-ru.translate.goog/dokuwiki/doku.php?id=title:gnome&amp;_x_tr_sl=ru&amp;_x_tr_tl=ru&amp;_x_tr_hl=en&amp;_x_tr_pto=nui&amp;_x_tr_sch=http|GNOME]] ), что вынуждает вас повторно добавлять все предыдущие зарегистрированные ключи.
-Добавьте в файл конфигурации [[https://synology-webmastermsk-ru.translate.goog/dokuwiki/doku.php?id=title:shell&amp;_x_tr_sl=ru&amp;_x_tr_tl=ru&amp;_x_tr_hl=en&amp;_x_tr_pto=nui&amp;_x_tr_sch=http|оболочки]] строку, подобную следующей , например, при использовании [[https://synology-webmastermsk-ru.translate.goog/dokuwiki/doku.php?id=title:bash&amp;_x_tr_sl=ru&amp;_x_tr_tl=ru&amp;_x_tr_hl=en&amp;_x_tr_pto=nui&amp;_x_tr_sch=http|Bash]] :
-<code>
-~ / .bashrc
-</code>
-<code>
-eval $ (связка ключей --eval --quiet id_ed25519 id_rsa ~ / .keys / my_custom_key)
-</code>
-**Примечание:** ''~/.bashrc'' используется вместо предлагаемого восходящего потока, ''~/.bash_profile''потому что в Arch он исходит как из оболочки входа, так и из оболочки, не входящей в систему, что делает его подходящим как для текстовой, так и для графической среды. См. [[https://synology-webmastermsk-ru.translate.goog/dokuwiki/doku.php?id=title:bash&amp;_x_tr_sl=ru&amp;_x_tr_tl=ru&amp;_x_tr_hl=en&amp;_x_tr_pto=nui&amp;_x_tr_sch=http#invocation|Bash # Invocation]] для получения дополнительной информации о различиях между ними.
-В приведенном выше примере
-  * в ''--eval''коммутационных выходов линии , которые будут оценены открытия ''eval''команды; это устанавливает необходимые переменные среды, чтобы клиент SSH мог найти ваш агент.
-  * ''--quiet'' ограничит вывод предупреждениями, ошибками и подсказками пользователя.
-В командной строке можно указать несколько ключей, как показано в примере. По умолчанию связка ключей будет искать пары ключей в ''~/.ssh/''каталоге, но для ключей в нестандартном месте можно использовать абсолютный путь. Вы также можете использовать ''--confhost''опцию для информирования брелки посмотреть в ''~/.ssh/config''для ''IdentityFile''настройки определенной для конкретных хостов, и использовать эти пути , чтобы найти ключи.
-См. ''keychain --help''Или [[https://translate.google.com/website?sl=ru&amp;tl=ru&amp;nui=1&amp;u=https://man.archlinux.org/man/keychain.1|keychain (1)]] для получения подробной информации о настройке связки ключей для других оболочек.
-Чтобы протестировать Связку ключей, просто откройте новый эмулятор терминала или выйдите из системы и вернитесь в сеанс. Он должен запросить у вас кодовую фразу для указанного закрытого ключа (ов) (если применимо), либо с помощью программы, установленной в ''$SSH_ASKPASS''терминале, либо на терминале.
-Поскольку Keychain повторно использует один и тот же процесс ssh-agent при последующих входах в систему, вам не придется вводить кодовую фразу при следующем входе в систему или открытии нового терминала. Вам будет предложено ввести кодовую фразу только один раз при каждой перезагрузке машины.
-=== подсказки ===
-  * keychain ожидает, что файлы открытых ключей будут существовать в том же каталоге, что и их частные копии, с ''.pub''расширением. Если закрытый ключ является символической ссылкой, открытый ключ можно найти рядом с символической ссылкой или в том же каталоге, что и цель символической ссылки (эта возможность требует, чтобы ''readlink''команда была доступна в системе).
-  * чтобы отключить графическую подсказку и всегда вводить парольную фразу на терминале, используйте эту ''--nogui''опцию. Это позволяет, например, скопировать длинные парольные фразы из диспетчера паролей.
-  * Если вы не хотите, чтобы вам сразу предлагалось разблокировать ключи, а лучше подождать, пока они потребуются, используйте эту ''--noask''опцию.
-**Примечание.** Связка ключей может управлять ключами [[https://synology-webmastermsk-ru.translate.goog/dokuwiki/doku.php?id=title:gpg&amp;_x_tr_sl=ru&amp;_x_tr_tl=ru&amp;_x_tr_hl=en&amp;_x_tr_pto=nui&amp;_x_tr_sch=http|GPG]] таким же образом. По умолчанию он пытается запустить только ssh-agent , но вы можете изменить это поведение с помощью ''--agents''опции, например ''--agents ssh,gpg'' . См. [[https://translate.google.com/website?sl=ru&amp;tl=ru&amp;nui=1&amp;u=https://man.archlinux.org/man/keychain.1|Брелок (1)]] .
-==== x11-ssh-askpass ====
-Пакет [[https://translate.google.com/website?sl=ru&amp;tl=ru&amp;nui=1&amp;u=https://archlinux.org/packages/?name%3Dx11-ssh-askpass|x11-ssh-askpass]] предоставляет графический диалог для ввода пароля при запуске X-сеанса. x11-ssh-askpass зависит только от библиотек [[https://translate.google.com/website?sl=ru&amp;tl=ru&amp;nui=1&amp;u=https://archlinux.org/packages/?name%3Dlibx11|libx11]] и [[https://translate.google.com/website?sl=ru&amp;tl=ru&amp;nui=1&amp;u=https://archlinux.org/packages/?name%3Dlibxt|libxt]] , а внешний вид x11-ssh-askpass настраивается. Хотя он может быть вызван программой ssh-add , которая затем загрузит ваши расшифрованные ключи в [[https://synology-webmastermsk-ru.translate.goog/dokuwiki/doku.php?_x_tr_sl=ru&amp;_x_tr_tl=ru&amp;_x_tr_hl=en&amp;_x_tr_pto=nui&amp;_x_tr_sch=http#ssh-agent|ssh-agent]] , следующие инструкции вместо этого настроят x11-ssh-askpass для вызова вышеупомянутым сценарием [[https://synology-webmastermsk-ru.translate.goog/dokuwiki/doku.php?_x_tr_sl=ru&amp;_x_tr_tl=ru&amp;_x_tr_hl=en&amp;_x_tr_pto=nui&amp;_x_tr_sch=http#keychain|Keychain]] .
-Установите [[https://translate.google.com/website?sl=ru&amp;tl=ru&amp;nui=1&amp;u=https://archlinux.org/packages/?name%3Dx11-ssh-askpass|связку]] [[https://translate.google.com/website?sl=ru&amp;tl=ru&amp;nui=1&amp;u=https://archlinux.org/packages/?name%3Dkeychain|ключей]] и пакеты [[https://translate.google.com/website?sl=ru&amp;tl=ru&amp;nui=1&amp;u=https://archlinux.org/packages/?name%3Dx11-ssh-askpass|x11-ssh-askpass]] .
-Отредактируйте ''~/.xinitrc''файл, включив в него следующие строки, при необходимости заменив имя и расположение вашего закрытого ключа. Обязательно поместите эти команды **перед** строкой, вызывающей ваш оконный менеджер.
-<code>
-~ / .xinitrc
-</code>
-<code>
-брелок ~ / .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
-</code>
-В приведенном выше примере первая строка вызывает цепочку ключей и передает имя и расположение вашего закрытого ключа. Если это не первый раз, когда связка ключей вызывается, следующие две строки загружают содержимое ''$HOSTNAME-sh''и ''$HOSTNAME-sh-gpg'', если они существуют. В этих файлах хранятся переменные среды предыдущего экземпляра связки ключей .
-=== Вызов x11-ssh-askpass с помощью ssh-add ===
-На странице руководства ssh-add указано, что помимо необходимости ''DISPLAY''определения переменной вам также необходимо ''SSH_ASKPASS''указать имя вашей программы askpass (в данном случае x11-ssh-askpass ). Следует иметь в виду, что установка Arch Linux по умолчанию помещает двоичный файл x11-ssh-askpass''/usr/lib/ssh/'' , чего не будет у большинства людей ''PATH''. Это немного раздражает не только при объявлении ''SSH_ASKPASS''переменной, но и при создании тем. Вы должны везде указывать полный путь. Оба неудобства можно решить одновременно, установив символическую ссылку:
-<code>
-$ ln -sv /usr/lib/ssh/x11-ssh-askpass ~/bin/ssh-askpass
-</code>
-Предполагается, что это ''~/bin''находится в вашем ''PATH''. Итак, теперь ''.xinitrc''перед вызовом оконного менеджера вам нужно просто экспортировать ''SSH_ASKPASS''переменную окружения:
-<code>
-$ export SSH_ASKPASS = ssh-askpass
-</code>
-и ваши [[https://synology-webmastermsk-ru.translate.goog/dokuwiki/doku.php?id=title:x_resources&amp;_x_tr_sl=ru&amp;_x_tr_tl=ru&amp;_x_tr_hl=en&amp;_x_tr_pto=nui&amp;_x_tr_sch=http|ресурсы X]] будут содержать что-то вроде:
-<code>
-ssh-askpass * фон: # 000000
-</code>
-Такой способ хорошо работает с [[https://synology-webmastermsk-ru.translate.goog/dokuwiki/doku.php?_x_tr_sl=ru&amp;_x_tr_tl=ru&amp;_x_tr_hl=en&amp;_x_tr_pto=nui&amp;_x_tr_sch=http#ssh-agent_as_a_wrapper_program|описанным выше методом использования]] [[https://synology-webmastermsk-ru.translate.goog/dokuwiki/doku.php?_x_tr_sl=ru&amp;_x_tr_tl=ru&amp;_x_tr_hl=en&amp;_x_tr_pto=nui&amp;_x_tr_sch=http#ssh-agent_as_a_wrapper_program|ssh-agent]] [[https://synology-webmastermsk-ru.translate.goog/dokuwiki/doku.php?_x_tr_sl=ru&amp;_x_tr_tl=ru&amp;_x_tr_hl=en&amp;_x_tr_pto=nui&amp;_x_tr_sch=http#ssh-agent_as_a_wrapper_program|в качестве программы-оболочки]] . Вы запускаете X с помощью, ''ssh-agent startx''а затем добавляете ssh-add в список запускаемых программ вашего оконного менеджера.
-=== Тематика ===
-Появление x11-SSH-askpass диалоге можно настроить , связанные с ним [[https://synology-webmastermsk-ru.translate.goog/dokuwiki/doku.php?id=title:x_resources&amp;_x_tr_sl=ru&amp;_x_tr_tl=ru&amp;_x_tr_hl=en&amp;_x_tr_pto=nui&amp;_x_tr_sch=http|X ресурсов]] . Некоторыми примерами являются файлы .ad по адресу [[https://translate.google.com/website?sl=ru&amp;tl=ru&amp;nui=1&amp;u=https://github.com/sigmavirus24/x11-ssh-askpass|https://github.com/sigmavirus24/x11-ssh-askpass]] . См. [[https://translate.google.com/website?sl=ru&amp;tl=ru&amp;nui=1&amp;u=https://man.archlinux.org/man/x11-ssh-askpass.1|X11-ssh-askpass (1)]] для получения полной информации.
-=== Альтернативные диалоги парольной фразы ===
-Существуют и другие программы диалога с паролями, которые можно использовать вместо x11-ssh-askpass . В следующем списке представлены некоторые альтернативные решения.
-  * [[https://translate.google.com/website?sl=ru&amp;tl=ru&amp;nui=1&amp;u=https://archlinux.org/packages/?name%3Dksshaskpass|ksshaskpass]] использует [[https://synology-webmastermsk-ru.translate.goog/dokuwiki/doku.php?id=title:kde_wallet&amp;_x_tr_sl=ru&amp;_x_tr_tl=ru&amp;_x_tr_hl=en&amp;_x_tr_pto=nui&amp;_x_tr_sch=http|кошелек KDE]] .
-  * [[https://translate.google.com/website?sl=ru&amp;tl=ru&amp;nui=1&amp;u=https://archlinux.org/packages/?name%3Dopenssh-askpass|openssh-askpass]] использует библиотеку [[https://synology-webmastermsk-ru.translate.goog/dokuwiki/doku.php?id=title:qt&amp;_x_tr_sl=ru&amp;_x_tr_tl=ru&amp;_x_tr_hl=en&amp;_x_tr_pto=nui&amp;_x_tr_sch=http|Qt]] .
-  * [[https://translate.google.com/website?sl=ru&amp;tl=ru&amp;nui=1&amp;u=https://archlinux.org/packages/?name%3Dlxqt-openssh-askpass|lxqt-openssh-askpass]]
-==== pam_ssh ====
-Проект [[https://translate.google.com/website?sl=ru&amp;tl=ru&amp;nui=1&amp;u=http://pam-ssh.sourceforge.net/|pam_ssh]] существует для предоставления [[https://synology-webmastermsk-ru.translate.goog/dokuwiki/doku.php?id=title:pluggable_authentication_module&amp;_x_tr_sl=ru&amp;_x_tr_tl=ru&amp;_x_tr_hl=en&amp;_x_tr_pto=nui&amp;_x_tr_sch=http|подключаемого модуля аутентификации]] (PAM) для закрытых ключей SSH. Этот модуль может обеспечивать единый вход для ваших SSH-подключений. При входе в систему можно ввести парольную фразу закрытого ключа SSH вместо традиционного системного пароля или в дополнение к нему. После того, как вы прошли аутентификацию, модуль pam_ssh запускает ssh-agent для хранения вашего расшифрованного закрытого ключа на время сеанса.
-Чтобы включить режим единого входа в приглашении входа на tty, установите неофициальный [[https://translate.google.com/website?sl=ru&amp;tl=ru&amp;nui=1&amp;u=https://aur.archlinux.org/packages/pam_ssh/|пакет]] <sup>AUR</sup> [[https://translate.google.com/website?sl=ru&amp;tl=ru&amp;nui=1&amp;u=https://aur.archlinux.org/packages/pam_ssh/|pam_ssh]] .
-**Примечание:** pam_ssh 2.0 теперь требует, чтобы все закрытые ключи, используемые в процессе аутентификации, находились в папке ''~/.ssh/login-keys.d/''.
-Создайте символическую ссылку на свой файл закрытого ключа и поместите его в ''~/.ssh/login-keys.d/''. Замените ''id_rsa''в приведенном ниже примере имя вашего собственного файла закрытого ключа.
-<code>
-$ mkdir ~ / .ssh / ключи входа в систему.d /
-$ cd ~ / .ssh / ключи входа в систему.d /
-$ ln -s ../id_rsa
-</code>
-Отредактируйте ''/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 [[https://translate.google.com/website?sl=ru&amp;tl=ru&amp;nui=1&amp;u=https://developer.ibm.com/tutorials/l-pam/|article]] is available which explains PAM configuration in further detail.
-<code>
-/etc/pam.d/login
-</code>
-<code>
-#%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
-</code>
-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 [[https://synology-webmastermsk-ru.translate.goog/dokuwiki/doku.php?id=title:slim&amp;_x_tr_sl=ru&amp;_x_tr_tl=ru&amp;_x_tr_hl=en&amp;_x_tr_pto=nui&amp;_x_tr_sch=http|SLiM]] or [[https://synology-webmastermsk-ru.translate.goog/dokuwiki/doku.php?id=title:xdm&amp;_x_tr_sl=ru&amp;_x_tr_tl=ru&amp;_x_tr_hl=en&amp;_x_tr_pto=nui&amp;_x_tr_sch=http|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.
-=== Using a different password to unlock the SSH key ===
-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
-<code>
-/etc/pam.d/system-auth
-</code>
-<code>
-#%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
-</code>
-For an explanation, see [[https://translate.google.com/website?sl=ru&amp;tl=ru&amp;nui=1&amp;u=https://unix.stackexchange.com/a/239486|[7]]].
-=== Known issues with pam_ssh ===
-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 [[https://synology-webmastermsk-ru.translate.goog/dokuwiki/doku.php?id=title:gnu_screen&amp;_x_tr_sl=ru&amp;_x_tr_tl=ru&amp;_x_tr_hl=en&amp;_x_tr_pto=nui&amp;_x_tr_sch=http|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 [[https://synology-webmastermsk-ru.translate.goog/dokuwiki/doku.php?_x_tr_sl=ru&amp;_x_tr_tl=ru&amp;_x_tr_hl=en&amp;_x_tr_pto=nui&amp;_x_tr_sch=http#keychain|Keychain]] front-end avoids this problem by keeping the ssh-agent process alive between logins.
-==== pam_exec-ssh ====
-As an alternative to [[https://synology-webmastermsk-ru.translate.goog/dokuwiki/doku.php?_x_tr_sl=ru&amp;_x_tr_tl=ru&amp;_x_tr_hl=en&amp;_x_tr_pto=nui&amp;_x_tr_sch=http#pam_ssh|pam_ssh]] you can use [[https://translate.google.com/website?sl=ru&amp;tl=ru&amp;nui=1&amp;u=https://aur.archlinux.org/packages/pam_exec-ssh/|pam_exec-ssh]]<sup>AUR</sup> . It is a shell script that uses pam_exec. Help for configuration can be found [[https://translate.google.com/website?sl=ru&amp;tl=ru&amp;nui=1&amp;u=https://github.com/x70b1/pam_exec-ssh|upstream]].
-==== GNOME Keyring ====
-If you use the [[https://synology-webmastermsk-ru.translate.goog/dokuwiki/doku.php?id=title:gnome&amp;_x_tr_sl=ru&amp;_x_tr_tl=ru&amp;_x_tr_hl=en&amp;_x_tr_pto=nui&amp;_x_tr_sch=http|GNOME]] desktop, the [[https://synology-webmastermsk-ru.translate.goog/dokuwiki/doku.php?id=title:gnome_keyring&amp;_x_tr_sl=ru&amp;_x_tr_tl=ru&amp;_x_tr_hl=en&amp;_x_tr_pto=nui&amp;_x_tr_sch=http|GNOME Keyring]] tool can be used as an SSH agent. See the [[https://synology-webmastermsk-ru.translate.goog/dokuwiki/doku.php?id=title:gnome_keyring&amp;_x_tr_sl=ru&amp;_x_tr_tl=ru&amp;_x_tr_hl=en&amp;_x_tr_pto=nui&amp;_x_tr_sch=http|GNOME Keyring]] article for further details.
-==== Store SSH keys with Kwallet ====
-For instructions on how to use kwallet to store your SSH keys, see [[https://synology-webmastermsk-ru.translate.goog/dokuwiki/doku.php?id=title:kde_wallet&amp;_x_tr_sl=ru&amp;_x_tr_tl=ru&amp;_x_tr_hl=en&amp;_x_tr_pto=nui&amp;_x_tr_sch=http#using_the_kde_wallet_to_store_ssh_key_passphrases|KDE Wallet#Using the KDE Wallet to store ssh key passphrases]].
-==== KeePass2 with KeeAgent plugin ====
-[[https://translate.google.com/website?sl=ru&amp;tl=ru&amp;nui=1&amp;u=https://lechnology.com/software/keeagent/|KeeAgent]] is a plugin for [[https://synology-webmastermsk-ru.translate.goog/dokuwiki/doku.php?id=title:keepass&amp;_x_tr_sl=ru&amp;_x_tr_tl=ru&amp;_x_tr_hl=en&amp;_x_tr_pto=nui&amp;_x_tr_sch=http|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 [[https://synology-webmastermsk-ru.translate.goog/dokuwiki/doku.php?id=title:keepass&amp;_x_tr_sl=ru&amp;_x_tr_tl=ru&amp;_x_tr_hl=en&amp;_x_tr_pto=nui&amp;_x_tr_sch=http#plugin_installation_in_keepass|KeePass#Plugin installation in KeePass]] or [[https://synology-webmastermsk-ru.translate.goog/dokuwiki/doku.php?id=title:install&amp;_x_tr_sl=ru&amp;_x_tr_tl=ru&amp;_x_tr_hl=en&amp;_x_tr_pto=nui&amp;_x_tr_sch=http|install]] the [[https://translate.google.com/website?sl=ru&amp;tl=ru&amp;nui=1&amp;u=https://archlinux.org/packages/?name%3Dkeepass-plugin-keeagent|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'''.
-==== KeePassXC ====
-The KeePassXC fork of KeePass [[https://translate.google.com/website?sl=ru&amp;tl=ru&amp;nui=1&amp;u=https://keepassxc.org/docs/%23faq-ssh-agent-how|supports being used as an SSH agent by default]]. It is also compatible with KeeAgent's database format.
-===== Troubleshooting =====
-==== Key ignored by the server ====
-  * 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:
-<code>
-$ chmod 700 ~/.ssh
-$ chmod 600 ~/.ssh/authorized_keys
-</code>
-  * 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):
-<code>
-$ chmod go-w /home/target_user
-</code>
-  * 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 [[https://synology-webmastermsk-ru.translate.goog/dokuwiki/doku.php?_x_tr_sl=ru&amp;_x_tr_tl=ru&amp;_x_tr_hl=en&amp;_x_tr_pto=nui&amp;_x_tr_sch=http#generating_an_ssh_key_pair|#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:
-<code>
-$ ssh -i id_rsa_server user@server
-</code>
-===== A Solution for Existing Repositories =====
-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.
-[[https://translate.google.com/website?sl=ru&amp;tl=ru&amp;nui=1&amp;u=https://careerkarma.com/blog/git-another-process-seems-to-be-running/|» 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://translate.google.com/website?sl=ru&amp;tl=ru&amp;nui=1&amp;u=https://github.com/career-karma-tutorials/ck-git|https://github.com/career-karma-tutorials/ck-git]] (fetch) origin [[https://translate.google.com/website?sl=ru&amp;tl=ru&amp;nui=1&amp;u=https://github.com/career-karma-tutorials/ck-git|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 [[https://translate.google.com/website?sl=ru&amp;tl=ru&amp;nui=1&amp;u=https://careerkarma.com/blog/git-change-remote/|git remote set-url command]]:
-<hljs language-cpp> git remote set-url origin [[https://translate.google.com/website?sl=ru&amp;tl=ru&amp;nui=1&amp;u=https://github.com/career-karma-tutorials/ck-git-tutorials|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); }
-    }
-%%//%%]]>

Инструменты пользователя

Инструменты сайта

Различия

Инструменты страницы