There will be times when you need to actually view your SSH certificates in Linux. Why? Say, for example, you need to add a certificate for authentication in GitHub (or any other online service that requires SSH authentication). You know you’ve created those SSH certificates, but how do you view them?
For those who are familiar with SSH, you probably already know the answer to that question. After all, this is pretty basic SSH stuff. For those who are new to the ways of SSH (or Linux, macOS, or Windows for that matter), the task might stump you.
Never fear, that’s why I’m here.
I want to show you just how easy it is to view those SSH keys, so you can use them for third-party services.
SEE: Identity theft protection policy (TechRepublic Premium)
What you’ll need
The only thing you’ll need for this is access to a server or desktop (Linux, macOS, or Windows) and an SSH key created. If you’ve not already created your SSH key pair, you can do so with the command:
ssh-keygen
That command will generate a key pair, both public and private keys. The public key is that which you send to servers for SSH key authentication. When you attempt to log in to that server, SSH will compare the public and private keys. If those keys are a match, you’ll be allowed access. Simple enough. You’re ready to move on.
How to view your SSH public key on Linux
There are two easy ways to view your SSH public key in Linux. The first method is a bit complicated, because it makes use of both ssh-agent and ssh-add commands. This is probably overkill for what you need, but it’s a good way to view the key, while requiring your SSH keypair password. The command is:
ssh-agent sh -c 'ssh-add; ssh-add -L'
Upon successful authentication, your SSH public key will print out in the terminal. You can then copy that and paste it where you need. Of course, that’s a lot of commands to remember, especially when you just need to view the contents of the public key.
If you don’t want to have to memorize yet another command, you could simply use the cat command like so:
cat ~/.ssh/id_rsa.pub
The above command will print out your SSH key on your Linux machine, without prompting you for your key authentication password.
How to view your SSH public key on macOS
Viewing your keys on macOS can be done in similar fashion as Linux. Open your terminal window and issue the command:
cat ~/.ssh/id_rsa.pub
Or:
cat /Users/USERNAME/.ssh/id_rsa.pub
Where USERNAME is your macOS username.
The above commands will print out your SSH public key.
macOS also has one more nifty trick up its sleeve. You can copy the contents of the SSH key directly to the clipboard, without displaying the key, using the pbcopy tool. This command would be:
cat ~/.ssh/id_rsa.pub | pbcopy
Once you’ve copied the key to your clipboard, you can paste it wherever you need it.
How to view your SSH public key on Windows
On Windows, you’ll use the type command to view your SSH public key like so:
type C:UsersUSERNAME.sshid_rsa.pub
Where USERNAME is the name of your user.
The above command will display your SSH public key. You can then use the Ctrl+c keyboard shortcut to copy the contents of the file.
You can also do something similar to what we did on macOS (copying the SSH public key directly to the clipboard) using the type and clip commands like so:
type C:UsersUSERNAME.sshid_rsa.pub | clip
Where USERNAME is your username.
You can now paste that key wherever you need it.
How to view your private key
Chances are you’re not ever going to have to view your private key. After all, that’s the secret in the sauce that’s never on display for anyone to see. But, on the off chance you do need to view that key, you can follow the same steps as above, but remove the .pub from the file name (in any instance). Remember id_rsa is the private key and id_rsa.pub is the public key.
And that’s all there is to viewing your SSH public and private keys on Linux, macOS, and Windows.
Just remember, treat these keys with the care and security they deserve. Although your public key will be handed out to other users and services, that private key needs to be tucked away and never shown to the public. If you do accidentally release that private key, you’ll need to remove the public key from the authorized_keys file from every server that uses the keypair, delete the public and private keys on the host, generate a new keypair, and send it to the servers you need to log in to with SSH key authentication. If you leave any trace of that compromised key pair on any server or desktop, you run the risk of allowing someone access.
Subscribe to TechRepublic’s How To Make Tech Work on YouTube for all the latest tech advice for business pros from Jack Wallen.
If you are using Windows PowerShell, the easiest way is to:
cat ~/.ssh/id_<key-type-here>.pub | clip
That will copy the key to your clipboard for easy pasting.
So, in my instance, I use ed25519 since RSA is now fairly hackable:
cat ~/.ssh/id_ed25519.pub | clip
Because I find myself doing this a lot, I created a function and set a simple alias I could remember in my PowerShell profile (learn more about PowerShell profiles here. Just add this to your Microsoft.PowerShell_profile.ps1:
function Copy-SSHKey {
Get-Content ~/.ssh/id_ed25519.pub | clip
}
Set_Alias -Name sshkey -Value Copy-SSHKey
Then, in a PowerShell console, run . $profile to load the functions. Then from now on all you will need to do is run sshkey, and then paste the key into wherever you need via the clipboard.
В некоторых ситуациях вам может потребоваться просмотреть содержимое ваших ключей SSH. Например, вам может потребоваться просмотреть содержимое открытого ключа, чтобы добавить его в удаленные службы, требующие аутентификации SSH, такие как Google Cloud. В этой статье показано, как просмотреть содержимое ключа SSH с помощью простой команды cat в Linux.
Первым шагом к настройке ключа SSH является создание пары. Пара ключей SSH содержит открытый и закрытый ключи. Используя общедоступную и частную пару, вы можете аутентифицировать пользователя на удаленном хосте.
В Linux используйте следующую команду для создания пары ключей SSH:
Приведенная выше команда потребует от вас ввода информации для настройки и создания ключей. Если вы находитесь в незащищенных сетях или критических системах, обязательно зашифруйте свои ключи парольной фразой.
Generating public/private rsa key pair. Enter file in which to save the key (/home/ubuntu/.ssh/id_rsa): Created directory '/home/ubuntu/.ssh'. Enter passphrase (empty for no passphrase): Enter same passphrase again: Your identification has been saved in /home/ubuntu/.ssh/id_rsa Your public key has been saved in /home/ubuntu/.ssh/id_rsa.pub The key fingerprint is: SHA256:hVkOnzk7nLWx3j4vqLv/B83tYN7w3juLAbFw610xh7Q ubuntu@CSALEM The key's randomart image is: +---[RSA 3072]----+ | . . . | | B o . o | | o.Boo Eo.| | oo=++ +| | S =+o +.| | .oo.* +| | ..*.B | | ..*.*| | +=.ooOB| +----[SHA256]-----+
Примечание
Для использования команды ssh-keygen в вашей системе должен быть установлен пакет OpenSSH.
Как просмотреть ключ SSH
Первый метод, который вы можете использовать для просмотра своего ключа SSH, — это использовать простую команду cat. Эта команда распечатает содержимое файла, которое вы можете скопировать и вставить на удаленный хост. По умолчанию ключи SSH хранятся в /home/$USER/.ssh
Для просмотра содержимого:
cd ~/.ssh cat id_rsa.pub
Приведенная выше команда распечатает содержимое вашего открытого ключа SSH. Ниже приведен пример ключа:
ssh-rsa AAAAB3NzaC1yc2EAAAADAQABAAABgQC4P7J4iUnK+lbKeBxEJqgBaapI6/tr2we9Ipr9QzYvAIzOyS396uYRhUldTL0sios0BlCes9k9FEU8/ZFABaPlvr/UcM/vBlVpEv1uCkq1Rg48bK8nWuCBcLmy2B+MUoiXT/0W51qT2fSYRUk0fafnxvBnqRidRdOpRLi48CzvsSua+tU5AciEuYJ+L4X32UF2sHe6o+GzAyItK5ZzpneiEPfoHUSJ4N7+wUcrTI52NPrHmH11jzLPpMHxoqiDBzF2IIVxxU1GSioGAij7T5Sf6aWDOnBHnpeJBFujChg+p2WPlha+B2NaCt25eBtwPMMFQqmJ38xoPr1BCtF6ViOR1e2e7rk/+XMLuY67U8mawhJbl6IqfzRtn5C8dP6vGqMg30kW9vIp4GqlbGLMeAyuBsA45rNnVqxtiMXdKcHPvA+Mmbm+7YSXzoyQcuRUzJY9K+Y+ty7XQP09HGvT7bvtFvC5B9wWAqt5qgmTToLp7qHLCXK+m/6rpJp7d57tGv0= ubuntu@UBUNTU
Другой метод, который вы можете использовать для просмотра содержимого вашего SSH-ключа, — это использование инструмента аутентификации Open-SSH с помощью команды, показанной ниже:
ssh-agent sh -c "ssh-add; ssh-add -L"
Эта команда запросит у вас пароль аутентификации для парольной фразы, если она назначена, как показано ниже:
Enter passphrase for /home/ubuntu/.ssh/id_rsa: Identity added: /home/ubuntu/.ssh/id_rsa (ubuntu@CSALEM) ssh-rsa AAAAB3NzaC1yc2EAAAADAQABAAABgQC4P7J4iUnK+lbKeBxEJqgBaapI6/tr2we9Ipr9QzYvAIzOyS396uYRhUldTL0sios0BlCes9k9FEU8/ZFABaPlvr/UcM/vBlVpEv1uCkq1Rg48bK8nWuCBcLmy2B+MUoiXT/0W51qT2fSYRUk0fafnxvBnqRidRdOpRZtxMLOj7Sua+tU5AciEuYJ+L4X32UF2sHe6o+GzAyItK5ZzpneiEPfoHUSJ4N7+wUcrTI52NPrHmH11jzLPpMHxoqiDBzF2IIVxxU1GSioGAij7T5Sf6aWDOnBHnpeJBFujChg+p2WPlha+B2NaCt25eBtwPMMFQqmJ38xoPr1BCtF6ViOR1e2e7rk/+XML3ypZU8mawhJbl6IqfzRtn5C8dP6vGqMg30kW9vIp4GqlbGLMeAyuBsA45rNnVqxtiMXdKcHPvA+Mmbm+7YSXzoyQcuRUzJY9K+Y+ty7XQPmwYgvLo7G78vC5B9wWAqt5qgmTToLp7qHLCXK+m/6rpJp7d57tGv0= ubuntu@UBUNTU
Заключение
В этой статье показано, как сгенерировать ключ SSH, а также два метода, которые можно использовать для просмотра содержимого ключа SSH. По большей части вам нужно будет только просматривать содержимое открытых ключей, а не закрытых ключей. Всегда следите за тем, чтобы ваши ключи SSH всегда были защищены. Защитите свою оболочку!
Если вы нашли ошибку, пожалуйста, выделите фрагмент текста и нажмите Ctrl+Enter.
abstract: В статье описаны продвинутые функций OpenSSH, которые позволяют сильно упростить жизнь системным администраторам и программистам, которые не боятся шелла. В отличие от большинства руководств, которые кроме ключей и -L/D/R опций ничего не описывают, я попытался собрать все интересные фичи и удобства, которые с собой несёт ssh.
Предупреждение: пост очень объёмный, но для удобства использования я решил не резать его на части.
Оглавление:
- управление ключами
- копирование файлов через ssh
- Проброс потоков ввода/вывода
- Монтирование удалённой FS через ssh
- Удалённое исполнение кода
- Алиасы и опции для подключений в .ssh/config
- Опции по-умолчанию
- Проброс X-сервера
- ssh в качестве socks-proxy
- Проброс портов — прямой и обратный
- Реверс-сокс-прокси
- туннелирование L2/L3 трафика
- Проброс агента авторизации
- Туннелирование ssh через ssh сквозь недоверенный сервер (с большой вероятностью вы этого не знаете)
Управление ключами
Теория в нескольких словах: ssh может авторизоваться не по паролю, а по ключу. Ключ состоит из открытой и закрытой части. Открытая кладётся в домашний каталог пользователя, «которым» заходят на сервер, закрытая — в домашний каталог пользователя, который идёт на удалённый сервер. Половинки сравниваются (я утрирую) и если всё ок — пускают. Важно: авторизуется не только клиент на сервере, но и сервер по отношению к клиенту (то есть у сервера есть свой собственный ключ). Главной особенностью ключа по сравнению с паролем является то, что его нельзя «украсть», взломав сервер — ключ не передаётся с клиента на сервер, а во время авторизации клиент доказывает серверу, что владеет ключом (та самая криптографическая магия).
Генерация ключа
Свой ключ можно сгенерировать с помощью команды ssh-keygen. Если не задать параметры, то он сохранит всё так, как надо.
Ключ можно закрыть паролем. Этот пароль (в обычных графических интерфейсах) спрашивается один раз и сохраняется некоторое время. Если пароль указать пустым, он спрашиваться при использовании не будет. Восстановить забытый пароль невозможно.
Сменить пароль на ключ можно с помощью команды ssh-keygen -p.
Структура ключа
(если на вопрос про расположение ответили по-умолчанию).
~/.ssh/id_rsa.pub — открытый ключ. Его копируют на сервера, куда нужно получить доступ.
~/.ssh/id_rsa — закрытый ключ. Его нельзя никому показывать. Если вы в письмо/чат скопипастите его вместо pub, то нужно генерировать новый ключ. (Я не шучу, примерно 10% людей, которых просишь дать ssh-ключ постят id_rsa, причём из этих десяти процентов мужского пола 100%).
Копирование ключа на сервер
В каталоге пользователя, под которым вы хотите зайти, если создать файл ~/.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/
Обратно тоже можно:
scp user@8.8.8.8:/full/path/to/file /path/to/put/here
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
Делаем файл +x, вызываем, идём в любое приложение, говорим сохранить и видим:
Параметры sshfs, которые могут оказаться важными: -o reconnect (говорит пытаться пересоединиться вместо ошибок).
Если вы много работаете с данными от рута, то можно (нужно) сделать idmap:
-o idmap=user. Работает она следующим образом: если мы коннектимся как пользователь pupkin@server, а локально работаем как пользователь vasiliy, то мы говорим «считать, что файлы pupkin, это файлы vasiliy». ну или «root», если мы коннектимся как root.
В моём случае idmap не нужен, так как имена пользователей (локальное и удалённое) совпадают.
Заметим, комфортно работать получается только если у нас есть ssh-ключик (см. начало статьи), если нет — авторизация по паролю выбешивает на 2-3 подключение.
Отключить обратно можно командой fusermount -u /path, однако, если соединение залипло (например, нет сети), то можно/нужно делать это из-под рута: sudo umount -f /path.
Удалённое исполнение кода
ssh может выполнить команду на удалённом сервере и тут же закрыть соединение. Простейший пример:
ssh user@server ls /etc/
Выведет нам содержимое /etc/ на server, при этом у нас будет локальная командная строка.
Некоторые приложения хотят иметь управляющий терминал. Их следует запускать с опцией -t:
ssh user@server -t remove_command
Кстати, мы можем сделать что-то такого вида:
ssh user@server cat /some/file|awk '{print $2}' |local_app
Это нас приводит следующей фиче:
Проброс stdin/out
Допустим, мы хотим сделать запрос к программе удалённо, а потом её вывод поместить в локальный файл
ssh user@8.8.8.8 command >my_file
Допустим, мы хотим локальный вывод положить удалённо
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 -c * | ssh user@server "cd && tar -x"
Tar запаковывает файлы по маске локально, пишет их в stdout, откуда их читает ssh, передаёт в stdin на удалённом сервере, где их cd игнорирует (не читает stdin), а tar — читает и распаковывает. Так сказать, scp для бедных.
Алиасы
Скажу честно, до последнего времени не знал и не использовал. Оказались очень удобными.
В более-менее крупной компании часто оказывается, что имена серверов выглядят так: spb-MX-i3.extrt.int.company.net. И пользователь там не равен локальному. То есть логиниться надо так: ssh ivanov_i@spb-MX-i3.extrt.int.company.net. Каждый раз печатать — туннельных синдромов не напасёшься. В малых компаниях проблема обратная — никто не думает о DNS, и обращение на сервер выглядит так: ssh root@192.168.1.4. Короче, но всё равно напрягает. Ещё большая драма, если у нас есть нестандартный порт, и, например, первая версия ssh (привет цискам). Тогда всё выглядит так: ssh -1 -p 334 vv_pupkin@spb-MX-i4.extrt.int.company.net. Удавиться. Про драму с scp даже рассказывать не хочется.
Можно прописать общесистемные alias’ы на IP (/etc/hosts), но это кривоватый выход (и пользователя и опции всё равно печатать). Есть путь короче.
Файл ~/.ssh/config позволяет задать параметры подключения, в том числе специальные для серверов, что самое важное, для каждого сервера своё. Вот пример конфига:
Host ric
Hostname ооо-рога-и-копыта.рф
User Администратор
ForwardX11 yes
Compression yes
Host home
Hostname myhome.dyndns.org
User vasya
PasswordAuthentication no
Все доступные для использования опции можно увидеть в man ssh_config (не путать с sshd_config).
Опции по умолчанию
По подсказке UUSER: вы можете указать настройки соединения по умолчанию с помощью конструкции Host *, т.е., например:
Host * User root Compression yes
То же самое можно сделать и в /etc/ssh/ssh_config (не путать с /etc/ssh/sshd_config), но это требует прав рута и распространяется на всех пользователей.
Проброс X-сервера
Собственно, немножко я проспойлерил эту часть в примере конфига выше. ForwardX11 — это как раз оно.
Теория: Графические приложения в юникс обычно используют X-сервер (wayland в пути, но всё ещё не готов). Это означает, что приложение запускается и подключается к X-серверу для рисования. Иными словами, если у вас есть голый сервер без гуя и есть локальный x-сервер (в котором вы работаете), то вы можете дать возможность приложениям с сервера рисовать у вас на рабочем столе. Обычно подключение к удалённом X-серверу — не самая безопасная и тривиальная вещь. SSH позволяет упростить этот процесс и сделать его совсем безопасным. А возможность жать трафик позволяет ещё и обойтись меньшим трафиком (т.е. уменьшить утилизацию канала, то есть уменьшить ping (точнее, latency), то есть уменьшить лаги).
Ключики: -X — проброс X-сервера. -Y проброс авторизации.
Достаточно просто запомнить комбинацию ssh -XYC user@SERVER.
В примере выше (названия компании вымышленные) я подключаюсь к серверу ооо-рога-и-копыта.рф не просто так, а с целью получить доступ к windows-серверу. Безопасность microsoft при работе в сети мы все хорошо знаем, так что выставлять наружу голый RDP неуютно. Вместо этого мы подключаемся к серверу по ssh, а дальше запускаем там команду rdesktop:
ssh ric
rdesktop -k en-us 192.168.1.1 -g 1900x1200
и чудо, окошко логина в windows на нашем рабочем столе. Заметим, тщательно зашифрованное и неотличимое от обычного ssh-трафика.
Socks-proxy
Когда я оказываюсь в очередной гостинице (кафе, конференции), то местный wifi чаще всего оказывается ужасным — закрытые порты, неизвестно какой уровень безопасности. Да и доверия к чужим точкам доступа не особо много (это не паранойя, я вполне наблюдал как уводят пароли и куки с помощью банального ноутбука, раздающего 3G всем желающим с названием близлежащей кафешки (и пишущего интересное в процессе)).
Особые проблемы доставляют закрытые порты. То джаббер прикроют, то IMAP, то ещё что-нибудь.
Обычный VPN (pptp, l2tp, openvpn) в таких ситуациях не работает — его просто не пропускают. Экспериментально известно, что 443ий порт чаще всего оставляют, причём в режиме CONNECT, то есть пропускают «как есть» (обычный http могут ещё прозрачно на сквид завернуть).
Решением служит socks-proxy режим работы ssh. Его принцип: ssh-клиент подключается к серверу и слушает локально. Получив запрос, он отправляет его (через открытое соединение) на сервер, сервер устанавливает соединение согласно запросу и все данные передаёт обратно ssh-клиенту. А тот отвечает обратившемуся. Для работы нужно сказать приложениям «использовать socks-proxy». И указать IP-адрес прокси. В случае с ssh это чаще всего localhost (так вы не отдадите свой канал чужим людям).
Подключение в режиме sock-proxy выглядит так:
ssh -D 8080 user@server
В силу того, что чужие wifi чаще всего не только фиговые, но и лагливые, то бывает неплохо включить опцию -C (сжимать трафик). Получается почти что opera turbo (только картинки не жмёт). В реальном сёрфинге по http жмёт примерно в 2-3 раза (читай — если вам выпало несчастье в 64кбит, то вы будете мегабайтные страницы открывать не по две минуты, а секунд за 40. Фигово, но всё ж лучше). Но главное: никаких украденных кук и подслушанных сессий.
Я не зря сказал про закрытые порты. 22ой порт закрывают ровно так же, как «не нужный» порт джаббера. Решение — повесить сервер на 443-й порт. Снимать с 22 не стоит, иногда бывают системы с DPI (deep packet inspection), которые ваш «псевдо-ssl» не пустят.
Вот так выглядит мой конфиг:
/etc/ssh/sshd_config:
(фрагмент)
Port 22
Port 443
А вот кусок ~/.ssh/config с ноутбука, который описывает vpn
Host vpn
Hostname desunote.ru
User vasya
Compression yes
DynamicForward 127.1:8080
Port 443
(обратите внимание на «ленивую» форму записи localhost — 127.1, это вполне себе законный метод написать 127.0.0.1)
Проброс портов
Мы переходим к крайне сложной для понимания части функционала SSH, позволяющей осуществлять головоломные операции по туннелированию TCP «из сервера» и «на сервер».
Для понимания ситуации все примеры ниже будут ссылаться на вот эту схему:
Комментарии: Две серые сети. Первая сеть напоминает типичную офисную сеть (NAT), вторая — «гейтвей», то есть сервер с белым интерфейсом и серым, смотрящим в свою собственную приватную сеть. В дальнейших рассуждениях мы полагаем, что «наш» ноутбук — А, а «сервер» — Б.
Задача
: у нас локально запущено приложение, нам нужно дать возможность другому пользователю (за пределами нашей сети) посмотреть на него.
Решение: проброс локального порта (127.0.0.1:80) на публично доступный адрес. Допустим, наш «публично доступный» Б занял 80ый порт чем-то полезным, так что пробрасывать мы будем на нестандартный порт (8080).
Итоговая конфигурация: запросы на 8.8.8.8:8080 будут попадать на localhost ноутбука А.
ssh -R 127.1:80:8.8.8.8:8080 user@8.8.8.8
Опция -R позволяет перенаправлять с удалённого (Remote) сервера порт на свой (локальный).
Важно: если мы хотим использовать адрес 8.8.8.8, то нам нужно разрешить GatewayPorts в настройках сервера Б.
Задача
. На сервере «Б» слушает некий демон (допустим, sql-сервер). Наше приложение не совместимо с сервером (другая битность, ОС, злой админ, запрещающий и накладывающий лимиты и т.д.). Мы хотим локально получить доступ к удалённому localhost’у.
Итоговая конфигурация: запросы на localhost:3333 на ‘A’ должны обслуживаться демоном на localhost:3128 ‘Б’.
ssh -L 127.1:3333:127.1:3128 user@8.8.8.8
Опция -L позволяет локальные обращения (Local) направлять на удалённый сервер.
Задача
: На сервере «Б» на сером интерфейсе слушает некий сервис и мы хотим дать возможность коллеге (192.168.0.3) посмотреть на это приложение.
Итоговая конфигурация: запросы на наш серый IP-адрес (192.168.0.2) попадают на серый интерфейс сервера Б.
ssh -L 192.168.0.2:8080:10.1.1.1:80 user@8.8.8.8
Вложенные туннели
Разумеется, туннели можно перенаправлять.
Усложним задачу: теперь нам хочется показать коллеге приложение, запущенное на localhost на сервере с адресом 10.1.1.2 (на 80ом порту).
Решение сложно:
ssh -L 192.168.0.2:8080:127.1:9999 user@8.8.8.8 ssh -L 127.1:9999:127.1:80 user2@10.1.1.2
Что происходит? Мы говорим ssh перенаправлять локальные запросы с нашего адреса на localhost сервера Б и сразу после подключения запустить ssh (то есть клиента ssh) на сервере Б с опцией слушать на localhost и передавать запросы на сервер 10.1.1.2 (куда клиент и должен подключиться). Порт 9999 выбран произвольно, главное, чтобы совпадал в первом вызове и во втором.
Реверс-сокс-прокси
Если предыдущий пример вам показался простым и очевидным, то попробуйте догадаться, что сделает этот пример:
ssh -D 8080 -R 127.1:8080:127.1:8080 user@8.8.8.8 ssh -R 127.1:8080:127.1:8080 user@10.1.1.2
Если вы офицер безопасности, задача которого запретить использование интернета на сервере 10.1.1.2, то можете начинать выдёргивать волосы на попе, ибо эта команда организует доступ в интернет для сервера 10.1.1.2 посредством сокс-прокси, запущенного на компьютере «А». Трафик полностью зашифрован и неотличим от любого другого трафика SSH. А исходящий трафик с компьютера с точки зрения сети «192.168.0/24» не отличим от обычного трафика компьютера А.
Туннелирование
Если к этому моменту попа отдела безопасности не сияет лысиной, а ssh всё ещё не внесён в список врагов безопасности номер один, вот вам окончательный убийца всего и вся: туннелирование IP или даже ethernet. В самых радикальных случаях это позволяет туннелировать dhcp, заниматься удалённым arp-спуфингом, делать wake up on lan и прочие безобразия второго уровня.
Подробнее описано тут: www.khanh.net/blog/archives/51-using-openSSH-as-a-layer-2-ethernet-bridge-VPN.html
(сам я увы, таким не пользовался).
Легко понять, что в таких условиях невозможно никаким DPI (deep packet inspection) отловить подобные туннели — либо ssh разрешён (читай — делай что хочешь), либо ssh запрещён (и можно смело из такой компании идиотов увольняться не ощущая ни малейшего сожаления).
Проброс авторизации
Если вы думаете, что на этом всё, то…… впрочем, в отличие от автора, у которого «снизу» ещё не написано, читатель заранее видит, что там снизу много букв и интриги не получается.
OpenSSH позволяет использовать сервера в качестве плацдарма для подключения к другим серверам, даже если эти сервера недоверенные и могут злоупотреблять чем хотят.
Для начала о простом пробросе авторизации.
Повторю картинку:
Допустим, мы хотим подключиться к серверу 10.1.1.2, который готов принять наш ключ. Но копировать его на 8.8.8.8 мы не хотим, ибо там проходной двор и половина людей имеет sudo и может шариться по чужим каталогам. Компромиссным вариантом было бы иметь «другой» ssh-ключ, который бы авторизовывал user@8.8.8.8 на 10.1.1.2, но если мы не хотим пускать кого попало с 8.8.8.8 на 10.1.1.2, то это не вариант (тем паче, что ключ могут не только поюзать, но и скопировать себе «на чёрный день»).
ssh предлагает возможность форварда ssh-агента (это такой сервис, который запрашивает пароль к ключу). Опция ssh -A пробрасывает авторизацию на удалённый сервер.
Вызов выглядит так:
ssh -A user@8.8.8.8 ssh user2@10.1.1.2
Удалённый ssh-клиент (на 8.8.8.8) может доказать 10.1.1.2, что мы это мы только если мы к этому серверу подключены и дали ssh-клиенту доступ к своему агенту авторизации (но не ключу!).
В большинстве случаев это прокатывает.
Однако, если сервер совсем дурной, то root сервера может использовать сокет для имперсонализации, когда мы подключены.
Есть ещё более могучий метод — он превращает ssh в простой pipe (в смысле, «трубу») через которую насквозь мы осуществляем работу с удалённым сервером.
Главным достоинством этого метода является полная независимость от доверенности промежуточного сервера. Он может использовать поддельный ssh-сервер, логгировать все байты и все действия, перехватывать любые данные и подделывать их как хочет — взаимодействие идёт между «итоговым» сервером и клиентом. Если данные оконечного сервера подделаны, то подпись не сойдётся. Если данные не подделаны, то сессия устанавливается в защищённом режиме, так что перехватывать нечего.
Эту клёвую настройку я не знал, и раскопал её redrampage.
Настройка завязана на две возможности ssh: опцию -W (превращающую ssh в «трубу») и опцию конфига ProxyCommand (опции командной строки, вроде бы нет), которая говорит «запустить программу и присосаться к её stdin/out». Опции эти появились недавно, так что пользователи centos в пролёте.
Выглядит это так (циферки для картинки выше):
.ssh/config:
Host raep
HostName 10.1.1.2
User user2
ProxyCommand ssh -W %h:%p user@8.8.8.8
Ну а подключение тривиально: ssh raep.
Повторю важную мысль: сервер 8.8.8.8 не может перехватить или подделать трафик, воспользоваться агентом авторизации пользователя или иным образом изменить трафик. Запретить — да, может. Но если разрешил — пропустит через себя без расшифровки или модификации. Для работы конфигурации нужно иметь свой открытый ключ в authorized_keys как для user@8.8.8.8, так и в user2@10.1.1.2
Разумеется, подключение можно оснащать всеми прочими фенечками — прокидыванием портов, копированием файлов, сокс-прокси, L2-туннелями, туннелированием X-сервера и т.д.
Финал
Разумеется, в посте про туннели должен быть туннель, а в любой успешной статье — секретный ингредиент всеобщей популярности. Держите:
Содержание
- Авторизация по ключу SSH
- Как работают ключи SSH?
- Как создать ключи SSH?
- Загрузка ключа на сервер
- Отключение проверки пароля
- Выводы
- Как найти открытый ключ SSH
- Как сгенерировать SSH-ключ
- Как просмотреть ключ SSH
- Заключение
- 🔐 Как просмотреть свои SSH-ключи на Linux, macOS и Windows
- Что вам понадобится
- Как посмотреть свой открытый ключ SSH на Linux
- Как посмотреть свой открытый ключ SSH на macOS
- Как посмотреть свой открытый ключ SSH на Windows
- Как посмотреть свой закрытый ключ
- SSH: RSA-ключи и ssh-agent — управление SSH-ключами и их паролями
- ssh-agent
- Запуск агента
- Примеры
- ssh-add
- Could not open a connection to your authentication agent
- Добавление ключа
- Проверка ключей в агенте
- Удаление ключа
- Автоматическое добавление в ssh-agent
- Запуск ssh-agent и несколько консолей
- systemd
- HackWare.ru
- Этичный хакинг и тестирование на проникновение, информационная безопасность
- SSH (ч.4): Создание и настройка ключей OpenSSH
- Оглавление
- Вход в SSH без пароля (с использованием файлов ключей)
- Типы ключей
- Утилита ssh-keygen
- Как поменять количество битов в ключах ssh-keygen
- Добавление комментариев в ключи ssh-keygen
- Изменение паролей в ssh-keygen
- Показ публичного ключа из приватного
- Управление приватными ключами на клиенте SSH
- Управление публичными ключами на сервере SSH
Авторизация по ключу SSH
Как работают ключи SSH?
Каждая пара ключей состоит из открытого и закрытого ключа. Секретный ключ сохраняется на стороне клиента и не должен быть доступен кому-либо еще. Утечка ключа позволит злоумышленнику войти на сервер, если не была настроена дополнительная аутентификация по паролю.
Открытый ключ используется для шифрования сообщений, которые можно расшифровать только закрытым ключом. Это свойство и используется для аутентификации с помощью пары ключей. Открытый ключ загружается на удаленный сервер, к которому необходимо получить доступ. Его нужно добавить в специальный файл
Как создать ключи SSH?
Сначала необходимо создать ключи ssh для аутентификации на локальном сервере. Для этого существует специальная утилита ssh-keygen, которая входит в набор утилит OpenSSH. По умолчанию она создает пару 2048 битных RSA ключей, которая подойдет не только для SSH, но и для большинства других ситуаций.
И так, генерация ключей ssh выполняется командой:
Утилита предложит вам выбрать расположение ключей. По умолчанию ключи располагаются в папке
/.ssh/. Лучше ничего не менять, чтобы все работало по умолчанию и ключи автоматически подхватывались. Секретный ключ будет называться id_rsa, а публичный id_rsa.pub.
Но все же, это необязательное дополнение и если не хотите, то вы можете просто нажать Enter. Тогда доступ по ключу ssh будет выполняться автоматически и вам не нужно будет что-либо вводить.
Теперь у вас есть открытый и закрытый ключи SSH и вы можете использовать их для проверки подлинности. Дальше нам осталось разместить открытый ключ на удаленном сервере.
Загрузка ключа на сервер
Когда генерация ключей завершена, нам осталось только загрузить ключ на сервер. Для загрузки ключа можно использовать несколько способов. В некоторых случаях вы можете указать ключ в панели управления сервером, например, сPanel или любой другой. Но мы такой способ рассматривать не будем. Мы рассмотрим ручные способы.
При первом подключении к серверу система может его не распознать, поэтому вам нужно ввести yes. Затем введите ваш пароль пользователя на удаленном сервере. Утилита подключится к удаленному серверу, а затем использует содержимое ключа id.rsa.pub для загрузки его на сервер в файл
/.ssh/authorized_keys. Дальше вы можете выполнять аутентификацию с помощью этого ключа.
Если такой способ по какой-либо причине для вас не работает, вы можете скопировать ключ по ssh вручную. Мы создадим каталог
/.ssh, а затем поместим наш ключ в файл authorized_keys с помощью символа >>, это позволит не перезаписывать существующие ключи:
Здесь вам тоже нужно набрать yes, если вы подключаетесь к новому серверу, а затем ввести пароль. Теперь вы можете использовать созданный ключ для аутентификации на сервере:
Если вы не захотели создать ssh ключ с доступом по паролю, то вы сразу же будете авторизованы, что очень удобно. Иначе, сначала вам придется ввести фразу-пароль для расшифровки ключа.
Отключение проверки пароля
Если пароль больше не будет использоваться, то для увеличения безопасности системы лучше его вовсе отключить. Но убедитесь, что ключ надежно сохранен и вы его не потеряете, потому что по паролю вы больше не войдете. Авторизуйтесь на сервере, затем откройте конфигурационный файл /etc/ssh/sshd_config и найдите там директиву PasswordAuthenticatin. Нужно установить ее значение в No:
sudo vi /etc/ssh/sshd_config
Теперь сохраните файл и перезапустите службу ssh:
sudo service ssh restart
Дальше будет возможно только подключение по ключу ssh, пароль не будет приниматься.
Выводы
В этой статье мы рассмотрели как выполняется авторизация по ключу ssh, настройка ключей ssh и добавить ssh ключ. Теперь вы можете войти на сервер без ввода пароля. Если у вас остались вопросы, спрашивайте в комментариях!
Источник
Как найти открытый ключ SSH
Главное меню » Linux » Как найти открытый ключ SSH
Как сгенерировать SSH-ключ
Первым шагом к настройке ключа SSH является создание пары. Пара ключей SSH содержит открытый и закрытый ключи. Используя общедоступную и частную пару, вы можете аутентифицировать пользователя на удаленном хосте.
В Linux используйте следующую команду для создания пары ключей SSH:
Приведенная выше команда потребует от вас ввода информации для настройки и создания ключей. Если вы находитесь в незащищенных сетях или критических системах, обязательно зашифруйте свои ключи парольной фразой.
Как просмотреть ключ SSH
Первый метод, который вы можете использовать для просмотра своего ключа SSH, – это использовать простую команду cat. Эта команда распечатает содержимое файла, которое вы можете скопировать и вставить на удаленный хост. По умолчанию ключи SSH хранятся в /home/$USER/.ssh
Для просмотра содержимого:
Приведенная выше команда распечатает содержимое вашего открытого ключа SSH. Ниже приведен пример ключа:
Другой метод, который вы можете использовать для просмотра содержимого вашего SSH-ключа, – это использование инструмента аутентификации Open-SSH с помощью команды, показанной ниже:
Эта команда запросит у вас пароль аутентификации для парольной фразы, если она назначена, как показано ниже:
Заключение
В этой статье показано, как сгенерировать ключ SSH, а также два метода, которые можно использовать для просмотра содержимого ключа SSH. По большей части вам нужно будет только просматривать содержимое открытых ключей, а не закрытых ключей. Всегда следите за тем, чтобы ваши ключи SSH всегда были защищены. Защитите свою оболочку!
Если вы нашли ошибку, пожалуйста, выделите фрагмент текста и нажмите Ctrl+Enter.
Источник
🔐 Как просмотреть свои SSH-ключи на Linux, macOS и Windows
Вы знаете, что создали эти сертификаты SSH, но как их посмотреть?
Те, кто знаком с SSH, вероятно, уже знают ответ на этот вопрос.
Для остальных я покажу, насколько легко просмотреть эти ключи SSH, чтобы вы могли использовать их для сторонних служб.
Что вам понадобится
Единственное, что вам понадобится для этого, – это доступ к серверу или рабочему столу (Linux, macOS или Windows) и созданный ключ SSH.
Если вы еще не создали свою пару ключей SSH, вы можете сделать это с помощью команды:
Как посмотреть свой открытый ключ SSH на Linux
Есть два простых способа просмотреть свой открытый ключ SSH на Linux.
Первый метод немного сложен, потому что в нем используются команды ssh-agent и ssh-add.
Вероятно, это излишне для того, что вам нужно, но это хороший способ просмотреть ключ, требуя при этом пароль вашей пары ключей SSH.
После успешной аутентификации ваш открытый ключ SSH будет показан в терминале.
Как посмотреть свой открытый ключ SSH на macOS
Просмотр ключей на macOS можно выполнить аналогично Linux.
Откройте окно терминала и введите команду:
Где USERNAME – ваше имя пользователя macOS.
Приведенные выше команды выведут ваш открытый ключ SSH.
В macOS есть еще один интересный трюк.
Вы можете скопировать содержимое ключа SSH прямо в буфер обмена, не отображая ключ, с помощью инструмента pbcopy.
Эта команда будет следующей:
Как посмотреть свой открытый ключ SSH на Windows
В Windows вы будете использовать команду type для просмотра открытого ключа SSH следующим образом:
Где USERNAME – имя вашего пользователя.
Приведенная выше команда отобразит ваш открытый ключ SSH.
Затем вы можете использовать сочетание клавиш Ctrl + c, чтобы скопировать содержимое файла.
Вы также можете сделать что-то похожее на то, что мы делали в macOS (копирование открытого ключа SSH непосредственно в буфер обмена), используя следующие команды type и clip:
Где USERNAME – ваше имя пользователя.
Теперь вы можете вставить этот ключ в любое место.
Как посмотреть свой закрытый ключ
Скорее всего, вам никогда не придется просматривать свой закрытый ключ.
В конце концов, это секрет, который никогда не выставляется на всеобщее обозрение.
Помните, что id_rsa – это закрытый ключ, а id_rsa.pub – открытый ключ.
И это все, что нужно для просмотра открытых и закрытых ключей SSH в Linux, macOS и Windows.
Источник
SSH: RSA-ключи и ssh-agent — управление SSH-ключами и их паролями
В этом посте посмотрим примеры работы с ssh-agent и то, как можно хранить и управлять запароленными RSA-ключами без таких бекендов.
Примеры выполняются на Arch Linux (и, местами, для проверки — на Manjaro Linux с Budgie DE).
ssh-agent
ssh-agent предназначен для управления SSH-ключами пользователя и их паролями, что бы не вводить пароль к ключу каждый раз при использовании.
Запуск агента
Для работы клиентов важны переменные, которые задаются агентом:
Что бы запустить агента без вывода всей этой информации — используем:
Вариантов запуска много, рассмотрим их в конце, в Запуск ssh-agent и несколько консолей.
Примеры
Создание ключа
Проверка пароля
Смена пароля
Что бы изменить пароль, заня старый:
ssh-copy-id — копирование ключа на сервер
Скопировать ключ можно вручную, получив его публичную часть:
И скопировав содержимое в файл
И пробуем подключиться, используя этот ключ:
ssh-add
Окей, теперь у нас ключ для аутентификации на сервере, и ключ закрыт паролем.
При каждом обращении к серверу — нам придётся вводить пароль заново — Enter passphrase for key ‘/home/setevoy/.ssh/test-key’.
Проверим, что агент запущен:
Could not open a connection to your authentication agent
Самая частая ошибка при использовании агента — когда к нему невозможно подключиться, и ssh-add сообщает:
ssh-agent был запущен в другом терминале (об этом тоже поговорим ниже), поэтому перезапустим его.
Для «чистоты эксперимента» — убиваем запущеные инстансы агента:
И запускаем заново:
Добавление ключа
Проверка ключей в агенте
Удаление ключа
Автоматическое добавление в ssh-agent
Проверяем — сейчас ключей в агенте нет:
Выполняем подключение, вводим пароль ключа:
Отключаемся, проверяем ключи в агенте:
И теперь при повторном подключении — ключ уже будет взят из агента, и пароль вводить не потребуется:
Запуск ssh-agent и несколько консолей
Например, при вызове ssh-add в новом терминале получим уже упомянутую ошибку «Could not open a connection to your authentication agent«:
Вариантов много, например самый простой — добавить в
Но тогда для каждой сессии bash будет запускаться новый агент.
Тут выполняется (см. коды ответа ssh-agent в документации):
Более-менее вариант, т.к. во всех сессиях у нас будет использоваться один и тот же агент (хотя некоторые рекомендуют использовать различных агентов для разных пулов ключей, например для личных ключей — один агент, для рабочих — другой).
systemd
Ещё один вариант — создать systemd unit-файл и запускать ssh-agent как сервис, см. Arch Wiki.
Добавляем каталог, если не создан:
Далее, Wiki говорит про файл
Останавливаем запущенные инстансы агента:
Можно добавить в автозапуск:
Ещё один вариант — запускать из
В таком случае, при вызове startx (как у меня, когда login manager нет, и X.Org запускается вручную, через вызов startx в консоли) будет запущен агент, а затем — Openbox, см. документацию:
Источник
HackWare.ru
Этичный хакинг и тестирование на проникновение, информационная безопасность
SSH (ч.4): Создание и настройка ключей OpenSSH
Оглавление
Вход в SSH без пароля (с использованием файлов ключей)
Вход в SSH по публичному ключу (без пароля) очень удобен и безопасен.
Процесс настройки аутентификации по публичному ключу очень простой:
Публичный ключ, который копируется на удалённый сервер, не является секретным. Один и тот же ключ можно использовать на разных серверах. Главное — хранить в секрете приватный ключ.
Сгененировать ключи и скопировать их на удалённый хост можно буквально тремя командами. Для генерации пары ключей используется программа ssh-keygen, она включена в пакет ssh и если SSH у вас уже настроен, то дополнительно устанавливать ничего не нужно.
У программы ssh-keygen много функций и возможностей, начнём с рассмотрения процедуры генерации ключей, которая выполняется элементарно.
Если вы успели залогиниться на удалённой системе, разлогинтесь. После этого наберите:
У нас спрашивают имя файла, не нужно ничего вводить, будет использовано имя по умолчанию. Также спрашивается пароль. Этот пароль позволяет установить дополнительную защиту — при подключении с помощью ключей не будет спрашиваться пароль пользователя, но будет спрашиваться пароль самого ключа. Устанавливать пароль необязательно.
В результате будет создано два файла:
Первый файл нужно хранить в секрете. Второй файл нужно скопировать на удалённый компьютер, где запущен сервер SSH.
Теперь на удалённой машине нам нужно создать каталог .ssh. В предыдущей части мы уже узнали, как выполнять команды на удалённой системе по SSH. Запустите команду вида:
Теперь нам нужно скопировать содержимое файла id_rsa.pub на удалённую машину в файл
/.ssh/authorized_keys. Сделать это очень просто (не забываем менять данные на свои):
Теперь выполняем подключение с помощью клиента SSH, но пароль у нас больше спрашиваться не будет.
Типы ключей
Программа ssh-keygen можен генерировать четыре типа ключей:
Чтобы выбрать любой из этих типов, используется опция -t. В предыдущем примере мы выбрали rsa — явно указывать тип RSA необязательно, поскольку он подразумевается по умолчанию (то есть генерацию ключей можно запустить вообще без опции -t).
В зависимости от выбранного типа, названия созданных файлов ключей могут различаться:
Эти файлы нужно держать в секрете, они должны быть доступны только для владельца.
Соответствующие публичные ключи будут иметь такое же название, но с дополнительным расширением .pub:
Эти файлы не являются секретными, их содержимое нужно скопировать в файл
/.ssh/authorized_keys на компьютер с сервером SSH.
Утилита ssh-keygen
Мы применили ssh-keygen для генерации ключей. Кроме этого она предназначена для управления и конвертации ключей аутентификации для ssh.
Далее рассмотрены только некоторые функции этой программы, с полным перечнем опций можно ознакомиться командой:
Как поменять количество битов в ключах ssh-keygen
Для этого используется опция: -b БИТЫ
Она определяет количество бит в создаваемом ключе. Для ключей RSA минимальный размер составляет 1024 бита, а по умолчанию — 2048 бит. Как правило, 2048 бит считается достаточным. Ключи DSA должны иметь длину 1024 бита, как указано в FIPS 186-2. Для ключей ECDSA флаг -b определяет длину ключа, выбирая один из трёх размеров эллиптической кривой: 256, 384 или 521 бит. Попытка использовать битовые длины, отличные от этих трёх значений, для ключей ECDSA потерпит неудачу. Ключи Ed25519 имеют фиксированную длину, и флаг -b будет игнорироваться.
Добавление комментариев в ключи ssh-keygen
Для работы с комментариями имеется две опции:
-C комментарий
После этой опции укажите комментарий.
Эта опция включает процесс изменений комментария в файлах приватного и публичного ключей. Программа сделает запрос на файл, содержащий приватные ключи, пароль (если он установлен) и затем предложит ввести новый комментарий.
Увидеть комментарий можно с помощью опции -l. Эта опция показывает отпечаток указанного файла публичного ключа. Для RSA и DSA ключей ssh-keygen пытается найти совпадающий файл публичного ключа и вывести его отпечаток. Если совместить с -v, то визуальное художественное представление ASCII будет показано после самого отпечатка:
Файл ключа можно указать явно опцией -f:
Изменение паролей в ssh-keygen
Для работы с паролями имеется несколько опций:
-P парольная фраза
Этой опцией можно передать пароль, чтобы программа его не спрашивала. При смене пароля, этой опцией передаётся старый пароль.
Эта опция вместо создания нового ключа, запускает смену парольной фразы файла приватного ключа. Программа сделает запрос, где размещён файл приватного ключа, затем спросит старый пароль и попросит дважды ввести новую парольную фразу.
-N новый_пароль
Этой опцией можно передать новый пароль, чтобы программа его не спрашивала. При создании ключей можно использовать эту опцию для указания паролей, чтобы программа не спрашивала их в интерактивном режиме.
Файл ключей нужно указать опцией -f:
Показ публичного ключа из приватного
Опция -y прочитает файл OpenSSH формата с приватным ключом и напечатает в стандартный вывод публичный ключ OpenSSH.
Также с помощью опции -f нужно указать путь до приватного ключа, из которого будет извлечён соответствующий ему публичный ключ:
Например, приватный ключ помещён в файл id_rsa, тогда команда извлечения из него публичного ключа следующая:
Вы можете столкнуться с ошибкой:
Она означает, что приватный ключ доступен для чтения кому угодно и программа ssh-keygen отказывается работать с ним по этой причине. Чтобы исправить эту ошибку, просто установите на файл с приватным ключом права доступа 600:
Управление приватными ключами на клиенте SSH
Одну и ту же пару ключей можно использовать для доступа к множеству серверов SSH. Следовательно, на каждом из них (на клиенте и на серверах) может быть по одному ключу. Тем не менее если у вас несколько ключей или если вы хотите использовать другое, не стандартное расположение файлов ключей, то далее показано, как указать расположения в строке команды и в конфигурационных файлах клиента SSH.
В конфигурационном файле клиента SSH для указания пути до приватных ключей используется директива IdentityFile. Её значения по умолчанию:
Как можно увидеть, разрешено использовать тильду для указания на домашнюю папку пользователя.
Можно иметь несколько директив IdentityFile в конфигурационных файлах; все эти идентификаторы будут опробованы по очереди. Множественные директивы IdentityFile добавят кандидатов в очередь для попыток (это поведение отличается от других конфигурационных директив).
Также можно настроить использование определённых идентификационных файлов для определённых хостов:
Для строки команды используется опция -i, после которой нужно указать путь до приватного ключа (файла идентификации). Значение по умолчанию такие же, как и у рассмотренной выше директивы. Опцию -i можно использовать несколько раз.
Управление публичными ключами на сервере SSH
Публичные ключи всех видов размещены в одном файле, значение по умолчанию:
По умолчанию проверяются файлы:
Каждая строка файла содержит один ключ (пустые строки, и строки начинающиеся с ‘#’ игнорируются как комментарии). Публичные ключи состоят из следующих разделённых пробелами полей: опции, тип ключа, ключ в кодировке base64, комментарий.
Поле с опциями является необязательным.
Тип ключа это “ecdsa-sha2-nistp256”, “ecdsa-sha2-nistp384”, “ecdsa-sha2-nistp521”, “ssh-ed25519”, “ssh-dss” или “ssh-rsa”.
Поле комментария ни для чего не используется (но может быть удобным для пользоватетля идентифицировать ключ).
Ключ .ppk генерируется при экспорте ключей из PuTTY.
Пример файла .ppk:
Для конвертации формата .ppk в формат OpenSSH можно использовать утилиту puttygen, которая включена в пакет Putty. Следовательно, нам нужно установить PuTTY
Linux: с вашим менеджером пакетов установите PuTTY (или более минимальный пакет PuTTY-tools):
Debian, Kali Linux, Linux Mint, Ubuntu и их производные:
Дистрибутивы на основе RPM:
Arch Linux, BlackArch и их производные:
OS X: Установите Homebrew, затем запустите
Поместите ваши ключи в какую-нибудь директорию, например, в домашнюю папку. Теперь конвертируем PPK ключи в SSH пару.
Для извлечения приватного ключа:
и для извлечения публичного ключа:
Переместите эти ключи в
/.ssh и убедитесь, что для приватного ключа ограничены права записи:
Вы сразу увидите публичный ключ SSH, который вы можете скопировать и вставить в файл.
Теперь в меню перейдите в «Conversions» → «Export OpenSSH key» и сохраните приватный ключ.
Скопируйте ваш приватный ключ в файл
/.ssh/id_dsa (или id_rsa).
Источник
