Как создать файл ключей

Обновлено: 21.11.2024

Примечание. Для производственных систем вам потребуется получить SSL-сертификаты в центре сертификации. Дополнительную информацию см. в разделе Использование SSL-безопасности, сертификатов, проверки одноранговых узлов и т. д.

Как создать самосертифицированный SSL-сертификат и файлы открытых/закрытых ключей.

Если вы спешите (и не нуждаетесь в объяснениях), то можете просто пропустить этот раздел.

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

Iguana поддерживает эти два формата PKCS:

Примечание. Iguana не поддерживает формат SSH, определенный в RFC4716, даже если этот формат похож:

В этом разделе показано, как создать файл открытого/закрытого ключа с помощью OpenSSL.

Чтобы сгенерировать файл открытого/закрытого ключа в системе Windows:

У вас должен быть установлен OpenSSL.
Создайте новый каталог на диске C и дайте ему соответствующее имя (например, Test).
Откройте окно командной строки и перейдите в новый каталог. Например:
Введите путь к каталогу установки OpenSSL, а затем алгоритм ключа RSA. Например:
Затем запустите эту команду, чтобы разделить сгенерированный файл на отдельные файлы с закрытым и открытым ключами.

Чтобы сгенерировать файл открытого/закрытого ключа в системе POSIX:

Используйте утилиту ssh-keygen, которая входит в состав большинства систем POSIX.
Создайте новый каталог и дайте ему соответствующее имя (например, Test).
Откройте окно командной строки и перейдите в новый каталог. Например:
Используйте параметр rsa, чтобы создать пару открытых закрытых ключей (используя свой адрес электронной почты в качестве комментария):

Совет. Для Iguana требуются ключи формата PEM. Утилита ssh-keygen недавно была изменена на использование (более безопасного) формата закрытого ключа openssh по умолчанию, тогда как ранее по умолчанию использовался формат PEM. Для создания формата PEM мы добавили к старой команде параметр «-m PEM».

Файлы открытого и закрытого ключей сохраняются в новом каталоге, который вы создали ранее. Пример файла закрытого ключа показан ниже:

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

Примечание. В этом примере параметр 4096 команды openssl genrsa указывает, что сгенерированный ключ имеет длину 4096 бит. Ключ длиной 4096 бит или более считается более безопасным. Более короткий ключ будет менее безопасным, но для его использования потребуется меньше вычислений.

В этом разделе показано, как создать файл самоподписанного сертификата с помощью OpenSSL.

Примечание. Iguana предлагает поддержку совместимых с x509 сертификатов в формате pem, сертификаты не должны быть защищены паролем.

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

У вас должен быть установлен OpenSSL.
Откройте окно командной строки и перейдите в созданный ранее каталог для файла открытого/закрытого ключа. Например:
Введите путь к каталогу установки OpenSSL, а затем алгоритм самозаверяющего сертификата. Например:
Следуйте инструкциям, которые появляются на экране. Например:

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

У вас должен быть установлен OpenSSL.
Откройте окно командной строки и перейдите в созданный ранее каталог для файла открытого/закрытого ключа. Например:
Введите путь к каталогу установки OpenSSL, а затем алгоритм самозаверяющего сертификата. Например:
Следуйте инструкциям, которые появляются на экране. Например:

Файл самоподписанного сертификата создается и сохраняется в каталоге, который вы указали ранее. Пример формата сертификата показан ниже:

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

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

В этих инструкциях используются скриншоты из Windows 7, но в других версиях Windows процесс такой же.

Чтобы сгенерировать файл открытого/закрытого ключа:

Стандартная установка puttygen.exe находится в папке C:\Program Files\PuTTY, но это отдельный исполняемый файл, который можно запускать откуда угодно.

PuTTYgen по умолчанию использует нужный ключ RSA (SSH-2 RSA).

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

Эта страница посвящена версии ssh-keygen для OpenSSH. Информацию о Tectia SSH см. здесь.Если вы хотите сгенерировать ключи для PuTTY, см. PuTTYgen в Windows или PuTTYgen в Linux.

Содержание

Что такое ssh-keygen?

Ssh-keygen — это инструмент для создания новых пар ключей аутентификации для SSH. Такие пары ключей используются для автоматизации входа в систему, единого входа и аутентификации хостов.

Ключи SSH и аутентификация с открытым ключом

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

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

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

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

Самый простой способ сгенерировать пару ключей — запустить ssh-keygen без аргументов. В этом случае он запросит файл для хранения ключей. Вот пример:

Сначала инструмент спросил, где сохранить файл. Ключи SSH для аутентификации пользователя обычно хранятся в каталоге пользователя .ssh в домашнем каталоге. Однако в корпоративных средах расположение часто отличается. Имя файла ключа по умолчанию зависит от алгоритма, в данном случае id_rsa при использовании алгоритма RSA по умолчанию. Это также может быть, например, id_dsa или id_ecdsa .

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

Выбор алгоритма и размера ключа

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

rsa — старый алгоритм, основанный на сложности факторизации больших чисел. Для RSA рекомендуется размер ключа не менее 2048 бит; 4096 бит лучше. RSA устаревает, а в факторинге делаются значительные успехи. Может быть целесообразным выбор другого алгоритма. Вполне возможно, что в обозримом будущем алгоритм RSA станет практически взломанным. Все клиенты SSH поддерживают этот алгоритм.

dsa – старый алгоритм цифровой подписи правительства США. Он основан на сложности вычисления дискретных логарифмов. Обычно с ним используется размер ключа 1024. DSA в исходном виде больше не рекомендуется.

ecdsa – новый алгоритм цифровой подписи, стандартизированный правительством США и использующий эллиптические кривые. Вероятно, это хороший алгоритм для текущих приложений. Поддерживаются только три размера ключа: 256, 384 и 521 (sic!) бит. Мы бы рекомендовали всегда использовать его с 521 битом, так как ключи все еще маленькие и, вероятно, более безопасные, чем ключи меньшего размера (хотя они также должны быть безопасными). Большинство клиентов SSH теперь поддерживают этот алгоритм.

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

Алгоритм выбирается с помощью параметра -t, а размер ключа — с помощью параметра -b. Следующие команды иллюстрируют:

Указание имени файла

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

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

Чтобы использовать аутентификацию с открытым ключом, открытый ключ необходимо скопировать на сервер и установить в файл author_keys. Это удобно сделать с помощью инструмента ssh-copy-id. Вот так:

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

Добавление ключа в агент SSH

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

Дополнительную информацию об использовании и настройке агента SSH см. на странице ssh-agent.

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

Этот инструмент также используется для создания ключей аутентификации хоста. Ключи хоста хранятся в каталоге /etc/ssh/.

Ключи хоста — это обычные пары ключей SSH. Каждый хост может иметь один ключ хоста для каждого алгоритма. Ключи хоста почти всегда хранятся в следующих файлах:

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

Использование сертификатов X.509 для аутентификации хоста

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

Использование собственных сертификатов OpenSSH

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

Однако сертификаты OpenSSH могут быть очень полезны для проверки подлинности сервера и дают те же преимущества, что и стандартные сертификаты X.509. Однако им нужна собственная инфраструктура для выдачи сертификатов. Дополнительную информацию об аутентификации сертификата см. .

Управление ключами требует внимания

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

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

В любой крупной организации практически необходимо использовать решения для управления ключами SSH. Ключи SSH также должны быть перемещены в места, принадлежащие root, с надлежащими процессами подготовки и завершения. Дополнительные сведения см. в разделе, как управлять ключами SSH. Широко используемым инструментом управления ключами SSH для OpenSSH является Universal SSH Key Manager.

Практически все нормативно-правовые акты по кибербезопасности требуют управления тем, кто и к чему имеет доступ. Ключи SSH предоставляют доступ и подпадают под это требование. Это означает, что организации в соответствии с мандатами должны внедрить надлежащие процессы управления ключами. NIST IR 7966 — хорошая отправная точка.

Убедитесь, что случайности достаточно

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

Системы общего назначения

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

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

Многие современные ЦП общего назначения также имеют аппаратные генераторы случайных чисел. Это очень помогает с этой проблемой. Лучше всего собирать некоторую энтропию другими способами, по-прежнему хранить ее в случайном начальном файле и подмешивать некоторую энтропию из аппаратного генератора случайных чисел. Таким образом, даже если один из них каким-то образом скомпрометирован, другой источник случайности должен обеспечить безопасность ключей.

Встраиваемые устройства и Интернет вещей

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

Мы рекомендуем, чтобы такие устройства имели аппаратный генератор случайных чисел.Если у ЦП его нет, его следует встроить в материнскую плату. Стоимость довольно небольшая.

Сводка команд и параметров

Вот краткий обзор наиболее часто используемых параметров инструмента для создания ключей:

-b «Биты» Эта опция указывает количество битов в ключе. Правила, регулирующие вариант использования SSH, могут требовать использования ключа определенной длины. Как правило, 2048 бит считается достаточным для ключей RSA.

-e «Экспорт» Эта опция позволяет переформатировать существующие ключи между форматом файла ключа OpenSSH и форматом, описанным в RFC 4716, «Формат файла открытого ключа SSH».

-p «Изменить парольную фразу» Эта опция позволяет изменить парольную фразу файла закрытого ключа с помощью [-P старая_парольная фраза] и [-N новая_парольная фраза], [-f ключевой файл] .

-i "Input" Когда ssh-keygen требуется для доступа к существующему ключу, эта опция назначает файл.

-f "Файл" Указывает имя файла, в котором будет храниться созданный ключ.

-N "Новый" Предоставляет новую парольную фразу для ключа.

-P "Парольная фраза" Предоставляет (старую) парольную фразу при чтении ключа.

-c "Комментарий" Изменяет комментарий к ключевому файлу.

-p Изменить парольную фразу файла закрытого ключа.

-q Отключить ssh-keygen.

-v Подробный режим.

-l "Fingerprint" Напечатать отпечаток указанного открытого ключа.

-B "Bubble babble" Показывает отпечаток ключевого файла в виде "пузыря" (формат Tectia).

-F Поиск указанного имени хоста в файле known_hosts.

-R Удалить все ключи, принадлежащие имени хоста, из файла known_hosts.

-y Прочитать частный файл формата OpenSSH и вывести открытый ключ OpenSSH на стандартный вывод.

Здесь перечислены только наиболее часто используемые параметры. Для полного использования, включая более экзотические и специальные параметры, используйте команду man ssh-keygen.

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

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

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

Файл закрытого ключа необходим для завершения работы мастера установки кластера MC.

Создать файл закрытого ключа

Войдите на сервер как root или как пользователь с привилегиями sudo.

Перейдите в свой домашний каталог.

Создайте каталог .ssh, если он еще не существует.

Создайте пару закрытый/открытый ключ без пароля.

Эта команда создает два файла: vid_rsa и vid_rsa.pub. Файл vid_rsa — это файл закрытого ключа, который вы загружаете в MC, чтобы он мог получить доступ к узлам в кластере и установить Vertica. Файл vid_rsa.pub копируется на все остальные хосты, чтобы клиенты могли получить к ним доступ с помощью файла vid_rsa.

Сделайте ваш каталог .ssh доступным для чтения и записи только вам самим.

Перейдите в каталог .ssh.

Объедините открытый ключ с файлом vauthorized_keys2.

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

Сделайте файлы в вашем каталоге .ssh доступными для чтения и записи только вам самим.

Создайте каталог .ssh на других узлах.

Скопируйте vавторизованный ключевой файл на другие узлы.

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

На каждом узле удалите файл vauthorized_keys2.

Полный пример команд для создания открытого ключа и предоставления доступа к трем хостам из ключа приведен ниже. Команды инициируются с хоста docg01, и все хосты будут включены в кластер (docg01 - docg03):

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

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

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

Важное примечание. При использовании управления входом на сервер (он же управляемый SSH) для управления ключами пользователя открытый ключ пользователя не может исчезнуть из файла ~/.ssh/authorized_keys сразу после отзыва разрешения server_login у этого пользователя. Это нормально — в конечном итоге ключ должен быть удален из файла author_keys запущенным демоном, но он запускается только периодически через определенные промежутки времени, поэтому его нельзя удалить немедленно.

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

Ответить

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

1. Создайте пару ключей на своем компьютере

Linux и MacOS X

Откройте окно терминала. В командной строке введите следующую команду:

Программа ssh-keygen запросит у вас расположение файла ключа. Нажмите «Return», чтобы принять значения по умолчанию. При желании вы можете указать парольную фразу для защиты вашего ключевого материала. Нажмите «Return», чтобы пропустить парольную фразу. Вывод программы будет выглядеть примерно так:

Запишите место, где были сохранены ваш открытый и закрытый ключи; они потребуются на следующем шаге.

Windows (SSH-клиент PuTTY)

На рабочей станции Windows выберите Пуск > Все программы > PuTTY > PuTTYgen. Отобразится генератор ключей PuTTY.

Нажмите кнопку "Создать" и следуйте инструкциям. После завершения генерации ключа вам будут представлены результаты:

Нажмите Сохранить закрытый ключ, чтобы сохранить закрытый ключ в файл. Обратите внимание на полный путь к файлу закрытого ключа, что особенно важно, если вы сохраняете его в папке «Документы». Повторите процесс для открытого ключа или просто скопируйте открытый ключ из текстовой области PuTTY в буфер обмена и сохраните его как текстовый файл.

Закройте генератор ключей PuTTY.

2. Изменить настройки RightScale SSH

Войдите на панель управления RightScale и выберите «Настройки» > «Настройки пользователя» > «SSH».
Нажмите «Изменить». В разделе "Аутентификация" выберите переключатель "Использовать учетные данные, хранящиеся на моем компьютере".
Откройте файл открытого ключа в текстовом редакторе и скопируйте его содержимое в буфер обмена. Вставьте их в текстовую область с надписью «Открытый ключ».

Если вы используете приложение Java Web Start или апплет Java в качестве средства запуска сеанса, введите местоположение файла закрытого ключа в текстовое поле с надписью Закрытый ключ. Обязательно используйте абсолютный путь к файловой системе без каких-либо специальных символов, таких как ~ или $HOME или %HOMEPATH% . Если вы используете ссылки протокола ssh:// в качестве предпочтения запуска сеанса, настройте свой SSH-клиент на автоматическое использование вашего закрытого ключа для аутентификации. Когда вы закончите, страница будет выглядеть примерно так:

Нажмите «Сохранить», чтобы сохранить настройки SSH.

3. Контроль входа на тестовый сервер

Запустите сервер, использующий RightImage 5.1.1 или более позднюю версию. Как только сервер заработает, перейдите на страницу сервера и нажмите кнопку консоли SSH.

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

Здравствуйте! Несмотря на мое внимательное чтение, я до сих пор не совсем понимаю, как использовать ключевой файл. Как его можно сгенерировать? Какой тип файла принимается в качестве ключевого файла? Что он может содержать? Где его можно сохранить? Можно ли его изменить (если да, то как?). То есть можно использовать оба варианта защиты: мастер-пароль и ключевой файл или и то, и другое? Извините, что я так запутался, но я думаю, что важно знать, что, поскольку говорится, что ключевой файл обычно превосходит мастер-пароль. Заранее спасибо за любой совет!

Если вы хотите сослаться на этот комментарий где-то еще в этом проекте, скопируйте и вставьте следующую ссылку:

Файл ключа можно использовать вместо пароля или в дополнение к паролю.
Ключевым файлом может быть любой файл, который вы выберете, хотя вы должны выбрать файл с большим количеством случайных данных — например, изображение собаки в формате JPEG.
KeePass сгенерирует для вас файл ключа, если вы не укажете существующий файл.
Файл ключа нельзя изменить, это остановит открытие базы данных. Вы можете сохранить базу данных с новым файлом ключей.
Ключевые файлы должны быть зарезервированы, иначе вы не сможете открыть базу данных после сбоя жесткого диска. Не делайте резервную копию файла ключа в том же месте, что и база данных, используйте другой каталог или диск. Попробуйте открыть базу данных на другом компьютере, чтобы убедиться, что резервная копия работает.

Большое спасибо за такой быстрый ответ!! Я открыл изображение PNG с помощью Блокнота Windows. Это дало много «страниц» различных персонажей на экране. Затем я сохранил это как image.key. Я открыл Keepass и щелкнул «Файл», «Изменить мастер-ключ», «Найти», а затем указал, где находится мой image.key (папка). Говорится: Новый ключ создан или что-то в этом роде. Так что с этого момента все, что мне нужно вводить, это мой мастер-пароль (местоположение файла ключа автоматически отображается в поле). Я попытался изменить ключевой файл и... конечно, Keepass его больше не принял (хотя имя и местоположение не изменились). Мне пришлось вернуть содержимое ключа, как это было, когда я создал ассоциацию с мастер-паролем). Он отлично работает! Теперь, если кто-то изменит или удалит ключевой файл, я не смогу открыть базу данных Keepass, верно? Если это так, крайне важно сохранить и базу данных, и файл ключа в дополнительном хранилище, например на съемном носителе, а не только на жестком диске. Большое спасибо за ваше время и качественный сервис!

Пол сказал: «Не делайте резервную копию файла ключа в том же месте, что и база данных, используйте другой каталог или диск».

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

Читайте также: