Как удалить ключ ssh?

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

/.ssh каталог (с оригиналом id_rsa и id_rsa.pub файлами).

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

Я попробовал следующую команду без успеха:

Есть ли способ полностью удалить ключ SSH?

Обратите внимание, что существует по крайней мере два сообщения об ошибках для ssh-add -d/-D не удаления ключей:

ssh-add -d/-D удаляет только вручную добавленные ключи из gnome-keyring.
Нет способа удалить автоматически добавленные ключи.
Это оригинальная ошибка, и она по-прежнему присутствует.

Так, например, если у вас есть две разные автоматически загруженные идентификационные данные ssh, связанные с двумя разными учетными записями GitHub — скажем, для работы и для дома — нет способа переключаться между ними. GitHub использует первый подходящий вариант, поэтому вы всегда появляетесь на GitHub как «домашний» пользователь, и у вас нет возможности загружать вещи в рабочие проекты.

Разрешение ssh-add -d применять к автоматически загружаемым ключам (и ssh-add -t X изменять время жизни автоматически загружаемых ключей) восстановит поведение, ожидаемое большинством пользователей.

Точнее, по вопросу:

Виновником является gpg-keyring-daemon :

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

Как мы ненавидим это? Давайте не будем считать пути — жизнь слишком коротка.

Ошибка осложняется тем, что новые ssh-клиенты автоматически пробуют все ключи в вашем ssh-agent при подключении к хосту.
Если их слишком много, сервер отклонит соединение.
И так как gnome-keyring-daemon для себя решил, сколько ключей вы хотите иметь у вашего ssh-агента, и автоматически их загрузил, И НЕ ПОЛУЧИТ УДАЛИТЬ ИХ, вы тост.

Эта ошибка все еще подтверждается в Ubuntu 14.04.4, всего два дня назад (21 августа 2014 г.)

Возможный обходной путь:

• Делать, ssh-add -D чтобы удалить все ваши добавленные вручную ключи. Это также блокирует автоматически добавленные ключи, но не очень полезно, так gnome-keyring как попросит вас разблокировать их в любом случае, когда вы попытаетесь сделать a git push .
• Перейдите в свою

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

Теперь вы должны быть в состоянии обойтись git push без проблем.

Другой обходной путь:

То, что вы действительно хотите сделать, это gpg-keyring-daemon вообще отключить .
Перейти System —> Preferences —> Startup Applications и отменить выбор SSH Key Agent (Gnome Keyring SSH Agent) флажок » — вам нужно прокрутить вниз, чтобы найти его.

Вы все равно получите ssh-agent , только теперь он будет вести себя разумно: ключи не загружаются автоматически, вы запускаете ssh-add, чтобы добавить их, и если вы хотите удалить ключи, вы можете это сделать. Представьте себе, что.

Решение состоит в том, чтобы gnome-keyring-manager не запускаться никогда, что было странным образом затруднено, в конечном итоге, путем удаления разрешения на выполнение программного файла.

Райан Лю добавляет еще один интересный случай в комментариях :

На случай, если это кому-нибудь поможет: я даже попытался удалить id_rsa и id_rsa.pub файлы вообще, а ключ был все еще показывает вверх.

Оказывается, gpg-agent кэшировал их в

/.gnupg/sshcontrol файле ; Я должен был вручную удалить их оттуда.

/.ssh/authorized_keys на удаленном хосте.

/.gnupg/sshcontrol файле; Я должен был вручную удалить их оттуда.

Если вы пытаетесь выполнить операцию, связанную с ssh, и получаете следующую ошибку:

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

Если не ошибаюсь, вы потеряли свой .ssh каталог, содержащий ваш закрытый ключ, на вашем локальном компьютере, и поэтому вы хотите удалить открытый ключ, который был на сервере и который позволял входить на основе ключа. В этом случае он будет храниться в .ssh/authorized_keys файле в вашем домашнем каталоге на сервере. Вы можете просто отредактировать этот файл с помощью текстового редактора и удалить соответствующую строку, если вы можете определить его (даже проще, если это единственная запись!). Надеюсь, этот ключ был не единственным способом доступа к серверу, и у вас есть другой способ войти в систему и отредактировать файл. Вы можете вручную добавить новый открытый ключ в authorised_keys файл или использовать ssh-copy-id . В любом случае вам потребуется пароль, установленный для вашей учетной записи на сервере, или другой способ идентификации или доступа, чтобы получить доступ к authorized_keys файлу на сервере.

ssh-add добавляет идентификационные данные к вашему ssh-агенту, который локально управляет вашими идентификационными данными, и «соединение с агентом перенаправляется через удаленные входы SSH, и пользователь может таким образом безопасно использовать привилегии, предоставляемые идентификационными данными в любом месте сети». (man page), так что я не думаю, что это то, что вы хотите в этом случае. Насколько я знаю, он не может получить ваш открытый ключ на сервер, если у вас нет доступа к нему через логин ssh.

Я открыл приложение «Пароли и ключи» в своем Unity и удалил ненужные ключи из ключей Secure Keys -> OpenSSH. И они также автоматически были удалены из ssh-agent -l .

Я могу подтвердить, что эта ошибка все еще присутствует в Ubuntu 19.04. Обходной путь, предложенный @VonC, работал отлично, суммируя для моей версии:

• Нажмите на вкладку Действия в верхнем левом углу.
• В появившемся окне поиска начните вводить «запуск приложений»
• Нажмите на значок «Запуск приложений»
• В появившемся окне выберите приложение менеджера ключей gnome (не могу вспомнить точное имя в графическом интерфейсе, но оно достаточно различимо) и удалите его.

Затем я попытался ssh-add -D снова, и после перезагрузки ssh-add -l сказал мне, что у агента нет идентификаторов. Я подтвердил, что у меня все еще ssh-agent работает демон ps aux | grep agent . Поэтому я добавил ключ, который чаще всего использую с GitHub ( ssh-add

/.ssh/id_ecdsa ), и все хорошо!

Теперь я могу выполнять обычные операции с моим наиболее часто используемым репозиторием, и если мне иногда требуется доступ к другому репозиторию, использующему ключ RSA, я просто выделяю для этого один терминал export GIT_SSH_COMMAND=»ssh -i /home/me/.ssh/id_rsa.pub» . Решено! Благодарим @VonC за указание на ошибку и решение.

Проверьте ключ .ssh или нет в вашей системе

1. Перейдите в папку -> /Users/administrator/.ssh/id_ed25519.pub

Если не чем

Прошлое в терминале

1. Проверьте пользователя -> ssh -T git@gitlab.com

Удалить существующий ключ .ssh

Удалить существующий ключ .ssh -> rm

Создать новый

Создать новый ключ .ssh -> ssh-keygen -t rsa -b 4096 -C «your_email@example.com»

Открытый ключ был сохранен в «/Users/administrator/.ssh/id_ed25519.pub.»

Открыть открытый ключ сохраненный путь.

Скопируйте ключ .ssh -> Учетная запись GitLab -> Настройка -> Ключ SSH -> Добавить ключ

Проверьте снова с терминала -> ssh -T git@gitlab.com

Решение для меня (OpenSuse Leap 42.3, KDE) состояло в том, чтобы переименовать папку,

/.gnupg которая, очевидно, содержала кэшированные ключи и профили. После выхода из системы / входа в KDE ssh-add / agent снова запускается, и папка создается с нуля, но старые ключи исчезли.

IT — это «жизнь»

Дядя, дядя, наши сети, притащили.

cookieOptions

пятница, 23 августа 2013 г.

Удалить устаревшие ключи SSH, управление ключами

Первый раз, когда вы заходите на сервер, ssh вас спрашивает, доверяете ли вы ключу. Если отвечаете нет, соединение закрывается. Если да — ключ сохраняется в файл

/.ssh/known_hosts . Узнать, где какой ключ нельзя (ибо несекьюрно).

Если ключ сервера поменялся (например, сервер переустановили), ssh вопит от подделке ключа. Обратите внимание, если сервер не трогали, а ssh вопит, значит вы не на тот сервер ломитесь (например, в сети появился ещё один компьютер с тем же IP, особо этим страдают всякие локальные сети с 192.168.1.1, которых в мире несколько миллионов). Сценарий «злобной man in the middle атаки» маловероятен, чаще просто ошибка с IP, хотя если «всё хорошо», а ключ поменялся — это повод поднять уровень паранойи на пару уровней (а если у вас авторизация по ключу, а сервер вдруг запросил пароль — то паранойю можно включать на 100% и пароль не вводить).

Удалить известный ключ сервера можно командой ssh-keygen -R server . При этом нужно удалить ещё и ключ IP (они хранятся раздельно): ssh-keygen -R 127.0.0.1 .

Ключ сервера хранится
в /etc/ssh/ssh_host_rsa_key и /etc/ssh/ssh_host_rsa_key.pub . Их можно:
а) скопировать со старого сервера на новый.
б) сгенерировать с помощью ssh-keygen. Пароля при этом задавать не надо (т.е. пустой). Ключ с паролем ssh-сервер использовать не сможет.

Заметим, если вы сервера клонируете (например, в виртуалках), то ssh-ключи сервера нужно обязательно перегенерировать.

Старые ключи из know_hosts при этом лучше убрать, иначе ssh будет ругаться на duplicate key.

Управление ключами OpenSSH OpenSSH key management

Большинство операций аутентификации в средах Windows выполняется с использованием имени пользователя и пароля. Most authentication in Windows environments is done with a username-password pair. Это хорошо подходит для систем, использующих общий домен. This works well for systems that share a common domain. При работе с несколькими доменами, например с локальными и облачными системами, возникает риск атак методом перебора. When working across domains, such as between on-premise and cloud-hosted systems, it becomes vulnerable to brute force intrusions.

С другой стороны, среды Linux традиционно используют для аутентификации пару открытого и закрытого ключей, что делает ненужным использование угадываемых паролей. By comparison, Linux environments commonly use public-key/private-key pairs to drive authentication which doesn’t require the use of guessable passwords. OpenSSH содержит средства, поддерживающие такой сценарий: OpenSSH includes tools to help support this, specifically:

• ssh-keygen для создания защищенных ключей; ssh-keygen for generating secure keys
• ssh-agent и ssh-add для защищенного хранения закрытых ключей; ssh-agent and ssh-add for securely storing private keys
• scp и sftp для защищенного копирования файлов открытого ключа при первом использовании сервера. scp and sftp to securely copy public key files during initial use of a server

В этом документе описано, как использовать эти средства в Windows для перехода на аутентификацию с использованием ключей по протоколу SSH. This document provides an overview of how to use these tools on Windows to begin using key authentication with SSH. Если вы ничего не знаете об управлении ключами через SSH, мы настоятельно рекомендуем ознакомиться с документом NIST IR 7966 о защите интерактивного и автоматизированного управления доступом через Secure Shell (SSH). If you are unfamiliar with SSH key management, we strongly recommend you review NIST document IR 7966 titled «Security of Interactive and Automated Access Management Using Secure Shell (SSH).»

Сведения о парах ключей About key pairs

Парой ключей называются файлы открытого и закрытого ключей, которые используются в некоторых протоколах аутентификации. Key pairs refer to the public and private key files that are used by certain authentication protocols.

При аутентификации SSH на основе открытого ключа используются асимметричные алгоритмы шифрования для создания двух файлов ключей, один из которых считается закрытым, а второй открытым. SSH public-key authentication uses asymmetric cryptographic algorithms to generate two key files – one «private» and the other «public». Файлы закрытых ключей выполняют функцию паролей, а значит, должны быть постоянно защищены. The private key files are the equivalent of a password, and should stay protected under all circumstances. Если кто-то получит ваш закрытый ключ, он сможет войти от вашего имени на любой сервер с поддержкой SSH, к которому у вас есть доступ. If someone acquires your private key, they can log in as you to any SSH server you have access to. Открытый ключ размещается на сервере SSH. Его можно свободно распространять, не компрометируя закрытый ключ. The public key is what is placed on the SSH server, and may be shared without compromising the private key.

Если на сервере SSH используется аутентификация с помощью ключей, сервер и клиент SSH сравнивают открытые ключи, связанные с предоставленным именем пользователя, с закрытым ключом. When using key authentication with an SSH server, the SSH server and client compare the public keys for username provided against the private key. Если открытый ключ на стороне сервера не проходит проверку по закрытому ключу, сохраненному на стороне клиента, аутентификация не будет выполнена. If the server-side public key cannot be validated against the client-side private key, authentication fails.

Пару ключей можно дополнить многофакторной проверкой подлинности, например, настроив требование предоставлять парольную фразу при создании пары ключей (см. раздел о создании ключей ниже). Multi-factor authentication may be implemented with key pairs by requiring that a passphrase be supplied when the key pair is generated (see key generation below). При аутентификации пользователю предлагается ввести эту парольную фразу. Она применяется вместе с закрытым ключом для аутентификации пользователя. During authentication the user is prompted for the passphrase, which is used along with the presence of the private key on the SSH client to authenticate the user.

Создание ключей узла Host key generation

Для открытых ключей действуют определенные требования к ACL, которые в среде Windows соответствуют предоставлению доступа только администраторам и системной учетной записи. Public keys have specific ACL requirements that, on Windows, equate to only allowing access to administrators and System. Чтобы упростить эту задачу, To make this easier,

• был создан модуль PowerShell OpenSSHUtils для корректной настройки ACL для ключей. Этот модуль нужно установить на сервере. The OpenSSHUtils PowerShell module has been created to set the key ACLs properly, and should be installed on the server
• При первом использовании sshd будет автоматически создана пара ключей для узла. On first use of sshd, the key pair for the host will be automatically generated. Если ssh-agent в этот момент работает, ключи будут автоматически добавлены в локальное хранилище. If ssh-agent is running, the keys will be automatically added to the local store.

Чтобы упростить аутентификацию на сервере SSH, выполните следующие команды в командной строке PowerShell с повышенными привилегиями: To make key authentication easy with an SSH server, run the following commands from an elevated PowerShell prompt:

Так как со службой sshd пользователи не связаны, ключи узла сохраняются в папке \ProgramData\ssh. Since there is no user associated with the sshd service, the host keys are stored under \ProgramData\ssh.

Создание ключей пользователя User key generation

Чтобы использовать аутентификацию на основе ключей, необходимо заранее создать для клиента одну или несколько пар открытого и закрытого ключей. To use key-based authentication, you first need to generate some public/private key pairs for your client. Выполните ssh-keygen в командной строке PowerShell или cmd, чтобы создать файлы ключей. From PowerShell or cmd, use ssh-keygen to generate some key files.

Эта команда возвращает примерно такие выходные данные (где вместо username будет указано ваше имя пользователя). This should display something like the following (where «username» is replaced by your user name)

Можно нажать клавишу ВВОД, чтобы принять вариант по умолчанию, или указать путь для создания файлов ключей. You can hit Enter to accept the default, or specify a path where you’d like your keys to be generated. На этом этапе вам будет предложено указать парольную фразу для шифрования файлов закрытого ключа. At this point, you’ll be prompted to use a passphrase to encrypt your private key files. Парольная фраза в сочетании с файлом ключа обеспечивает двухфакторную аутентификацию. The passphrase works with the key file to provide 2-factor authentication. В нашем примере парольная фраза остается пустой. For this example, we are leaving the passphrase empty.

Теперь у вас есть пара открытого и закрытого ключей ED25519 (PUB-файлы содержат открытые ключи, а все остальные файлы нужны для закрытого ключа): Now you have a public/private ED25519 key pair (the .pub files are public keys and the rest are private keys):

Помните, что файлы закрытых ключей выполняют функцию пароля и должны защищаться так же тщательно. Remember that private key files are the equivalent of a password should be protected the same way you protect your password. Для этого, чтобы безопасно хранить закрытые ключи в контексте безопасности Windows, связанным с определенным именем входа Windows, используйте ssh-agent. To help with that, use ssh-agent to securely store the private keys within a Windows security context, associated with your Windows login. Запустите службу ssh-agent от имени администратора и выполните ssh-add, чтобы сохранить закрытый ключ. To do that, start the ssh-agent service as Administrator and use ssh-add to store the private key.

После этого при каждом выполнении аутентификации с этого клиента с использованием закрытого ключа, ssh-agent будет автоматически извлекать его и передавать клиенту SSH. After completing these steps, whenever a private key is needed for authentication from this client, ssh-agent will automatically retrieve the local private key and pass it to your SSH client.

Мы настоятельно рекомендуем создать резервную копию закрытого ключа в безопасном расположении, а затем удалить его из локальной системы после добавления в ssh-agent. It is strongly recommended that you back up your private key to a secure location, then delete it from the local system, after adding it to ssh-agent. Закрытый ключ невозможно извлечь из агента. The private key cannot be retrieved from the agent. Если вы утратите доступ к закрытому ключу, вам нужно будет создать новую пару ключей и обновить открытый ключ во всех системах, с которыми вы работаете. If you lose access to the private key, you would have to create a new key pair and update the public key on all systems you interact with.

Развертывание открытого ключа Deploying the public key

Чтобы использовать созданный ранее ключ пользователя, следует поместить открытый ключ на сервер в текстовый файл с именем authorized_keys в папке users\username\.ssh\. To use the user key that was created above, the public key needs to be placed on the server into a text file called authorized_keys under users\username\.ssh\. Для этого для безопасной передачи файлов в составе средств OpenSSH предоставляется служебная программа scp. The OpenSSH tools include scp, which is a secure file-transfer utility, to help with this.

Переместите содержимое открытого ключа (

.ssh\id_ed25519.pub) в текстовый файл с именем authorized_keys в папке

.ssh\ на нужном сервере или узле. To move the contents of your public key (

.ssh\id_ed25519.pub) into a text file called authorized_keys in

.ssh\ on your server/host.

В этом примере используется функция Repair-AuthorizedKeyPermissions модуля OpenSSHUtils, который вы ранее установили на узле согласно инструкциям выше. This example uses the Repair-AuthorizedKeyPermissions function in the OpenSSHUtils module which was previously installed on the host in the instructions above.

Эти действия завершают настройку, которая требуется для использования аутентификации SSH на основе ключей в среде Windows. These steps complete the configuration required to use key-based authentication with SSH on Windows. Теперь пользователь может подключаться к узлу sshd с любого клиента, где есть закрытый ключ. After this, the user can connect to the sshd host from any client that has the private key.