Когда-то я писал о личном опыте использования Sublime Text 2, а после выхода Sublime Text 3 решил начать новую статью, ориентированную именно на версию 3 с небольшим акцентом на миграцию с 2 на 3.
Sublime Text — это профессиональный программерский текстовый редактор. Он завоевал очень большую популярность благодаря проработанности интерфейса, кроссплатформенности, удобной и простой расширяемости плагинами. Мои впечатления со времён написания первой статьи не особо изменились, поэтому я второй раз их переписывать не буду.
Создать файл ~/.gimp-2.8/fonts.conf вот с таким содержимым:
<fontconfig>
<match target="font">
<edit name="rgba" mode="assign">
<const>none</const>
</edit>
</match>
</fontconfig>
Изначально проблема проявляется так: на краю отрендеренного текста цветные пятна.
Это древний текст, вместо него была написана более общая и систематизированная статья о многих аспектах использования SSH: Эффективная работа с SSH
В SSH есть крайне полезная фича, позволяющая организовать прозрачный проброс трафика через практически любой SSH-сервер. Принцип туннелирования простой: подключаемся к ssh-серверу со специальными опциями и получаем SOCKS-прокси, висящий на указанном в опциях порту локальной машины. Что самое приятное — на удалённой машине не надо ставить никакой софт, плюс необязательно быть суперпользователем, достаточно обычного аккаунта.
Дальше я детально опишу сценарий настройки и конфигурации такой системы.
В файле ~/.ssh/config можно писать алиасы для используемых хостов, указывать для разных хостов разные ключи и так далее.
Host home
HostName home.example.com
Port 1488
Ciphers arcfour,blowfish-cbc
Compression yes
CompressionLevel 9
Host github.com
IdentityFile ~/.ssh/id_rsa-github
Host bitbucket.org
IdentityFile ~/.ssh/id_rsa-bitbucket
Здесь написано о GnuPG, как им пользоваться и при этом понимать, что делаешь. Изначально статья была написана в 2013 году, несколько раз слегка обновлялась, а в 2023 была значительно переработана и дополнена актуальной информацией.
GnuPG (GNU Privacy Guard, официальный сайт gnupg.org) — это опенсорсная реализация открытого стандарта OpenPGP, изложенного в RFC 4880. GnuPG состоит из набора программ и библиотек, однако нас будет интересовать только консольная программа gpg. Она существует под все операционные системы, однако наиболее комфортно используется в linux и macos. По gnupg есть множество материалов, однако из-за высокой сложности базовых концептов, всегда есть что добавить или объяснить.
В линуксах gnupg ставится из штатного репозитория, для макоси можно поставить из macports, brew, но я рекомендую GPG Suite. Все эти способы предоставляют вам консольную программу gpg с одинаковыми командами на всех операционках. Текущая актуальная версия GnuPG 2.2 и вся статья отталкивается именно от неё. Многие команды в принципе применимы и для более старых версий.
Между разными версиями gnupg формат хранения данных в каталоге с конфигурацией несколько раз менялся и связанные с этим термины типа keyring уже во многом устарели, поэтому в обновлённой версии я постараюсь не углубляться в конкретные детали реализации и слова типа keyring/кейринг тут использоваться не будут. Чтобы подчеркнуть относительность конфигурации, я буду использовать слово конфиг, под которым вы должны понимать выбранный каталог с конфигурацией. Также я не буду вдаваться в эзотерические команды или свойства подписей, который никем нигде не используются.
Когда я рассказываю о концепциях, то обычно использую термин OpenPGP, когда рассказываю о конкретных прикладных командах, то использую gpg или gnupg.
Типичная ситуация: коннектимся с машины M1 на машину M2 через SSH, затем на машине M2 меняем юзера через sudo и хотим там запустить X11-приложение, чтобы оно открылось на дисплее машины M1. Это может быть, например, отладчик или графическая гуйня к базе.
Дальше я по шагам распишу все этапы подключения с комментариями.
Постоянно нужно и всегда забываю.
% arecord - | aplay -
encfs позволяет прозрачно шифровать каталог с файлами, используется достаточно надёжный метод, такой каталог можно сравнительно безбоязненно положить в Dropbox, например. Для доступа этот каталог монтируется через fuse с вводом пароля, после чего с ним можно работать как с обычным каталогом, все данные перешифровываются на лету.
В debian/ubuntu ставится в два шага:
# apt-get install encfs
# adduser USER fuse
После чего перелогиниться, чтобы пользователь проявился в группе fuse.
Эта вот строчка мне каждый раз мозг выносит — куда воткнуть NOPASSWD в sudoers, чтобы заработало:
%sudo ALL=(ALL:ALL) ALL
А разгадка проста:
%sudo ALL=(ALL:ALL) NOPASSWD:ALL
И ещё одни важные грабли: срабатывает последнее правило, которое заматчило. Например, если вы хотите для себя одного сделать исключение в виде NOPASSWD, добавьте это правило в самом конце файла для гарантии, иначе может не сработать.
Это древний текст, вместо него была написана более общая и систематизированная статья о многих аспектах использования SSH: Эффективная работа с SSH
Аккаунт на ssh-сервере можно легко использовать для создания SOCKS-прокси, причём для этого достаточно обычного непривилегированного аккаунта. Всё делается очень просто (подключаемся к серверу example.com под юзером user):
% ssh -D 127.0.0.1:13388 [email protected]
Запускается с виду обычная ssh-сессия, оставляем её в таком виде, а дальше указываем в клиенте (веб-браузере, например) адрес SOCKS-прокси 127.0.0.1, порт 13388 и пользуемся.
По сути ssh-клиент организует туннель, по которому гоняется трафик. Особенным плюсом является то, что на стороне сервера не нужно вообще никакого специального софта, помимо стандартного ssh-сервера.
Другой полезный рецепт — создание туннеля до конкретного сетевого сервиса, работающего на удалённом сервере или доступного только с удалённого сервера. Делается это так:
% ssh -L LOCAL_ADDR:2222:HOST_ADDR:80 [email protected]
LOCAL_ADDR можно опустить, тогда будут использованы все локальные сетевые интерфейсы:
% ssh -L 2222:HOST_ADDR:80 [email protected]
При этом происходит следующее: все соединения с локальной машины к адресу LOCAL_ADDR:2222 (для бо́льшей безопасности можно указывать LOCAL_ADDR равным 127.0.0.1 или localhost) будут перенаправляться через SSH-соединение и уже с компьютера на другом конце отправляются на адрес HOST_ADDR:80. По такому принципу можно пробрасывать любое сетевое соединение; самый простой пример — до http-сервера, видного только в сети ssh-сервера, или до сервера базы данных.
Вот пример для пробрасывания подключения до сервера mysql, доступного в удалённой сети по адресу 192.168.3.12 и порту 3306:
% ssh -L 127.0.0.1:5900:192.168.3.12:3306 [email protected]
Естественно, все эти опции можно задавать через конфиг ssh-клиента, создавая нечто вроде «профилей подключения» для разных туннелей и сервисов. Об этом я напишу чуть позднее.
Другие статьи на эту же тему¶
- Меняем ssh-agent на gpg-agent
- Параноидальная настройка ssh-agent в Mac OS X Mavericks
- SOCKS-прокси через SSH
- Безопасный ssh-туннель
История изменений¶
- 2013-01-22: изначальная версия