Как удалить ssh key mac os

Обновлено: 08.07.2024

Спустя полгода после переезда под MacOS мне понадобилось залогиниться на один Ubuntu-сервер, доступ к которому у меня был по ключу, сгенерированному в puttygen под Windows.

Достучатся до админа сервера не получилось, а переконфигурировать сервер надо было быстро. После пары минут в поисковике я нашел способ конвертировать ключи ppk, созданные putty под Windows, в ключи формата OpenSSH, которые понимают ssh-клиенты под Mac и Linux.

Устанавливаем putty на Mac (или Linux)

Под MacOS самый удобный способ установить putty (и все сопутствующие ему приложения вроде puttygen) через Homebrew:

Теперь нам доступна утилита puttygen .

Конвертируем ключи

Мой приватный ключ называется stena.ppk , поэтому я пишу в консоли:

Тем самым говорю утилите:

возьми мой приватный ключ в формате ppk ,
конвертируй его в приватный ключ в формате OpenSSH
и положи в папку .ssh в домашнем каталоге текущего пользователя под именем stena .

Не уходя далеко, из того же самого приватного ключа делаем публичный (на всякий случай):

Аналогично, просим утилиту:

возьми мой приватный ключ в формате ppk ,
конвертируй его в публичный ключ в формате OpenSSH
и положи в папку .shh под именем stena.pub .

Обновляем права доступа к файлам ключей

На только что созданные ключи терминальный ssh начал ругаться, что их права доступа «слишком открыты (too open)». Пришлось изменить права к файлам вот такими командами:

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

Подключаемся по ssh к удаленному серверу с новым ключом

Для подключения к серверу пишем в терминале:

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

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

Слева публичный ключ, сгенерированный Putty, а справа — сконвертированный в OpenSSH. Отличаются они переносами строк в теле ключа и оформлением начальных и конечных меток. Удаленный сервер на Ubuntu считает их идентичными

Замечательно, что есть версия putty для Mac и Linux. С помощью этой утилиты можно сэкономить кучу времени, особенно, если ваши публичные ключи разложены по большому количеству серверов. Меньше головной боли для админов. Здоровья им.

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

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

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

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

Проверьте ваши сокеты, которые использует ваш ssh-agent (1).

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

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

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

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

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

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

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

Делать, ssh-add -D чтобы удалить все ваши добавленные вручную ключи. Это также блокирует автоматически добавленные ключи, но не очень полезно, так gnome-keyring как попросит вас разблокировать их в любом случае, когда вы попытаетесь сделать a 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 файле ; Я должен был вручную удалить их оттуда.

Другой вариант в Ubuntu 14-16 - использовать графический интерфейс «Пароли и ключи» (вы можете найти ssh, чтобы найти его). Выберите, например, ключи OpenSS, затем щелкните правой кнопкой мыши ключ и выберите «Удалить». Вам может потребоваться перезагрузить систему, чтобы увидеть, что она удалена. Почему эта информация о ssh-agent и ssh-add выбранный ответ? Оригинальный плакат сказал, что хочет remove the old SSH key directly on the server and upload a new one . Похоже, он хочет редактировать

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

Этот ответ привел меня к решению проблемы с включенной пересылкой ssh. При переходе с компьютера с Ubuntu 16.04 на систему Debian, куда пересылаются все учетные данные ssh, git clone использовался первый ключ в цепочке вместо версии в файле конфигурации в окне Ubuntu. Плохой ключ автоматически засасывался и отправлялся в ящик Debian. Это настоящая боль в тылу. Я работаю над проектами компании и по контракту работаю в другой компании. Это просто добавляет потраченное время на управление обоими. Я надеюсь, что исправление придет в ближайшее время! В случае , если это помогает любому: я даже пытался вычеркивания id_rsa и id_rsa.pub файлы вообще, а ключ был все еще показывает вверх. Оказывается, gpg-agent кеширует их в

/.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 или нет в вашей системе

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

Если не чем

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

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

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

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

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

Перевод статьи «How to Manage Multiple SSH Keys».

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

Несмотря на то, что хорошей практикой считается иметь одну пару ключей (закрытый и открытый) для каждого устройства, иногда возникает потребность использовать несколько ключей. Также эти ключи могут иметь необычные имена.

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

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

Пристегните ремни и полетели!

Работа с одним SSH-ключом

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

У вас есть один закрытый ключ, хранящийся в файле

/.ssh/id_rsa, и соответствующий открытый ключ в файле

Давайте представим, что вы хотите отправлять изменения в коде на удаленный Git-сервер, допустим, на GitHub (почему бы и нет). Для этого вам нужно сначала добавить на GitHub ваш открытый ключ. Я не буду останавливаться на этом шаге, найти информацию по этой теме довольно легко.

Предположим, что вас зовут Стив (англ. Steve) и вы работаете над очень секретным проектом с использованием Raspberry Pies для прослушивания сетевого трафика.

Чтобы начать работу, вам нужно клонировать git-репозиторий, используя SSH:

На этом этапе GitHub «думает»: «О, приватный репозиторий! Нам нужно зашифровать трафик при помощи имеющегося у меня открытого ключа и вашего закрытого ключа».

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

/.ssh/id_rsa (это лучшее, что он может предположить). Если по этому адресу не будет соответствующего файла, вы получите ошибку:

Если у вас все же хранится какой-то ключ в

/.ssh/id_rsa, SSH-клиент использует этот закрытый ключ для шифрования соединения. Если ключ защищен паролем (как это и должно быть), вам будет предложено ввести этот пароль:

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

Но что, если вы дали своему файлу с закрытым ключом нестандартное имя (например,

/.ssh/_id_rsa)? SSH-клиент не сможет определить, где хранится закрытый ключ. Вы получите ту же самую ошибку Permission denied …, что и раньше.

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

После ввода пароля вы при помощи команды ssh-add -l сможете проверить, добавился ли ключ в ssh-agent (SSH -клиент). Эта команда выведет все ключи, доступные на данный момент SSH-клиенту.

Если вы теперь попробуете клонировать репозиторий, вы сможете это сделать.

Пока все хорошо, не так ли?

Внимательный читатель мог заметить несколько потенциальных проблем.

Для начала, если вы перезагрузите свой компьютер, ssh-agent тоже перезагрузится, и вам придется заново добавлять ваши ключи с нестандартными именами и вводить пароли.

Можно ли автоматизировать добавление ключей или как-то указать, какие ключи для каких серверов использовать?

Можно ли каким-то образом сохранить пароли, чтобы не вводить их каждый раз? Если бы только существовало что-то вроде keychain («связка ключей») для хранения SSH-ключей, защищенных паролями!

Можете быть спокойны: на все эти вопросы есть ответы.

Знакомьтесь: SSH config

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

Создайте новый файл

/.ssh/config и откройте его для редактирования.

Управление SSH-ключами с нестандартными именами

Первое, что мы хотим сделать при помощи файла config, это избавиться от необходимости постоянно добавлять SSH-ключи с нестандартными именами при помощи ssh-add.

Предположим, ваш ключ имеет имя

/.ssh/_id_rsa. В файл config нужно добавить следующие строки:

Выполните команду ssh-add -D, чтобы убедиться, что вашего файла

/.ssh/_id_rsa нет в ssh-agent. Эта команда удалит все ключи из текущей сессии ssh-agent. Сессия сбрасывается при каждом вашем выходе из системы или перезагрузке компьютера (или когда вы вручную убиваете процесс ssh-agent). При помощи команды ssh-add -D мы можем смоделировать перезагрузку.

Если вы попробуете клонировать ваш GitHub-репозиторий сейчас, все будет происходить так же, как если бы мы добавили ключ вручную (как мы делали раньше). Вам будет предложено ввести пароль:

Обратите внимание, что ключ, пароль от которого у нас спрашивают, это именно тот ключ, который мы указали в файле config. После ввода корректного пароля репозиторий будет успешно клонирован.

Примечание: если после успешного клонирования вы попытаетесь выполнить git pull, вам опять предложат ввести пароль. С этим мы разберемся дальше.

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

Теперь вы можете использовать git clone git@bitbucket-corporate:company/project.git

Теперь вы можете использовать git clone git@bitbucket-personal:steve/other-pi-project.git

А сейчас вы можете подключаться по SSH к собственному серверу, используя ssh myserver. Круто? Больше не нужно каждый раз, запуская ssh, вручную вводить номер порта и имя пользователя.

Бонус: настройки для каждого отдельного репозитория

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

Можно прописать специальную SSH-команду, задав ее в качестве значения sshCommand под core в <project>/.git/config. Например:

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

Управление паролями

Последняя часть головоломки — управление паролями. Нам хотелось бы избежать введения пароля при каждой инициации SSH-соединения. Для этого мы можем использовать специальное программное обеспечение для управления связками ключей. Оно поставляется в MacOS и различных дистрибутивах Linux.

Начните с добавления вашего ключа в связку (keychain). Для этого к команде ssh-add нужно добавить опцию -K:

Теперь вы можете видеть ваш SSH-ключ в связке. На MacOS это выглядит примерно так:

Если вы удалите ключи из ssh-agent при помощи команды ssh-add -D (как я уже говорил, это также происходит при перезагрузке компьютера) и попытаетесь установить SSH-соединение, вам будет предложено ввести пароль. Почему? Мы только что добавили ключ в связку. Если вы снова проверите Keychain Access, вы заметите, что добавленный при помощи команды ssh-add -K ключ по-прежнему находится в связке. Странно, правда?

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

Теперь SSH будет искать ключ в связке, и если найдет, то вам не нужно будет вводить пароль. Ключ также будет добавлен в ssh-agent.

Для MacOS это будет работать в версии MacOS Sierra 10.12.2 и в более поздних версиях. Для Linux можно использовать что-то вроде gnome-keyring и это может сработать даже без последней модификации SSH-конфига. Что касается Windows — кто знает.

Надеюсь, эта статья будет вам полезной. А теперь — вперед, приступайте к работе над SSH-конфигом!

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

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

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

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

точнее, о проблеме:

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

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

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

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

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

этот коммент на самом деле предполагает:

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

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

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

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