Почти всички модерни Linux дистрибуции поддържат генерирането на двойка ключове по следните алгоритми (дължината на ключовете, препоръчани по-долу, отговяря на съвремените нива на сигурност):

• ed25519 (256-битов ключ):

  Изпълнението на командния ред:

  $ ssh-keygen -t ed25519

  ще създаде файловете ~/.ssh/id_ed25519 и ~/.ssh/id_ed25519.pub.

• ecdsa (384-битов ключ или по-дълъг):

  Изпълнението на командния ред:

  $ ssh-keygen -b 384 -t ecdsa

  ще създаде файловете ~/.ssh/id_ecdsa и ~/.ssh/id_ecdsa.pub.

• rsa (2048-битов ключ или по-дълъг), опционално:

  Изпълнението на командния ред:

  $ ssh-keygen -b 2048 -t rsa

  ще създаде файловете ~/.ssh/id_rsa и ~/.ssh/id_rsa.pub.

Имайте предвид, че файловете, които са създадени на база на изпълнението на горните командни редове, имат chmod 0600.

Файловете с разширение *.pub съдържат публичния ключ от двойката ключове. Файловете без разширение *.pub съдържат двойката ключове (частния и публичния) в криптиран блок. Ако имате на разположение само файловете без разширение *.pub, може да "извадите" публичния ключ като следвате инструкцииите в "Екстракция на публичния ключ от криптирания блок съдържащ двойката ключове".

Първите два алгоритъма следва да се предпочитани, доколкото те използват по-къси ключове, чиято сигурност е почти същата, която се постига при използването на дълги RSA SSH ключове (използването на по-къси ключове ускорява процеса на удостоверяване).

Имайте предвид следното: при удостоверяване пред отдалечен SSH сървър, SSH клиентът чете само файловете без разширение *.pub (т.е. ако се следва горния пример, той ще чете ~/.ssh/id_ed25519, ~/.ssh/id_ecdsa и опционално (ако сте решили да използвате RSA) ~/.ssh/id_rsa). Тези файлове, съдържащи публичния ключ, се поставят като средство за удостоверяване в потребителския ви профил на отдалечения SSH сървър. Това означава, че когато искате да ги използвате за тази цел, трябва да дадете копие от поне един от тези *.pub файлове на администратора на отдалечения SSH сървър.

По подразбиране, инструментът ssh-keygen криптира частния ключ, съхранен във файловете ~/.ssh/id_ed25519, ~/.ssh/id_ecdsa и опционално (ако сте решили да използвате RSA) ~/.ssh/id_rsa, чрез шифъра AES-128-CBC (шифър, предоставян от библиотеките на OpenSSL). Въпреки, че съвременият криптоанализ все още класифицира AES-128-CBC като безопасен шифър, е добре да увеличите защитата на частния ключ като смените този шифър (по възможност) веднага след генериране на двойката ключове. Смяната на шифъра от такъв с 128-битов ключ към друг, поддържащ 256-битов ключ, става така (примера по-долу е за ~/.ssh/id_ed25519, но важи и за ~/.ssh/id_ecdsa и ~/.ssh/id_rsa - просто сменете името на файла в командия ред):

$ touch ~/.ssh/id_ed25519.256 && chmod 600 ~/.ssh/id_ed25519.256
$ openssl ec -in ~/.ssh/id_ed25519 -out ~/.ssh/id_ed25519.256 -aes-256-cbc

Ще трябва първо да въведете паролата за защита на ключа в стария файл, а след това новата - за защита на ключа в новия файл.

read EC key
Enter PEM pass phrase: въведете паролата за защита на ключа в стария файл
writing EC key
Enter PEM pass phrase: въведете паролата за защита на ключа в новия файл (първи път)
Verifying - Enter PEM pass phrase: въведете паролата за защита на ключа в новия файл (втори път)

Проверете съдържанието на новия файл, отваряйки го с текстов редактор (или с cat). Трябва да виждате структура подобна на тази:

-----BEGIN EC PRIVATE KEY-----
Proc-Type: 4,ENCRYPTED
DEK-Info: AES-256-CBC,FAD89DDF4DFB4BD1607534B40C904464

DDe5Q6UlYj58DEDDR0Mdh5RRnkIUcJyqzRfKiyQCYCBwszIYEfT+FPsYxNm6fyGp
...
FI852Qpc8JvalDYFkJQ/VFfdkhittD6vfA8u3m+rYAg=
-----END EC PRIVATE KEY-----

Ако не виждате подобна структура, то най-вероятно е възникнал проблем при смяната на шифъра! Проверете дали не сте сгрешили при изпълнението на командния ред.

Ако съдържанието отговаря на показания по-горе шаблон, то смяната на шифъра е успешна. В този случай, може да изтриете стария файл и да го замените с новия:

$ mv ~/.ssh/id_ed25519.256 ~/.ssh/id_ed25519

ВНИМАНИЕ! Свързвайте се само към отдалечени SSH сървъри, чиято идентичност може да проверите!

Изтеглете копие от SSH ключовете на отдалечения SSH сървър (обикновено са повече от един), с помощта на инструмента ssh-keyscan, използвайки примерните командни редове даден по-долу (там заменете host.example.com с актуалното име на сървъра):

$ ssh-keyscan -t ed25519 host.example.com > /tmp/ssh_remote_ed25519_key.tmp 2>&1
$ ssh-keyscan -t ecdsa host.example.com > /tmp/ssh_remote_ecdsa_key.tmp 2>&1
$ ssh-keyscan -t rsa host.example.com > /tmp/ssh_remote_rsa_key.tmp 2>&1

Успешното изпълнение на командните редове по-горе, ще създаде три файла: /tmp/ssh_remote_ecdsa_key.tmp, /tmp/ssh_remote_ecdsa_key.tmp и /tmp/ssh_remote_rsa_key.tmp. Ако сървърът, който е сканиран, не поддържа сървърски ключ по някой от заявените алгоритми (ed25519, ecdsa, rsa), в съответния файл ще имате ще имате само един ред - коментар (т.е. няма да имате ред, съдържащ ключ).

След като файловете са налични, за тези, от тях, които съдържат ключ, изпълнете:

$ ssh-keygen -l -v -f /tmp/ssh_remote_ed25519_key.tmp
$ ssh-keygen -l -v -f /tmp/ssh_remote_ecdsa_key.tmp
$ ssh-keygen -l -v -f /tmp/ssh_remote_rsa_key.tmp

и на екрана информация ще се изведе информация подобна на следната:

384 SHA256:2QqMdMvvJHOLu6daoCe0zncCoADL0Xe1hJEX0UNUWC0 host.example.com (ECDSA)
+---[ECDSA 384]---+
|  .    .==*o+o.  |
|.. . . +...+ E . |
|o.. o o ..  . .  |
|+. . = . o       |
|o.. o = S .      |
|...o . o .       |
|  +.. + =        |
| o oo..B..       |
|  o..+==o        |
+----[SHA256]-----+

На първия ред, в началото, 384 е дължината на ключа (в битове), SHA256 е хеш-функцията, с която е изчислена контролата сума, намираща се след двуеточието, която за примера е 2QqMdMvvJHOLu6daoCe0zncCoADL0Xe1hJEX0UNUWC0 (във вашия случай ще е друга), а по-нататък следва името на хоста (host.example.com, за примера) и алгоритъма на ключа (ECDSA, за примера). От началото на втория ред до края на блока е разположен ASCII арт на ключа. В този ASCII арт, най-горе в рамката стои името на алгоритъма, по който е генериран и работи ключа (ECDSA), дължината му (384 бита), ASCII репрезентацията на хеша (точно тя изглежда като картинка) и най-долу в рамката е името на хеш-функцията, с която е произведен показания ASCII арт (в случая това е SHA256).

За да сте сигурни, че тези ключове са актуални и автентични, контактувайте с администратора на отдалечения SSH сървър, използвайки канал, който е сигурен (S/MIME, PGP/MIME, съдържание поставено на сигурен файлов сървър), и изисквайте да ви изпрати копие от ключовете или хеш и ASCII арт за всеки ключ, които да сравните с тази, която сте получили по начина, описан по-горе. Препоръчително е да поискате само ASCII арт изображенията. Използването на ASCII арт изображението ви спестява досадното четене и сравняването на контролните суми. Сравнете изобжението, което вие сте изчислили с това, което ви е изпратено от администратора на отдалечения сървър. Ако има пълно съвпадение - ключа на сървъра, който сте изтеглили чрез ssh-keyscan, е автентичен и може да го поставите във файла ~/.ssh/known_hosts така:

$ cat /tmp/ssh_remote_ed25519_key.tmp >> ~/.ssh/known_hosts
$ cat /tmp/ssh_remote_ecdsa_key.tmp >> ~/.ssh/known_hosts
$ cat /tmp/ssh_remote_rsa_key.tmp >> ~/.ssh/known_hosts

За всеки отдалечен SSH сървър, към който ще се свързвате, може да дефнинирате поведението на вашия ssh клиент. Съответните настройки трябва да направите във файла ~/.ssh/config. Примерът, даден по-долу, показва подобни настройки, които осигуряват сравнително високо ниво на защита при установяване и поддържане на SSH сесията, иницирана към SSH сървъри работещи с последните версии на дистрибуции като CentOS, Scientific Linux, Ubuntu и Debian:

Host host.example.com
   ServerAliveInterval 30
   Ciphers chacha20-poly1305@openssh.com,aes256-gcm@openssh.com,aes256-ctr,aes192-ctr
   MACs hmac-sha2-512-etm@openssh.com,hmac-sha2-512
   KexAlgorithms curve25519-sha256,curve25519-sha256@libssh.org,ecdh-sha2-nistp256,ecdh-sha2-nistp384,ecdh-sha2-nistp521,diffie-hellman-group16-sha512,diffie-hellman-group18-sha512
   HostKeyAlgorithms ecdsa-sha2-nistp384-cert-v01@openssh.com,ecdsa-sha2-nistp521-cert-v01@openssh.com,ssh-ed25519-cert-v01@openssh.com,ecdsa-sha2-nistp384,ecdsa-sha2-nistp521,ssh-ed25519

Освен подбора на хеш-функции, криптографски алгоритми, алгоритми за обмен на ключ и др, може да зададете SSH сесията да се поддържа "жива", дори да не изпълнявате команди дистанционно през нея за известно време. Така та няма да бъде затворена автоматично поради прекъсването на TCP сесията (на основа на която се осъществява SSH сесията) от страна на защитни стени, които автоматично прекратяват обслужването на "латентни" TCP сесии (такива, по които няма обмен на пакети за дълго време). Това става чрез опцията ServerAliveInterval. След ServerAliveInterval трябва да зададете интервала (в секунди), през който ще се изпраща пакет до сървъра по вече установената SSH сесия.

За повече настройки в ~/.ssh/config, вижте съотверната man/info информация:

$ man ssh_config

Възможно е да декларирате някои от настройкие генерално (валидни за всички потребители) във файла /etc/ssh/ssh_config.

Преди да пристъпите към свързването, трябва да сте сигурни, че:

• имате SSH двойка ключове и публичния ключ от тази двойка е инсталиран като средство за удостоверяване на отдалечения SSH сървър;
• идентичността на сървъра е проверена (имате копие от публичния ключ на сървъра във файла ~/.ssh/known_hosts);
• използвате криптографски протоколи и алгоритми, които осигуряват високо ниво на сигурност (описани спефицично за дадения сървър, в ~/.ssh/config).

За да иницирате SSH сесия към порт 22 на отдалечения сървър с име на хост host.example.com, с последващо удостоверяване като потребител с име в отдалечената система "user", може да използвате следния команден ред:

$ ssh user@host.example.com

Ако искате да иницирате SSH сесия към отдалечения сървър на порт, различен от подразбиращия се (22), трябва да укажете порта след -p (за примера по-долу използвания порт е 2222):

$ ssh user@host.example.com -p 2222

Ако искате да укажете кой точно ключ да бъде използван, трябва да използвате опцията -i и след нея да укажете файла, който съдържа ключа:

$ ssh user@host.example.com -i ~/.ssh/id_ed25519

Ако искате да изпълните команда дистанционно и SSH сесията да се затвори веднага след получаването на резултата от изпълнението (например, да покаже файловете и директорията в /home/user), използвайте примера:

$ ssh user@host.example.com 'ls /home/user'

Ако в хода на иницирането на сесията получите следното предупреждение:

The authenticity of host 'host.example.com (192.168.1.2)' can't be established.
ECDSA key fingerprint is SHA256:7RZG/AtDe1x7bi5GxCy1ajco6yTmjMDA/ZjVrd6UN7c.
ECDSA key fingerprint is MD5:49:00:bc:78:52:df:4c:d1:bf:26:d4:69:b6:3b:59:d0.
Are you sure you want to continue connecting (yes/no)?

това означава, че имате автентичността на сървъра не е била предварително установена. Изпълнете инструкциите в "Установяване на автентичността на сървъра по сървърския му SSH ключ" и опитайте да се свържете към сървъра отново.

Ако в хода на иницирането на сесията получите следното предупреждение:

@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@
@    WARNING: REMOTE HOST IDENTIFICATION HAS CHANGED!     @
@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@
IT IS POSSIBLE THAT SOMEONE IS DOING SOMETHING NASTY!
Someone could be eavesdropping on you right now (man-in-the-middle attack)!
It is also possible that a host key has just been changed.
The fingerprint for the ECDSA key sent by the remote host is
SHA256:kdCtbkhDhfisy2zp6T4b9p6sFl5gVyPWKmEe6u0QRek.
Please contact your system administrator.
Add correct host key in /home/user/.ssh/known_hosts to get rid of this message.
Offending ECDSA key in /home/user/.ssh/known_hosts:734
ECDSA host key for host.example.com has changed and you have requested strict checking.
Host key verification failed.

това означава, че има проблеми с идентичността на SSH ключа на отделечения SSH сървър. Свържете се с администратора на сървъра, за да установите къде е проблема и как да бъде отстранен.

Стартирайте и използвайте SSH агент само и единствено на работна станция, върху която имате пълен контрол и която не се използва от други потребители и специално такива, които имат super user (root) права!

Ако използвате графична потребителска десктоп среда (GNOME, KDE), поддържана от някоя от модерните Linux дистрибуции, този агент се активира по подразбиране и в момента, в който се опитате да достъпите отдалечен SSH сървър, пред който се удостоверявате с персонален SSH ключ, ако този ключ вече не е вече зареден в слотовете на агента в паметта, ще бъде изведен прозорец, в който ще трябва да въведе паролата за декриптиране на ключа.

Ако не използвате графична десктоп среда, а работите в "чист" команден ред, трябва да стартирате агента така:

$ ssh-agent

и да въведете паролата за отключване на SSH частния ключ. Имайте предвид, че този агент се асоциира по подразбиране към текущия терминал, което означава, че ако стартирате втори терминал на същата машина, ще трябва да стартитрате и втори агент.

Създаването на SSH тунел, входа на който се намира на клиентската машина, може да бъде направено чрез изпълнение на следния команден ред (имената на хостове в него са примерни):

$ ssh -L 2222:another-host.example.com:22 user@host.example.com

Горният команден ред (при успешно изпълнение) ще изгради TCP тунел използвайки SSH сесията, установена с отдалечения сървър host.example.com. Началото на този тунел ще е на компютъра (или виртуалната машина), на който сте изпълнили командния ред, а края му - на отдалечения SSH сървър (host.example.com, за примера). В работен режим този тунел ви позволява следното - да иницирате TCP сесия към порт 2222 на локалния хост и така да се свържете към порт на 22 на another-host.example.com. Имайте предвид следното. Използвайки тунела, приложението, което слуша на порт 22 на another-host.example.com, ще вижда опит за свързване не от вашия хост, а от host.example.com. Т.е. тунелът осигурява проксиране на комуникацията.

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

$ ssh -R 2222:another-host.example.com:22 user@host.example.com

Горният команден ред (при успешно изпълнение) ще изгради TCP тунел използвайки SSH сесията, установена с отдалечения сървър host.example.com. Началото на този тунел ще е на хоста host.example.com, а края му - на компютъра, на който сте изпълнили командния ред. В работен режим този тунел ви позволява следното - процес на host.example.com да иницира TCP сесия към порт 2222 на локалния (за него) хост и така да се свърже към порт на 22 на another-host.example.com, преминавайки през вашия компютър. Имайте предвид следното. Използвайки тунела, приложението, което слуша на порт 22 на another-host.example.com, ще вижда опит за свързване не от host.example.com, а от вашия хост. Т.е. тунелът осигурява проксиране на комуникацията.

Ако нямате на разположение файловете с разширение *.pub, но имате тези, които съдържат частния ключ, можете да ги генерирате. Това става по следния начин:

• ed25519:

  $ ssh-keygen -y -f ~/.ssh/id_ed25519 > ~/.ssh/id_ed25519.pub

• ecdsa:

  $ ssh-keygen -y -f ~/.ssh/id_ecdsa > ~/.ssh/id_ecdsa.pub

• rsa:

  $ ssh-keygen -y -f ~/.ssh/id_rsa > ~/.ssh/id_rsa.pub