What is the correct way to remove RSA key-pair entirely from my SSH configuration?
Suppose these two operating systems and SSH software:
GNU/Linux Debian 9.3 with OpenSSH version 1:7.4p1-10+deb9u2
Linux Mint 18.3 with OpenSSH version 1:7.2p2-4ubuntu2.4
And I want to switch away from rsa completely to the benefits of curve ed25519 .
The question is, after I generate ed25519 on both systems with:
And copy the public keys with ssh-copy-id , shall I delete the rsa key-pair with rm or is that a wrong way?
1 Answer 1
No, deleting the key pair is fine. All you have to do is to delete your public key from the server. However, you don’t remove it with rm ; you delete the relevant lines from the
Check first that you can log in with your new key pair!
For cleanliness, I’d also suggest you to remove your private key from the client machine, although that would make no difference.
How to remove ssh keys?
It seems to me you are copying 4 keys to your server.
This is taken from the online documentation located at https://www.ssh.com/academy/ssh/copy-id
-i Specifies the identity file that is to be copied (default is
/.ssh/id_rsa). If this option is not provided, this adds all keys listed by ssh-add -L. Note: it can be multiple keys and adding extra authorized keys can easily happen accidentally! If ssh-add -L returns no keys, then the most recently modified key matching
/.ssh/id*.pub, excluding those matching
/.ssh/*-cert.pub, will be used.
Update from the comments:
If you which to remove a certain key just use:
One of the backup options can be:
$ mv .ssh/id_target_key id_target_key.bak
Remember that there are always 2 keys. One private and one public. The latter has the extension .pub
Where to locate these keyfiles? On the server open /etc/ssh/sshd_config and look for
This file can be edited in order to remove your key manually, there might be other users keys installed.
On the client open /etc/ssh/ssh_config and look for an alternative path from there. (Mine is all commented out so
/.ssh is the default location)
/ is a relative path which changes per user. Executing the ssh command set with sudo will result in a different path: /root.
Памятка пользователям SSH
В статье описаны продвинутые функций OpenSSH, которые позволяют сильно упростить жизнь системным администраторам и программистам, которые не боятся шелла.
В отличие от большинства руководств, которые кроме ключей и -L/D/R опций ничего не описывают, я попытался собрать все интересные фичи и удобства, которые с собой несёт ssh.
Управление ключами
Теория в нескольких словах: ssh может авторизоваться не по паролю, а по ключу. Ключ состоит из открытой и закрытой части. Открытая кладётся в домашний каталог пользователя, «которым» заходят на сервер, закрытая — в домашний каталог пользователя, который идёт на удалённый сервер. Половинки сравниваются (я утрирую) и если всё ок — пускают. Важно: авторизуется не только клиент на сервере, но и сервер по отношению к клиенту (то есть у сервера есть свой собственный ключ). Главной особенностью ключа по сравнению с паролем является то, что его нельзя «украсть», взломав сервер — ключ не передаётся с клиента на сервер, а во время авторизации клиент доказывает серверу, что владеет ключом (та самая криптографическая магия).
Генерация ключа
Свой ключ можно сгенерировать с помощью команды ssh-keygen. Если не задать параметры, то он сохранит всё так, как надо. Ключ можно закрыть паролем. Этот пароль (в обычных графических интерфейсах) спрашивается один раз и сохраняется некоторое время. Если пароль указать пустым, он спрашиваться при использовании не будет. Восстановить забытый пароль невозможно.
Сменить пароль на ключ можно с помощью команды ssh-keygen -p.
Структура ключа
/.ssh/id_rsa.pub — открытый ключ. Его копируют на сервера, куда нужно получить доступ.
/.ssh/id_rsa — закрытый ключ. Его нельзя никому показывать. Если вы в письмо/чат скопипастите его вместо pub, то нужно генерировать новый ключ.
Копирование ключа на сервер
В каталоге пользователя, под которым вы хотите зайти, если создать файл
/.ssh/authorized_keys и положить туда открытый ключ, то можно будет заходить без пароля. Обратите внимание, права на файл не должны давать возможность писать в этот файл посторонним пользователям, иначе ssh его не примет. В ключе последнее поле — user@machine. Оно не имеет никакого отношения к авторизации и служит только для удобства определения где чей ключ. Заметим, это поле может быть поменяно (или даже удалено) без нарушения структуры ключа.
Если вы знаете пароль пользователя, то процесс можно упростить. Команда ssh-copy-id user@server позволяет скопировать ключ не редактируя файлы вручную.
Замечание: Старые руководства по ssh упоминают про authorized_keys2. Причина: была первая версия ssh, потом стала вторая (текущая), для неё сделали свой набор конфигов, всех это очень утомило, и вторая версия уже давным давно переключилась на версии без всяких «2». То есть всегда authorized_keys и не думать о разных версиях.
Если у вас ssh на нестандартном порту, то ssh-copy-id требует особого ухищрения при работе: ssh-copy-id ‘-p 443 user@server’ (внимание на кавычки).
Ключ сервера
Первый раз, когда вы заходите на сервер, 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.
Копирование файлов
Передача файлов на сервер иногда может утомлять. Помимо возни с sftp и прочими странными вещами, ssh предоставляет нам команду scp, которая осуществляет копирование файла через ssh-сессию.
scp path/myfile user@8.8.8.8:/full/path/to/new/location/
Обратно тоже можно:
Fish warning: Не смотря на то, что mc умеет делать соединение по ssh, копировать большие файлы будет очень мучительно, т.к. fish (модуль mc для работы с ssh как с виртуальной fs) работает очень медленно. 100-200кб — предел, дальше начинается испытание терпения. (Я вспомнил свою очень раннюю молодость, когда не зная про scp, я копировал
5Гб через fish в mc, заняло это чуть больше 12 часов на FastEthernet).
Возможность копировать здорово. Но хочется так, чтобы «сохранить как» — и сразу на сервер. И чтобы в графическом режиме копировать не из специальной программы, а из любой, привычной.
sshfs
Теория: модуль fuse позволяет «экспортировать» запросы к файловой системе из ядра обратно в userspace к соответствующей программе. Это позволяет легко реализовывать «псевдофайловые системы». Например, мы можем предоставить доступ к удалённой файловой системе через ssh так, что все локальные приложения (за малым исключением) не будут ничего подозревать.
Собственно, исключение: O_DIRECT не поддерживается, увы (это проблема не sshfs, это проблема fuse вообще).
Использование: установить пакет sshfs (сам притащит за собой fuse).
Собственно, пример моего скрипта, который монтирует desunote.ru (размещающийся у меня на домашнем комьютере — с него в этой статье показываются картинки) на мой ноут:
#!/bin/bash
sshfs desunote.ru:/var/www/desunote.ru/ /media/desunote.ru -o reconnect
Параметры sshfs, которые могут оказаться важными: -o reconnect (говорит пытаться пересоединиться вместо ошибок).
Если вы много работаете с данными от рута, то можно (нужно) сделать idmap:
Работает она следующим образом: если мы коннектимся как пользователь pupkin@server, а локально работаем как пользователь vasiliy, то мы говорим «считать, что файлы pupkin, это файлы vasiliy». ну или «root», если мы коннектимся как root.
В моём случае idmap не нужен, так как имена пользователей (локальное и удалённое) совпадают.
Заметим, комфортно работать получается только если у нас есть ssh-ключик (см. начало статьи), если нет — авторизация по паролю выбешивает на 2-3 подключение.
Отключить обратно можно командой fusermount -u /path, однако, если соединение залипло (например, нет сети), то можно/нужно делать это из-под рута: sudo umount -f /path.
Удалённое исполнение кода
ssh может выполнить команду на удалённом сервере и тут же закрыть соединение. Простейший пример:
Выведет нам содержимое /etc/ на server, при этом у нас будет локальная командная строка.
Некоторые приложения хотят иметь управляющий терминал. Их следует запускать с опцией -t:
ssh user@server -t remove_command
Кстати, мы можем сделать что-то такого вида:
Проброс stdin/out
Допустим, мы хотим сделать запрос к программе удалённо, а потом её вывод поместить в локальный файл
Допустим, мы хотим локальный вывод положить удалённо
mycommand |scp — user@8.8.8.8:/path/remote_file
Усложним пример — мы можем прокидывать файлы с сервера на сервер: Делаем цепочку, чтобы положить stdin на 10.1.1.2, который нам не доступен снаружи:
mycommand | ssh user@8.8.8.8 «scp — user@10.1.1.2:/path/to/file»
Есть и вот такой головоломный приём использования pipe’а (любезно подсказали в комментариях в жж):
Tar запаковывает файлы по маске локально, пишет их в stdout, откуда их читает ssh, передаёт в stdin на удалённом сервере, где их cd игнорирует (не читает stdin), а tar — читает и распаковывает. Так сказать, scp для бедных.
How do I manage SSH keys stored in the ssh-agent (Portable OpenSSH)?
I’m at my wit’s end trying to figure out how to manage SSH keys stored by the ssh-agent. I expect to be able to list the keys and delete all or individual keys as needed. The Microsoft Docs doesn’t give any indication of how to do this, but at least point you to the OpenSSH Manual.
However, the commands do not work!
I have searched for solutions on the internet, but I couldn’t find any. I’ll explain the issue in more detail with the following steps:
I Verified that the path for the ssh-agent used by Git is properly configured and associated with Portable OpenSSH in Windows.
Exit fullscreen mode
Exit fullscreen mode
1. Test the SSH connection to confirm that SSH authentication is working.
Exit fullscreen mode
Exit fullscreen mode
2. To lists the public keys of all identities currently managed by the ssh-agent. I expected a list containing the Ed25519 key(s) stored by the agent.
Exit fullscreen mode
Exit fullscreen mode
3. To delete a specific or list of identities from the ssh-agent. I expected the agent to remove the private key corresponding to the specified public key.
Exit fullscreen mode
Exit fullscreen mode
4. To delete all identities from the ssh-agent. I expected the agent to remove all the private keys, but even though it seems successful, the SSH authentication test in the next step disproof this assumption.
Exit fullscreen mode
Exit fullscreen mode
5. Test the SSH connection again after deleting all keys. I expected that the test will fail, yet the second test is successful as well.