aws ec2: проблема входа по ключам

 Казалось бы, уже давно отработанный механизм с .ssh/authorized_keys в случае амазона ВДРУГ дал сбой. Вдруг - потому что ещё несколько лет назад этой ПРОБЛЕМЫ не было.

Смотрим /var/log/auth.log и видим там крайне сомнительные строки

AuthorizedKeysCommand /usr/share/ec2-instance-connect/eic_run_authorized_keys username SHA256:ecphulTPPp7xHnSCVkuQH2fcXemYKjT8xFftheRDz+s failed, status 22

Но секрет прост: кто-то "переиграл в безопасность" и

# apt show ec2-instance-connect

...

Description: Configures ssh daemon to accept EC2 Instance Connect ssh keys

 EC2 Instance Connect is a service that publishes ssh keys for use by EC2

 instances based on AWS Credentials. These keys are consumed by on-instance

 configuration provided by this package. The ssh daemon will query EC2

 Instance Metadata service for user-keys at ssh calltime, validate any if

 present as well as validating their signature, and if all checks pass return

 will include them in the authorized keys list.

Фикс версия 1:

apt remove ec2-instance-connect

systemctl restart sshd

Фикс версия 2:

rm /usr/lib/systemd/system/ssh.service.d/ec2-instance-connect.conf

systemctl daemon-reload

И ещё немного почитать

https://github.com/widdix/aws-ec2-ssh/issues/157

И причина: 

ExecStart=/usr/sbin/sshd -D -o "AuthorizedKeysCommand /usr/share/ec2-instance-connect/eic_run_authorized_keys %%u %%f" -o "AuthorizedKeysCommandUser ec2-instance-connect" $SSHD_OPTS




yandex cloud: нестандартное подключение по ssh

 Было обнаружено в яндекс.практикум

Для доступа к серийной консоли ВМ необходимо знать её идентификатор (ID). В консоли управления перейдите в раздел Compute Cloud. По умолчанию откроется страница со списком ВМ. В столбце справа указан идентификатор каждой ВМ.

Используйте для входа идентификатор ВМ и имя (логин) созданного в ней пользователя. Вот шаблон команды подключения для Linux:

ssh -t -p 9600 -o IdentitiesOnly=yes -i ~/.ssh/<имя закрытого ключа> <ID виртуальной машины>.<имя пользователя>@serialssh.cloud.yandex.net 

Вот так вы подключитесь к консоли, если в ВМ с ID fhm0b28lgfp4tkoa3jl6 есть пользователь yc-user:

ssh -t -p 9600 -o IdentitiesOnly=yes -i ~/.ssh/id_rsa fhm0b28lgfp4tkoa3jl6.yc-user@serialssh.cloud.yandex.net 

Введите установленный ранее пароль.
Чтобы отключиться от серийной консоли, нажмите клавишу Enter, а затем введите символы ~. (тильда и точка). В терминалах Linux для отключения также можно использовать комбинацию клавиш Ctrl + D.

ssh виды ключей

                  [-t dsa | ecdsa | ecdsa-sk | ed25519 | ed25519-sk | rsa]

а что выбрать? Можно по привычке просто ssh-keygen, но будет создан id_rsa с длиной ключа 1024, что в современном мире откровенно мало.

ssh-keygen -b 4096 - и это будет работать и будет достаточно безопасно. Но что такое остальные виды?

Сразу про -sk: это security key, для FIDO/U2F (например YubiKey)

EC* ключи - основаны на эллиптических кривых

https://habr.com/ru/articles/335906/

ecdsa (elliptic curve dsa) это очень небольшой ключ, основанный на эллиптических кривых, но при этом более безопасный чем обычный -t rsa -n 1024

Как я понимаю, ed25519 по надёжности как ecdsa, но более быстый:

https://security.stackexchange.com/questions/50878/ecdsa-vs-ecdh-vs-ed25519-vs-curve25519

https://latacora.singles/2018/04/03/cryptographic-right-answers.html

Итог: лучше всего взять ed25519

Unable to negotiate with x.x.x.x.123 port 22: no matching key exchange method found. Their offer: diffie-hellman-group1-sha1

При подключении к некоторым железкам типа Cisco ASA5508 может быть ошибка при подключении
Unable to negotiate with x.x.x.x.123 port 22: no matching key exchange method found. Their offer: diffie-hellman-group1-sha1

Фикс: указать опцию -oKexAlgorithms=+diffie-hellman-group1-sha1
например так
ssh -oKexAlgorithms=+diffie-hellman-group1-sha1 x.x.x.x

Можно в ~/.ssh/config добавить
Host x.x.x.x
    KexAlgorithms +diffie-hellman-group1-sha1

Ходим по ssh через tor

https://trac.torproject.org/projects/tor/wiki/doc/TorifyHOWTO/ssh

Последний рецепт через .ssh/config не работает, еще 2 проверены и работают
sudo apt-get update
sudo apt-get install tor torproxy
sudo service tor start

1) torproxy ssh aaa@bb
2) ssh -o "ProxyCommand nc -X 5 -x 127.0.0.1:9050 %h %p" aaa@bb

git и bitbucket = беспарольная работа

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

1) создадим ключи. Делаем от того пользователя, от которого будем работать, то есть не рута.

ssh_keygen -b 2048 -N '' -f ~/.ssh/bitbucket
cat >> ~/.ssh/config <<EOF
Host bitbucket.org
  User git
  IdentityFile ~/.ssh/bitbucket
EOF

chmod 0600 ~/.ssh/config
cat ~/.ssh/bitbucket.pub

2)
вывод - на битбакет (публичный ключ), раздел настройки (manage) - security - SSH keys - add key
User git - не меняем, так и должно быть, актуальный юзер указывается в пути.

Если надо сделать ключ для деплоя (только для чтения), то добавляется он в другое место - открываем репозиторий, слева внизу settings, там в Deployment keys придумываем имя ключа (оно же будет логином) и вставляем ключ, полученный выше.

3) проверка
ssh -T git@bitbucket.org

Если что-то не так, можно руками добавить после -T: -i (какой файл использовать)

Нормальный вывод:
authenticated via a deploy key.


You can use git or hg to connect to Bitbucket. Shell access is disabled.

This deploy key has read access to the following repositories:

и дальше список, куда можно логиниться. Смотрим интересующие нас репы и копируем/запоминаем первую часть до двоеточия (:), понадобится дальше.

4) Использование

git clone ssh://git@bitbucket.org/(тут пишем/вставляем нужную репу, выбранную выше)

хотя если в .ssh/config есть User git, то из клона можно убрать git@

Линки
https://confluence.atlassian.com/display/BITBUCKET/Add+an+SSH+key+to+an+account
https://confluence.atlassian.com/display/BITBUCKET/Set+up+SSH+for+Git
https://confluence.atlassian.com/display/BITBUCKET/Use+deployment+keys
http://jeka.by/post/1051/setup-ssh-keys-for-bitbucket-github/ - с картинками

Где взять portaputty

Есть полезный и известный набор утилит для работы через ssh, tty, telnet под винду. Лежит тут:
http://www.chiark.greenend.org.uk/~sgtatham/putty/download.html
последняя версия 0.64

 К большому сожалению, она пишет в реестр, поэтому её невозможно использовать с нескольких машин, а потеря реестра означает потерю всех настроек. Есть 3 варианта избавиться от этой гадости:
1) putty portable на portableapps.com - версия свежая, но для работы нужна обёртка. Неизвестна стабильность при работе в связке с pytty connection manager и аналогами.
2) portaputty. Сами исходники "отучены" лезть куда не нужно, все настройки на диске, переносимость хорошая, работает с менеджерами. Долгое время обитало на http://code.google.com/p/portaputty/, но сейчас удалено или закрыто. Есть клон/копия на https://github.com/potatosalad/portaputty, но исходники 8-летней давности, версия 0.60.
3) KiTTY, http://www.9bis.net/kitty/?zone=ru
KiTTY — это модифицированная версия программы PuTTY версии 0.64
По умолчанию так же гадит в реестр, но есть возможность изменить поведение: http://www.9bis.net/kitty/?page=Portability&zone=ru
Увы, полноценного менеджера сессий в комплекте так и нет.

получаем ssh fingerprint для хоста

При первом подключении к серверу запрашивается
The authenticity of host 'nnn.nnn.nnn.nnn' can't be established.
RSA key fingerprint is xx:xx:xx:xx:xx:xx:xx:xx:xx:xx:xx:xx:xx:xx:xx:xx.
Are you sure you want to continue connecting (yes/no)? no

А как этот самый принт получить? (например, для автоматического добавления)
# ssh-keygen -lf /etc/ssh/ssh_host_rsa_key.pub
2048 1a:b9:2c:dc:99:a6:57:14:5e:b4:b0:f4:62:a4:1a:3d  root@ubuntu (RSA)

Автоматическая авторизация паролем по ssh

Иногда бывает нужно авторизовываться на устройствах по ssh, которые не умеют авторизации по ключам. Увы, штатно в ssh пароль не передать никак. В этом случае помогают expect или sshpass

ssh: отключаем проверки отпечатка

Бывает нужно отключить проверку отпечатков, например внутри локалки, и особенно актуально для автоматических скриптов.
Вариант 1: ssh -o StrictHostKeyChecking=no host.ru
Оно же, без записи ключа в known_hosts: ssh -o StrictHostKeyChecking=no -o UserKnownHostsFile=/dev/null host.ru

Вариант 2: в ~/.ssh/config:

Host 192.168.0.*
   StrictHostKeyChecking no
   UserKnownHostsFile=/dev/null

Смотрим отпечаток (fingerprint) ssh ключа

ssh-keygen -lf ~/.ssh/id_rsa