Linux

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

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

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

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

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

Обновите свои 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

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

Я уже упомянул, что перелез на 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 (да, знаю, старая)