Вот сделал ты все как написано тут и тут и тут, сгенерил ключи и подготовил сервера, но сука все равно что-то какая-то шляпа:

Искал медь, обосрал медведь…

ssh user@server

Permission denied (publickey).

Что я делаю не так?

Всё правильно, твой ssh клиент не знает, что ты пытаешься подключиться по ключам. Он идет на сервер по дефолту и ожидает что запросят пароль.
ㅤ
А вход по паролям-то мы отключили!

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

Ансибл ходит на сервера по ssh, соответственно это агент и ему тоже нужно знать про ssh ключи.

Не ссым, все уже придумали за нас.

➡️ Первый вариант:

ssh -i ~/.ssh/bashdays_rsa user@server

Через ключ -i указываем путь до своего ключа и со свистом залетаем на сервер.

Теперь твой клиент знает — ага, эта бестолочь догадалась указать ключ, ну ок, прогнусь.

Указывать каждый раз -i очень заёбисто, особенно если у тебя ssh ключей вагон и тележка, легко запутаться. Но тут тоже уже все придумано за нас.

➡️ Второй вариант:

Захуячиваем ssh-agent

sudo apt-get update
sudo apt-get install openssh-client

Запускаем агент в фоне:

eval "$(ssh-agent -s)"

И добавляем в него нужные ключи:

ssh-add ~/.ssh/id_rsa
ssh-add ~/.ssh/bashdays_rsa
ssh-add ~/.ssh/ed25519

Смотрим что у нас торчит в агенте:

ssh-add -L

Ага, все ключи добавлены. Теперь не нужно указывать ключ -i, агент сам подкинет нужный ключ. Ну и ансибл сразу засвистит-запердит как надо.

Прикол с агентом:

Если на ssh ключе у тебя установлен пароль, то достаточно один раз его ввести и все последующие разы он у тебя не запрашивается.

Не прикол с агентом:

Как только ты закроешь консоль, агент уедет на кладбище со всеми ключами.

Решение:

Хуярим в ~/.profile (или чо там у тебя) такую конструкцию:

if [ -z "$SSH_AUTH_SOCK" ]; then
  eval $(ssh-agent -s) > ~/.ssh/ssh-agent
fi

ssh-add ~/.ssh/id_rsa
ssh-add ~/.ssh/bashdays_rsa
ssh-add ~/.ssh/ed25519

Теперь при открытии консоли, у тебя будет автоматически запускаться ssh-agent и добавляться нужные ключи.

Для zsh, в конфиге ~/.zshrc прописываем:

plugins=(git ssh-agent)

zstyle :omz:plugins:ssh-agent agent-forwarding on
zstyle :omz:plugins:ssh-agent identities id_rsa bashdays_rsa ed25519
zstyle :omz:plugins:ssh-agent lifetime

Включаем плагин ssh-agent и добавляем все нужные ключи. Теперь из коробки у тебя будет работать агент и в нем будут подгружены ключи.

➡️ Третий вариант:

Через конфиг ~/.ssh/config, открываем этот файл у себя на машине и пишем:

Host bashdays.ru
  Hostname bashdays.ru
  IdentityFile /home/user/.ssh/bashdays_rsa

Теперь когда ты будешь подключаться по ssh к серверу bashdays.ru, то автоматически подставится указанный файл с ключами.

Таким способом разруливают разные ключи для разных учеток в гитхабах/гитлабах.

Например, так:

Host github.com
  Hostname github.com
  IdentityFile ~/.ssh/id_ed25519

Host github.com-bashdays
  Hostname github.com
  IdentityFile ~/.ssh/bashdays_rsa

➡️ Четвертый вариант:

Сделать алиасы:

alias stage='ssh -i ~/.ssh/bashdays_rsa user@server'
alias prod='ssh -i ~/.ssh/id_ed25519 root@server'

И потом просто в консольке вбивать stage или prod, все автоматически подставится.

🅰️🅰️
Я использую все варианты, в зависимости от ситуации, но в предпочтениях у меня ssh-agent и алиасы.

Да, в ансибле можно тоже прописать хардкодом ssh ключ, чтобы не использовать агентов и т.п.

Через конфиг ansible.cfg:

[defaults]
private_key_file = ~/.ssh/bashdays_rsa

Через переменную окружения:

export ANSIBLE_PRIVATE_KEY_FILE=~/.ssh/bashdays_rsa

Есть еще 100500 способов как в ансибле это передать, я показал основные. Если хочешь узнать про все, велком в LF.

Если знаешь еще какие-то варианты и приколюхи с ключами, камон в комменты, соберем в кучу полезняхи.

С пятницей друзья!

tags: #git #devops #ssh #linuxfactory
—
🔔 @bashdays➡️ @gitgate

Такс, теперь в тему как отлаживать ssh подключения к серверу. К примеру ты все прописал и сделал как тут #linuxfactory, а оно все равно тебя не пускает по ключам.
ㅤ
Тут хочешь не хочешь нужен доступ к логам сервера к которому подключаешься. Так что заранее об этом побеспокойся, прежде чем перезапускать sshd службу.

Если рута нет, загружайся в рекавери и откатывайся по конфигам на сход по паролю. В рекавери я думаю ты знаешь как заходить, да и облачных провайдеров обычно это есть из коробки.

Маунтишь корневой раздел и откатываешь конфиги. Заходишь в конфиги (/etc/sshd/) руками и просто откатываешь, то что ты там закомментировал.

Ладно, предположим у тебя есть доступ к руту и ты зашел на сервер.

Запускай команду:

tail -f /var/log/auth.log

Теперь открывай другой терминал и пробуй подключиться по ключам. После того как ты это сделал, возвращайся в терминал где запускал tail и внимательно смотри что тебе пишут.

В 100% там будет ошибка, которая элементарно гуглится. Обычно это просто проблемы с правами на файл ~/.ssh/authorized_keys или папку ~/.ssh/.

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

Распространенные ошибки:

Invalid user
bad ownership or modes for /home/<username>/.ssh
Authentication failed
Connection closed by remote host
Permission denied
Too many authentication failures
Connection refused
PAM authentication errors
User not allowed
Host key verification failed
SSH protocol mismatch
Banner errors
Brute-force attempts
Timeout
Subsystem errors
Resource temporarily unavailable

Не ссым читать логи и находить нужное. А как только нашел что-то вменяемое — гуглим или скармливаем GPT (как ты любишь).

Кстати китайцы тут DeepSeek запустили, мол убийца GPT. Бесплатная и работает в РФ без приколов. Домашку ребенку решать милое дело.

tags: #git #devops #ssh #linuxfactory
—
🔔 @bashdays➡️ @gitgate

Еще немного про отладку ssh ключей, но уже в контексте интеграции со всякими гитлабами/гитхабами.
ㅤ
Чтобы работать с приватными репами ты добавляешь в настройки гитлаба/гитхаба свою публичную часть ключа.

Хорошо если такой ключ один, запутаться особо негде.

Но что если добавлено 20-100 ключей?

Порой возникает ситуация, когда какой-нибудь раннер отказывается клонировать репу и начинает орать на доступы.

Ты проверяешь, видишь в табличке «Заголовок» — gitlab-runner-1 и вроде всё хорошо, ключ прописан и в раннере его приватная часть есть. Чо за хуйня?

Тут нам и пригодится команда:

ssh-keygen -l -E md5 -f ~/.ssh/id_rsa

Выполняем ее для ключа с которым подключаемся (работает и для приватной и публичной части одинаково).

И по итогу видим фингерпринт, отпечаток:

2048 MD5:03:62:23:ca:ce:1b:8c:ad:60:1f:66:16:05:43:d8:a7 shuba@server (RSA)

Сравниваем этот отпечаток с тем что прописан в гитлабе/гитхабе и видим что он НЕ совпадает.

А это значит что твой раннер использует не тот приватный ключ для подключения.

Фиксим и радуемся. Как фиксить? Прописать актуальную публичную часть ключа в гитлаб/гитхаб. Дело закрыто.

tags: #git #devops #ssh #linuxfactory
—
🔔 @bashdays➡️ @gitgate

Еще один частый вопрос с LF — а нужно ли менять дефолтный ssh (22) порт на какой-то другой?
ㅤ
Нет! Ну а нахуя? Сократить в логах количество записей про неудачные попытки подломить твой девственный сервак?

В логи ты ходишь — практически никогда! Тем более там logrotate работает и место диске сильно не забьется.

Предположим ты поменял 22 на 2222. Количество записей в логах «сократилось» и теперь ты ебешься с указанием порта.

ssh -p2222 user@server

Охуеть как удобно! Ты скажешь - дак можно же в ~/.ssh/config все это прописать и всё вернуть на свои места.

Host bashdays.ru
    HostName bashdays.ru
    User user
    IdentityFile ~/.ssh/shuba
    Port 2222

Справедливо. Но зачем жертвовать своим удобством?

У тебя на серверах уже отключен вход по паролю, только ключи, рут тоже запрещен.

Пусть эти писька-боты долбятся и дальше в жопы. Накрайняк воткни fail2ban и устрой им веселую жизу.

Да и боты сейчас умные, если они видят закрытый 22 порт, они сделают nmap -Pn, по итогу получат твой 2222 и продолжат долбиться.

Как не прячься, все равно тебя найдут и насрут в логи.

Получается все манипуляции с портом это бесполезные телодвижения в ущерб удобства.

Соблюдай базовые правила безопасности и всё с твоими серверами будет хорошо.

- отключи вход по паролю
- перейди на ssh ключи
- запрети вход для рута

За всю свою практику я встретил только одну компанию, где меняли 22 порт на какой-то другой, но никакой смысловой нагрузки в этом не было. Так и так эту компанию подломили и спиздили базу данных.

Да, еще был компания, где 22 порт открывался через port knocking. То есть нужно было предварительно стукнуться на 3 определенных порта и если последовательность была соблюдена, то открывался 22 порт.

Ну тоже такое себе решение в ущерб удобства. Любят люди из пушки по воробьям стрелять.

Это как в жизни — мойте руки перед едой. Если соблюдаешь этот базовый принцип, то повышаешь шансы, что твой организм не хакнет кишечная палочка.

Такие дела, изучай!

tags: #devops #ssh #linuxfactory #security
—
🔔 @bashdays➡️ @gitgate

Есть у клиента старинный сервер с мониторингом, старинный как гавно мамонта. Работает чуть ли не на BlackCat Linux.
ㅤ
Всё бы ничего, но при подключении к этому серверу по ssh, оно пиздец долго думает, минуты по 3-4 и только потом пускает. Сидишь как олень ждешь у моря погоды.

Сегодня будем решать эту проблему.

Самый очевидный фикс, это прописать в конфиге: /etc/ssh/sshd_config опцию: UseDNS no.

Опция отключает обратное DNS-разрешение IP-адреса клиента при подключении по SSH.

По умолчанию опция UseDNS yes, SSH-сервер при подключении клиента:

1. Получает IP-адрес клиента.
2. Делает обратный DNS-запрос (reverse DNS lookup) — определяет доменное имя по IP.
3. Делает прямой DNS-запрос для проверки, что имя действительно соответствует IP

Дохуя лишнего!

😲 Но этот способ не прокатил. Ладно, идем дальше!

Нахожу в конфиге /etc/ssh/sshd_config: UsePAM yes, ага, еще один звоночек.

Удаляю эту опцию из конфига.

Перезапускаю: systemctl restart sshd

Пробую подключиться по ssh к серверу. Слава яйцам! Залетает только в путь, без мучительных ожиданий. Дело закрыто!

Что делает UsePAM yes в SSH

Когда выставлено UsePAM yes, после успешной аутентификации (например, по публичному ключу), sshd передаёт управление PAM-модулям, которые:

1. Создают сессию (session блок в /etc/pam.d/sshd)
2. Инициализируют среду (например, pam_env)
3. Логируют (pam_lastlog, pam_motd)
4. Могут подключать модули вроде pam_systemd, pam_limits, pam_loginuid и т.п.

Ну и корень проблемы: /etc/pam.d/sshd обычно в этом файле включена пачка модулей которые тормозят твою деятельность.

Вдумчиво настрой этот файл и потом можно обратно включать UsePAM yes.

Проблема решена, всем хорошей рабочей недели!

🛠 #ssh #bugfix #linux
—
✅ @bashdays / @linuxfactory / @blog