Не подходит пароль после восcтановления из backup
Забэкапил в своё время папку .gnupg. Сегодня потребовалось восстановить. Просто скопировал все файлы из бэкапа в папку /.gnupg. Дальше потребовалось расшифровать файл. Тут и проблема, пароль не подходит. Пароль у меня хранится в KeePass. Ввожу верно. Пароль не менялся.
Что я делаю неверно? Возможно не правильно восстановил из бэкапа?
комментариев: 11558 документов: 1036 редакций: 4118
Вряд ли, содержимое директории ~/.gnupg в дефолтной конфигурации самодостаточно. Разве что в бэкапе хранилась копия закрытого ключа с другим паролем.
Проблема точно именно в неверном пароле? При расшифровании из консоли не выводятся ли какие-то более специфические ошибки? Ну, и попробуйте вспомнить, меняли ли Вы пароль ключа после того, как сделали бэкап.
комментариев: 511 документов: 2 редакций: 70
Файл, зашифрованный ключом из кейринга в ~/.gnupg, который (кейринг) вы когда-то бэкапили?
комментариев: 4 документов: 1 редакций: 1
Да, ни сменить пароль не расшифровать файл.
Нет, не менял. Были сгенерированы ключи. Публичный ключ отправлен на сервер, где нужно было делать бэкапы, криптовать и отправлять на dropbox. А вся папка gnupg была забэаплена отдельно.
При этом все даты изменения файлов в .gnupg на сервере и в папке бэкапа соответствуют той дате, когда всё это было сделано. Я полагаю, что если бы пароль менялся, то даты изменения были бы другими.
Не совсем понял о чем речь. Вот что бэкапилось:
комментариев: 511 документов: 2 редакций: 70
Аналогично.
Какой файл? Т.е. чем он был зашифрован? GnuPG поддреживает симметричное и асимметричное шифрование. У вас точно было последнее?
То, что вы описываете, быть не может, значит, ошибка либо в KeePass (например, новая версия несовместима со старой), либо в ваших действиях.
Как ещё одна параноя-версия: вы расшифровыввете файлы, которые лежали на серверах. Кто-то намеренно их изменил так, что они более не расшифровываются. ☺ Проставить нужные даты изменений в метаданных — не проблема.
комментариев: 4 документов: 1 редакций: 1
У меня на сервере есть база данных. Она архивируется и криптуется командой:
Расшифровываю:
комментариев: 511 документов: 2 редакций: 70
OK, значит, шифровалось ключом с идентификатором backup_man.
Не стоит усложнять вещи раньше времени. Первое: gpg -K выдаёт наличие приватного ключа? Второе: если да, то попытайтесь сделать gpg --edit-key backup_man, потом выполните в консоли passwd. Это смена пароля на приватный ключ. Если пароль неверный, он не даст его сменить. Т.е. для теста вашего утеряного пароля никакие файлы и расшифровывания не нужны в принципе.
Ещё стоит посмотреть в сторону состава подключей в backup_man. Он изменялся?
комментариев: 4 документов: 1 редакций: 1
Да.
Неверный пароль.
Подключи я не добавлял.
А можно ли как-то посмотреть целостность приватного ключа? Он у меня хранился на зеркальном RAID массиве. Один диск в этом массиве выходил из строя. Может в процессе восстановления что-то случилось.
комментариев: 11558 документов: 1036 редакций: 4118
Ещё один вариант: настройки кодировки консольного ввода не менялись? Изначально пароль мог вводиться не в той кодировке, которая установлена сейчас.
комментариев: 4 документов: 1 редакций: 1
Да, менял с en-US.UTF-8 на ru-RU.UTF-8. Вернул обратно, плюс потестил на win (kleopatra) – результат тот же.
Видимо уже ничего не поможет. Благо данные не критичные потеряны. Отныне буду хранить секретный ключ на нескольких сменных носителях ;)
SATtva, pgprubot, спасибо за помощь.
комментариев: 11558 документов: 1036 редакций: 4118
Ну, это смена локали, но не кодировки, так что не должно было повлиять. Странная ситуация.
комментариев: 511 документов: 2 редакций: 70
комментариев: 11558 документов: 1036 редакций: 4118