Не могу не поделиться этой историей, хотя пользы от неё кому-то кроме меня скорее всего... — 7 мая 2026 г. в 09:11:01.239
Не могу не поделиться этой историей, хотя пользы от неё кому-то кроме меня скорее всего не будет. Я потратил где-то час на решение одной нелепой ошибки, а спаc меня в итоге бесплатный Qwen. Я уже практически отчаялся самостоятельно разобраться в проблеме. Делаю простую задачу. Полное её описание скорее всего напишу отдельно. Мне нужно с Windows машины автоматически выключать Linux сервера по событию с ИБП. Делается это элементарно через cmd скрипт, который можно отладить в консоли примерно так: > ssh ups_shutdown@192.168.137.29 "sudo systemctl poweroff" Делаем на сервере пользователя ups_shutdown и добавляем ему публичный ключ: # useradd -m -s /bin/bash ups_shutdown # mkdir -p /home/ups_shutdown/.ssh # touch /home/ups_shutdown/.ssh/authorized_keys # echo "ssh-ed25519 AAAAC3NzaC1lZDI1... ваш_ключ..." >> /home/ups_shutdown/.ssh/authorized_keys # chown -R ups_shutdown:ups_shutdown/home/ups_shutdown/.ssh # chmod 700 /home/ups_shutdown/.ssh # chmod 600 /home/ups_shutdown/.ssh/authorized_keys Даём ему через visudo права на выполнение указанной команды: ups_shutdown ALL=(ALL) NOPASSWD: /usr/bin/systemctl poweroff На винде перед этим создал нужный ключ: > ssh-keygen -t ed25519 -C "ups_shutdown" -N "" -f %USERPROFILE%\.ssh\id_ed25519 Всё максимально просто и стандартно. Пробую подключиться, не получается. На команду: > ssh ups_shutdown@192.168.137.29 "sudo systemctl poweroff" Получаю запрос на аутентификацию по паролю. Режим отладки показывает, что ssh успешно применяет созданный ключ id_ed25519, публичная часть которого добавлена на Linux. А на самом сервере никаких ошибок при подключении. Просто тишина. Перепроверил по 10 раз все настройки и права доступа. Ничего не помогло. При этом, если туда же подключаться под root, то аутентификация нормально проходит. Вызвал на помощь Qwen. Он, конечно, кучу всего предложил проверить, отправить логи, отладку и т.д. Ничего не помогало. В конце он предложил начать всё сначала и отправить ему вообще все настройки и логи. Дал список команд. Я всё собрал и отправил. Он тут же нашёл ошибку: ssh-ed25519 ssh-ed25519 AAAAC3NzaC1....LQSVErJUKo ups_shutdown 💥 Два раза ssh-ed25519 подряд! Это невалидный формат ключа. Я тупо ошибся при переносе публичного ключа, скопировав ssh-ed25519 два раза. Не знаю, как так вышло, но вот вышло. И ни в одном логе нигде не было ошибки, что ключи не совпадают, формат неверный или что-то в этом духе. Рано или поздно я бы плюнул на всё, удалил пользователя и сделал бы всё заново. Это известный и рабочий приём, который я сам практикую и многим советую, особенно в комментариях к моим статьям, которые гарантированно рабочие, потому что я проверял их лично. Но очень хотелось разобраться в проблеме, поэтому тратил время. Многие сетуют, мол ИИ часто ошибается. Я вот с ним плотно работаю и могу сказать, что он ошибается реже чем я. И при этом он быстро находит свои ошибки. Давал ему на проверку некоторые свои статьи, которые я внимательно писал и выверял. Он там находил ошибки. И писал итоговые статьи лучше меня. Он вообще может за час проверить все статьи с моего сайта, исправить ошибки, дополнить полезной информацией и проверить на реальных системах всё, что напишет. Грустно было осознать, что он разом обесценил мой прошлый тяжёлый труд. Но ничего не поделать. Мир меняется и надо меняться вместе с ним. Писать вручную подобные статьи, что есть на моём сайте, потеряло всякий смысл. Как и делать вручную многие другие вещи. Я за последние пару недель автоматизирую всё, что только в голову приходит. Репы в gitflic растут как на дрожжах. Всё, что откладывал или казалось не очень нужным, решается за пару часов генерации и отладки. Причём для админских дел, в отличии от программерских, много токенов не нужно. У нас контекст задач значительно меньше. #ai