Как исправить ошибку SSH: no matching host key type found. Their offer: ssh-rsa

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

Всё очень просто: достаточно в локальном файле ~/.ssh/config указать следующее:

Host *
  # здесь могут быть и другие настройки, но важно добавить только эти:
  PubkeyAcceptedAlgorithms +ssh-rsa
  HostkeyAlgorithms +ssh-rsa

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

Опубликовано
В рубрике blog Отмечено ,

Обновите свои SSH-ключи до Ed25519

closeup photo of Yale 19 key against black background
Photo by Matt Artz on Unsplash

Привет. Это мой самостоятельный перевод некогда случайно найденной мной оригинальной статьи Upgrade Your SSH Key to Ed25519, автор — Risan Bagja, ныне веб-разработчик из Швеции.

Благодаря ей я когда-то чуть скорректировал свой взгляд на SSH и стал использовать именно такие ключи. В современном мире они без проблем генерируются и принимаются буквально где угодно, без каких-либо настроек. Читатель моего блога, должно быть, заметил, что я использовал этот алгоритм при настройке Termux.

В статье идёт речь о том, как сгенерировать и использовать ключи с алгоритмом, отличным от набившего оскомину RSA, почему следует отказываться от RSA и что даёт этот ваш Ed25519.

Следует обратить внимание на дату оригинальной статьи — ноябрь 2017. За прошедшие до сего момента 5 лет что-то могло существенно измениться.

Далее — текст перевода.

Немного про графические оболочки на Linux и за что я в итоге полюбил KDE

Photo by Nayam on Unsplash

Пост про поиски и вкусовщину.

Я уже упомянул, что перелез на KDE на обоих своих компах, и дома, и на работе. Но этому предшествовал долгий поиск того самого, единственного.

Впервые я погрузился в Linux, когда отдал маме свой старый Hasee, сидеть в одноквасниках. На тот момент у него уже был удалён экран: в корпусе разломались все крепления и матрица с уже нерабочей подсветкой отправилась в утиль. Ноут цеплялся к внешнему монитору и продолжал сносно работать по мере сил.

А силёнок у него было немного, зато ALT Linux 6 (а может и 7, не помню) с иксфейсом (xfce) вполне годно вытягивал огнелиса с мультимедией. Большего от него не требовалось.

Тогда я пробовал чем-то заменить xfce, но это было зря — ноут не вытягивал. Это всё, что я помню.

DavFS2. Куда утекает свободное место? Got error 28 from storage engine

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

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

Однажды утром, после свежего бекапа, MySQL стал падать с ошибкой:

Got error 28 from storage engine

Эта ошибка возникает во время выборки записей из БД. Поскольку выборка хранится в кеше на диске и в этот момент возникает ошибка, значит что-то с ним не так. Самое банальное — закончилось место. По факту так и оказалось. MySQL-у просто негде было хранить файлы кеша.

Но как? На сервере свежий бекап только один, и его размер несоизмеримо меньше, чем сейчас должно быть свободного места.
Начал поиски обжоры.

Резервное копирование базы данных на Cron с выгрузкой в облако на примере Яндекс.Диск. Версия 1.

Привет.

Тут я расскажу о самом простом способе создания бекапов БД на сервере, о выгрузке их в Яндекс.Диск. Я написал скрипт, который всё это выполняет.

Он приведён поэтапно, можешь скопировать пункты 4.1-4.5, убрав оттуда заголовки, и получишь готовый скрипт. Или можешь скачать, ссылка будет в конце. А лучше прочитать пост и вникнуть в суть происходящего.

ОС на сервере — CentOS 6.7
Версия СУБД — MySQL 5.5 (да, знаю, старая)