# Создать пару ключей
ssh-keygen -t rsa -b 4096
# В каталоге ~/.ssh появляются id_rsa (закрытый ключ) и id_rsa.pub (открытый ключ)
# -t — тип ключа
# -b — длина ключа в битах (по умолчанию 3072 для RSA)
# -f — путь к файлу ключа (по умолчанию ~/.ssh/id_rsa)
# -C — комментарий к ключу (по умолчанию username@hostname)
# -P — пароль для доступа к ключу
 
# более защищённый аглоритм, и открытый ключ гораздо короче, чем у RSA
ssh-keygen -t ed25519 -C "my-laptop"
 
# Скопировать открытый ключ на другую машину
ssh-copy-id username@remote_host
# можно просто
ssh-copy-id remote_host # если имя пользователя одинаковое
# скопировать другой ключ
ssh-copy-id -i ~/.ssh/random_key.pub admin@remote_host
# скопирует содержимое файла открытого ключа из ~/.ssh/id_rsa.pub в файл authorized_keys
# в каталоге ~/.ssh пользователя на удалённом хосте.

Доступ будет с сервера с закрытым ключом на сервер, куда скопировали открытый.

https://www.ssh.com/ssh/keygen/
https://medium.com/risan/upgrade-your-ssh-key-to-ed25519-c6e8d60d3c54

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

Закрытый ключ, созданный ssh-keygen, для putty не годится, и нужно либо генерить его там изначально, либо открывать уже созданный закрытый ключ в PuTTYgen и конвертировать.

Также в составе PuTTY имеется Pageant - позволяет загрузить приватный ключ заранее, и затем передавать PuTTY данные аутентификации - PuTTY изначально пытается связаться с Pageant для получения данных. Ключ можно задавать аргументом к pageant.exe. Если в настройках PuTTY → Connection → Data задать ещё и логин, то вход будет полностью автоматическим.
https://www.youtube.com/watch?v=2nkAQ9M6ZF8

# Ограничить разрешения на файл с закрытым ключом, иначе будет ругань при попытке соединения
chmod 600 .ssh/ssh_key
# Подключиться с указанием ключа и не спрашивать о добавлении отпечатка в ~/.ssh/known_hosts
ssh -i .ssh/ssh_key -o StrictHostKeyChecking=no user@server

.ssh/config - настройки клиента. Сюда добавляются сгенерированные закрытые ключи для соединения с удалёнными серверами, самый простой пример: IdentityFile ~/.ssh/id_ed25519. Также можно добавить опции:

StrictHostKeyChecking no # автоматически добавить сервер в ~/.ssh/known_hosts
UserKnownHostsFile=/dev/null # Чтобы не добавлять каждый раз запись к known_hosts, если IP сервера динамический
#RequestTTY force
#LogLevel=quiet
 
# Для gitlab runner
Host gitlab-runner
  HostName 192.168.1.40
  User vasya
  ForwardAgent yes
  IdentityFile ~/.ssh/id_rsa
  ProxyJump jproxy
 
# Для всех, кроме gitlab-runner
Host * !gitlab-runner
  ControlMaster auto
  ControlPath ~/.ssh/sockets/%r@%h-%p
  ControlPersist 600
  StrictHostKeyChecking no
  UserKnownHostsFile=/dev/null
  ServerAliveInterval 30
  ServerAliveCountMax 25
  ForwardAgent yes

Опции в строку:

ssh -o StrictHostKeyChecking=no -o UserKnownHostsFile=/dev/null user@host.com
# в случае с rsync, scp и т. д.
rsync -e 'ssh -o StrictHostKeyChecking=no' ...

Автоматическое принятие RSA key клиентом SSH

Устаревшие алгоритмы

# Unable to negotiate with 192.168.1.1 port 22: no matching key exchange method found. Their offer: diffie-hellman-group1-sha1
# Unable to negotiate with 192.168.1.1 port 22: no matching host key type found. Their offer: ssh-rsa
ssh -o KexAlgorithms=+diffie-hellman-group1-sha1 -o HostKeyAlgorithms=+ssh-rsa -o StrictHostKeyChecking=no user@192.168.1.1

Чтобы не ругалось на права закрытого ключа и не спрашивало на добавление в known_hosts.

~\.ssh\config

Host *
  UserKnownHostsFile=/dev/null
  StrictHostKeyChecking=no

Worst practice - пароль хранится в скрипте, по возможности избегайте этого! Шаблон подключения для Powershell (вставка пароля по ПКМ, если не настроен ключ в authorized_keys)

$clip = Get-Clipboard
Set-Clipboard 'SSH_P@ssw0rd'
clear
& ssh.exe admin@server1-web
Set-Clipboard $clip

/etc/ssh/sshd_config - настройки демона ssh. После правки надо перезапустить сервис - sudo systemctl restart ssh.

Port                            22
Protocol                        2
UsePAM                          yes
PermitRootLogin                 no
PasswordAuthentication          yes
PermitEmptyPasswords            no
PubkeyAuthentication            yes
AllowTcpForwarding              no
X11Forwarding                   no
StrictModes                     yes
UsePAM                          yes
PrintMotd                       no
PrintLastLog                    no
TCPKeepAlive                    yes
UseDNS                          no
LoginGraceTime                  1m
maxauthtries                    4
Subsystem                       sftp internal-sftp
AcceptEnv                       LANG LC_*
AllowAgentForwarding            yes
ChallengeResponseAuthentication no
AllowUsers                      vasya root@IP

https://www.opennet.ru/man.shtml?topic=sshd_config&category=5&russian=0

Пайплайн для удалённых команд в shell.

1. Сгенерить ключи, добавить закрытый ключ в переменную $SSH_PRIVATE_KEY в Гитлабе
2. Добавить открытый ключ на сервер, к которому нужно подключаться, в файл ~/.ssh/authorized_keys пользователя, под которым будет подключение
3. Нарисовать этап в пайплайне

stages:
  - deploy

deploy-job:
  stage: deploy
  before_script:
  # устанавливаем ssh-agent, если ещё не
  - 'which ssh-agent > /dev/null || ( apt-get update -y && apt-get install openssh-client -y )'
  - eval $(ssh-agent -s)
  # сохраняем сгенеренный ранее приватный ключ для раннера
  - echo "$SSH_PRIVATE_KEY" | tr -d '\r' | ssh-add -
  - mkdir -p ~/.ssh
  - chmod 600 ~/.ssh
  script:
    - |
      ssh -o StrictHostKeyChecking=no -o UserKnownHostsFile=/dev/null user@192.168.4.5 "
      id
      ls ~
      echo "Привет"
      "

Using SSH keys with GitLab CI/CD

Для синхронизации конфигурации и сертификатов, выполняется под root

# Генерация ключа
ssh-keygen -t ed25519
# Включить возможность входа под рутом
echo "PermitRootLogin yes" > /etc/ssh/sshd_config.d/root
# Рестарт ssh для применения настроек
systemctl restart ssh
# Вывести открытый ключ и скопировать его в буфер обмена
cat ~/.ssh/id_ed25519.pub
ssh-ed25519 AAAAC3NzaC1lZDI1NTE5AAAAIJvFD1ALkXfbmFaH7A5IQJ+EGD8I9A1SxqVX2z+6Wrts root@srv-haproxy1
 
# На другом сервере (также под root) вставить открытый ключ из буфера в файл:
nano /root/.ssh/authorized_keys

Это работает только с RSA-ключами. Шифрование открытым ключом, расшифровывание - закрытым. Ключи должны быть в формате PEM.
Открытый ключ можно получить из закрытого, поэтому в качестве исходного нужен только один закрытый ключ.

# Create key pair if needed
ssh-keygen -f id_rsa -t rsa -P ""
 
# Convert public key to PEM
ssh-keygen -f id_rsa -e -m PEM > id_rsa.pub.pem
# Encrypt file (rsautl deprecated, use pkeyutl on new systems)
openssl rsautl -encrypt -inkey id_rsa.pub.pem -pubin -in pass.txt -out pass.enc
 
# Convert private key to PEM (copy because private key overwrites)
cp id_rsa id_rsa.pem
ssh-keygen -f id_rsa.pem -p -m PEM -N ""
# Decrypt file
openssl rsautl -decrypt -inkey id_rsa.pem -in pass.enc > pass2.txt

https://www.linuxquestions.org/questions/linux-security-4/openssl-error-unable-to-load-private-key-4175725374/

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

# Encrypt
openssl enc -aes-256-cbc -pbkdf2 -k "$(cat ~/.ssh/id_ed25519 |tr -d '\n')" -in pass.txt -out pass.enc
# Decrypt
openssl enc -aes-256-cbc -pbkdf2 -k "$(cat ~/.ssh/id_ed25519 |tr -d '\n')" -in pass.enc -out pass2.txt -d

Опция -kfile не используется, т. к. она читает из файла только первую строку (-----BEGIN OPENSSH PRIVATE KEY-----). Если убрать -out, то будет вывод в stdout.

mRemoteNG - удобная оболочка для удалённого доступа.