OpenSSH 7. Возвращаем авторизацию по ключам

Return simple authorization by public keys

У меня на большинство серверов настроена авторизация по ключам. Удобно — один раз разблокировал связку ключей и ходишь по серверам не отвлекаясь на ввод паролей. Когда пароли на все сервера разные, это действительно удобно.
Но после обновление ssh до 7 версии у меня вдруг постоянно стал запрашиваться пароль при подключении к серверам, как будто никаких ключей и не было никогда прописано. Либо я один с такой проблемой, либо просто обновился рано, но готового ответа нагуглить не удалось, а решается всё просто.
В новой версии добавилась опция PubkeyAcceptedKeyTypes (ссыль), без которой имеющиеся ключи стали игнорироваться.
Идём в /etc/ssh/ssh_config и добавляем PubkeyAcceptedKeyTypes=+ssh-dss . Всё. Опять авторизация по ключам работает.


Проверить причину "неавторизации" можно включением дебага (или verbose) при попытке коннекта:
$ ssh -v hostname

В моём случае в выводе присутствовало:

debug1: Skipping ssh-dss key /home/george/.ssh/id_dsa for not in PubkeyAcceptedKeyTypes

debug1: Next authentication method: password

Dirty tags ;) : ssh ignore keys, ssh want password, enable ssh key logon

How to disable bold font into guake terminal

Жирный шрифт в окне терминала не всегда и не везде выглядит нормально, отсюда и желание многих - отображение шрифта bold'ом запретить. В gnome-terminal (да и во многих других) для этого есть галочка в настройках, хочешь включай жирный шрифт, хочешь - отключай. А в guake почему-то этого нет. Есть патчи, есть примеры, как настройку добавить, но автор добавлять эту мега-киллер-фичу не хочет.
Вот в https://github.com/Guake/guake/issues/168 есть ответ замечательный:

So, yeah, basically, bold works, and I don't see enough motivation to ever allow to disable it.

Раньше я добавлял в guake настройку для отключения bold'а, но там несколько файлов править приходится ручками, патч-то вслепую не накатишь, версия из репозитория дистрибутива обычно отличается немного от версии в репозитории автора. Поэтому решил не заморачиваться, сперва просто захардкодил отключение bold'а, но потом всё же решил оставить возможность изменения параметра через gconf, чтоб не только мне полезно было.

Итак. Всё применительно к Arch'у, в других дистрибутивах путь может немного отличаться.

Правим /usr/bin/guake.

В GConfHandler.__init__ вставляем строку

    notify_add(KEY('/style/font/allow_bold'), self.fallowbold_changed)

у меня она встала на 144 строку, над

    notify_add(KEY('/style/font/style'), self.fstyle_changed)

(я везде новый код добавил над /style/font/style)

Дальше в сам GConfHandler добавляем метод

def fallowbold_changed(self, client, connection_id, entry, data):

    policy = entry.value.get_bool()

    for i in self.guake.term_list:

        i.set_allow_bold( policy )

(я метод вставил над существующим методом fstyle_changed, 257 строка)

Perl, OpenSSL и самоподписной сертификат

В продолжение предыдущей заметки...

Так как кроме получения данных по https со "своими" сертификатами мне эти данные нужно было ещё и обработать, то решил и обработку и получение данных запихнуть в один perl-скрипт. Так как с проблемой "трёх сертификатов в одном файле" разобрался, то не предвидел каких-либо трудностей на этом пути :)

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

Ошибка:

500 Can't connect to www.nekiysite.ru:443 (SSL connect attempt failed with unknown error error:14077410:SSL routines:SSL23_GET_SERVER_HELLO:sslv3 alert handshake failure)

Linux, wget, SSL и самоподписной сертификат

Столкнулся недавно с необходимостью получения данных по https из консоли с использованием клиентского сертификата. При этом и клиентский и серверный сертификаты не от какого-то публичного доверенного центра сертификации.

Задача: имея на "руках" p12-сертификат получить данные с некоего сервиса.

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

Ковырясь и подбирая варианты запросов получал такие ошибки:

OpenSSL: error:14094413:SSL routines:SSL3_READ_BYTES:sslv3 alert unsupported certificate
Unable to establish SSL connection.

OpenSSL: error:0B080074:x509 certificate routines:X509_check_private_key:key values mismatch
Disabling SSL due to encountered errors.

OpenSSL: error:0906D06C:PEM routines:PEM_read_bio:no start line
OpenSSL: error:140AD009:SSL routines:SSL_CTX_use_certificate_file:PEM lib
Disabling SSL due to encountered errors.

Пакетное переименование файлов с транслитерацией имени

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

$ perl -MLingua::Translit -le '$tr=new Lingua::Translit("GOST 7.79 RUS");opendir DIR,".";rename$_,$tr->translit($_)for grep{!/^\./}readdir DIR'

Решил в этот раз не заморачиваться с более менее правильным скриптом, переименовал/оттранслитил файлы перловым однострочником.

Принцип работы (вдруг кому пригодится): идём в папку, где лежат файлы, открываем её в терминале и выполняем команду. Однострочник читает список файлов в текущей директории и переименовывает все файлы, кроме тех, чьё имя начинается с точки.

P.S. Предварительно придётся поставить перловый модуль Lingua::Translit

$ sudo cpan -i Lingua::Translit
или
$ sudo cpanm Lingua::Translit
в зависимости от наличия cpan'а или cpanminus'а в системе.

P.P.S. Может быть потом как-нибудь не поленюсь и сделаю нормальный скрипт без лишних зависимостей.

Симлинки в shared папках под VirtualBox

С некоторых пор в гостевой системе под VirtualBox в примонтированной shared-папке нельзя создать симлинк. Связано это с безопасностью и в какой-то версии такую возможность по-дефлоту выключили, но оставили параметр, которым можно это поведение исправить. Какую-то информацию по теме можно подчерпнуть из тикета #10085.
Собственно, далеко не всегда гостевая ОС отдаётся посторонним лицам, которые могут попытаться набезобразничать, иногда VirtualBox ставится для своих нужд, и иногда симлинки действительно нужны и именно в примонтированных папках.

Итак. По-умолчанию при попытке создать симлинк из гостевой ОС в консоли получаем что-то вроде:
$ ln -s some/path/to/dir
ln: creating symbolic link `some/path/to/dir': Read-only file system

хотя файловая система совсем не read-only.

Выполняем
$ VBoxManage setextradata <vm_name> VBoxInternal2/SharedFoldersEnableSymlinksCreate/<share_name> 1

в моём случае это
$ VBoxManage setextradata centos VBoxInternal2/SharedFoldersEnableSymlinksCreate/www 1

Дальше, чтобы убедиться, что настройки сохранились, выполняем
$ VBoxManage getextradata <vm_name> enumerate

и видим появившуюся новую строку с нашей папкой.

Теперь перезапускаем VirtualBox (простого ребута гостевой ОС недостаточно) и спокойно создаём символические ссылки на примонтированной файловой системе.
Если рестарт виртуалбокса не помогает, то можно перезапустить его модули, после этого изменения точно учтутся при старте виртуальной машины.


P.S. Попутно добавлю.
Если при настройке shared-папок в VirtualBox поставить галку на автомонтирование

то система при старте сама будет пытаться примонтировать эту папку (само собой при условии, что установлены vbox guest additions).
Скорее всего дефолтное расположение примонтированной папки не устроит, тогда достаточно просто добавить запись в fstab
<share_name>   /<path/to/dir>        vboxsf     defaults,gid=502,uid=500,dmode=775,fmode=755   0 0
(uid,gid,dmode,fmode можно поправить по вкусу, либо убрать нафиг)

Теперь папка будет в правильном месте. И не нужно писать никаких скриптов для монтирования этой папки и пихать их в автозагрузку...

Resize virtual box virtual-hard-disk-drive

Появилась как-то необходимость увеличить размер virtual-hdd для vitrualbox. На деле оказалось, что ничего сложного в этом нет:

- в virtual media manager в самом virtualbox'е выбирем копирование/клонирование для требующего ресайза "диска"
- hard drive type указываем VDI
- обязательно выбираем динамически расширяемый (или как в рускоязычной vbox это называется) диск, а не фиксированного размера
- в консоли идём в папку, где лежит файл нового "диска" (необязательный пункт)
- выполняем в консоли
   $ VBoxManage modifyhd --resize <new_size_in_MB> disk-name-file
например
   $ VBoxManage modifyhd --resize 10000 disk1,vdi

Всё.
Дальше "подключаем" свежескопированноотресайзенный "диск" на место старого и можем запускать виртуальную машину.

P.S. Само собой разделы на "диске" не изменились, и если требуется не создание нового раздела, а увеличение существующего, то придётся воспользоваться сторонним софтом, благо нет проблем скачать небольшой livecd-образ и загрузившись в виртуалке с него через тот же gparted отресайзить разделы.