SSH Agent auto add keys

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

Host *
UseKeychain yes
AddKeysToAgent yes
IdentityFile ~/.ssh/id_rsa
IdentityFile ~/.ssh/id_25519

Один раз перечисляем все нужные ключи в начале ~/.ssh/config, и все. 

Краткий экскурс в sslh

Доступ ко многим сервисам (особенно в публичных местах или при проксированном доступе на рабочем месте) "из коробки" не работает: что SSH, что OpenVPN, что Jabber, что $еще_стопицот_нужных_сервисов требуют NAT или разрешенный порт на прокси для подключения к удаленной точке. Если таких настроек нет - соединение установить не удастся. 

Однако на сегодняший день реалии таковы, что любой, пусть даже самый ограниченный, доступ к интернет-ресурсам подразумевает разрешенные исходящие соединения на 443/tcp. А это значит, что при наличии собственного сервера в интернете, мы можем получить доступ к нему (или куда-либо еще) с помощью демона sslh.

Этот демон висит на внешнем (доступном из Сети) IP и слушает 443 порт, анализируя входящий трафик. По заголовкам пакетов он определяет "чьих будете" и перенаправляет трафик на соответствующий внутренний адрес и порт. По умолчанию на сегодняший день поддерживаются HTTP, SSL, SSH, OpenVPN, tinc, XMPP, а также существует возможность описать любой другой протокол, задав уникальный для его однозначного определения regex. 

Разработчики заявляют, что sslh опакечен для многих дистрибутивов (Debian точно есть), но даже если и врут, собрать свежую версию из исходников быстро и просто.

Например, для моего сервера с устаревшим уже Squeeze это будет выглядеть примерно так (в репозитории пакет доступен, однако его версия не умеет иных протоколов, кроме ssh\ssl):

Загружаем исходники:

wget http://www.rutschle.net/tech/sslh-1.15.tar.gz

Распаковываем и переходим в каталог:

tar -zxvf sslh-1.15.tar.gz

cd sslh-1.15.tar.gz

Читаем README, узнаем, что для сборки необходимы заголовочные файлы библиотек libconfig и libwrap. Устанавливаем оные (при необходимости нужно установить набор пакетов для сборки - build-essential):

apt-get install libconfig8-dev libwrap0-dev

Ввиду малого объема кода настройка через configure-скрипт не используется, все изменения в конфигурацию по умолчанию следует внести прямо в Makefile. Меняем PREFIX на

PREFIX=/usr

Далее пробуем собрать бинарник:

make

Если процесс завершился без ошибок, устанавливаем sslh (для Debian сделана специальная цель в Makefile, поэтому используется не make install):

make install-debian

Настраиваем форвардинг нужных нам сервисов (в файле /etc/default/sslh):

LISTEN=server.example.org:443
SSH=localhost:22
SSL=localhost:443
XMPP=localhost:5222
USER=nobody
PID=/var/run/sslh.pid

В предложенном примере sslh будет запущен на интерфейсе с адресом server.example.org:443 (можно указать и IP-адрес). Перед запуском следует убедиться, что порт 443/tcp на желаемом адресе не занят, иначе sslh не сможет запуститься. Форвардиться на внутренний интерфейс будут доступны по умолчанию сервисы SSL, SSH и XMPP. Запустится sslh от имени пользователя nobody, а свой PID запишет в /var/run/sslh.pid

Все, запускаем sslh:

/etc/init.d/sslh star

Да, выяснилось, что init-файл подставляет в строку запуска демона только переменные SSL и SSH, то есть ничего другое (из протоколов) при старте демону не передастся. Лечится ручным добавлением соответствующего параметра. Например, для запуска с форвардингом XMPP я меняю в /etc/init.d/sslh

 start()
{
        echo "Start services: sslh"
        $DAEMON --user ${USER} --listen ${LISTEN} --ssh ${SSH} --ssl ${SSL} --pidfile ${PID}
        logger -t ${tag} -p ${facility} -i 'Started sslh'
}

на

  start()
{
        echo "Start services: sslh"
        $DAEMON --user ${USER} --listen ${LISTEN} --ssh ${SSH} --ssl ${SSL} --xmpp ${XMPP} --pidfile ${PID}
        logger -t ${tag} -p ${facility} -i 'Started sslh'
}

Итак, после запуска в списке сервисов должно быть примерно следующее:

 # ps aux | grep sslh

nobody   13923  0.0  0.0   2084   528 ?        Ss   20:30   0:00 /usr/sbin/sslh --user nobody --listen server.example.org 443 --ssh localhost 22 --ssl localhost 443 --xmpp localhost 5222 --pidfile /var/run/sslh.pid
nobody   13925  0.0  0.0   2084   224 ?        S    20:30   0:00 /usr/sbin/sslh --user nobody --listen server.example.org 443 --ssh localhost 22 --ssl localhost 443 --xmpp localhost 5222 --pidfile /var/run/sslh.pid
nobody   29435  0.0  0.0   2296   676 ?        S    20:49   0:00 /usr/sbin/sslh --user nobody --listen server.example.org 443 --ssh localhost 22 --ssl localhost 443 --xmpp localhost 5222 --pidfile /var/run/sslh.pid

Почему сервисов несколько? Ответ есть в README: sslh собирается в два бинарника - sslh-fork, который запускает новый процесс при каждом новом потоке данных (подключении), и sslh-select, который держит все потоки внутри одного процесса. По умолчанию предлагается fork-вариант, как более стабильный. Однако, если предполагается поддерживать много соединений (несколько сотен), или просто не нравится множество одинаковых процессов в top-е, можно заменить sslh-fork на sslh-select (выполняется из каталога, где собирался sslh):

/etc/init.d/sslh stop

cp sslh-select /usr/sbin/sslh

/etc/init.d/sslh start

После этих операций процесс будет лишь один:

nobody    8956  0.0  0.0   2088   536 ?        Ss   21:43   0:00 /usr/sbin/sslh --user nobody --listen server.example.org 443 --ssh localhost 22 --ssl localhost 443 --xmpp localhost 5222 --pidfile /var/run/sslh.pid

Более сложные конфигурации - к примеру, проксирование или прозрачный режим работы, можно почитать в README.

Отключение ssh fingerprints

В клиенте ssh имеется замечательный механизм защиты от возможных Man-In-The-Middle атак при работе с удаленными хостами. При попытке подключиться к ранее неизвестному хосту впервые считывается его fingerprint

The authenticity of host 'example.com (192.168.0.1)' can't be established.
RSA key fingerprint is 0e:33:94:9b:83:b1:d8:02:81:42:0f:0e:4c:c2:cd:98.
Are you sure you want to continue connecting (yes/no)?

и записывается в файл ~/.ssh/known_hosts

Warning: Permanently added 'example.com,192.168.1.1' (RSA) to the list of known hosts.

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

:~$ ssh interra@192.168.0.1
@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@
@    WARNING: REMOTE HOST IDENTIFICATION HAS CHANGED!     @
@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@
IT IS POSSIBLE THAT SOMEONE IS DOING SOMETHING NASTY!
Someone could be eavesdropping on you right now (man-in-the-middle attack)!
It is also possible that the RSA host key has just been changed.
The fingerprint for the RSA key sent by the remote host is
e5:98:85:24:bd:62:f1:2f:9a:ab:f5:9f:24:e8:88:5c.
Please contact your system administrator.
Add correct host key in /home/delayer/.ssh/known_hosts to get rid of this message.
Offending key in /home/delayer/.ssh/known_hosts:212
RSA host key for 192.168.0.1 has changed and you have requested strict checking.
Host key verification failed.

Однако у меня в локалке это вызывает сильное неудобство, так как в сети часто появляются новые хосты (сервер приехал, настроился, уехал), которые получают одни и те же IP-адреса из заданного пула. И каждый раз приходится удалять запись о старом фингерпринте из known_hosts. 

Дабы этого не делать, а полностью отключать этот в целом полезный механизм, изменяем настройки ssh следующим образом (глобально - в /etc/ssh/ssh_config; для пользователя - ~/.ssh/config):

Host 192.168.0.*
   StrictHostKeyChecking no
   UserKnownHostsFile=/dev/null

И все, при подключении к хостам сети 192.168.0.0/24 фингерпринт проверяться не будет.

sshuttle -- transparent proxy server for VPN over SSH

Проматривая очередной дайджест Debian Project News, узнал о добавлении в unstable-репозиторий софтинки

* sshuttle -- transparent proxy server for VPN over SSH [51]
   51 : http://packages.debian.org/unstable/main/sshuttle

 Более подробно о том, что реализует эта утилита, можно почерпнуть из README на github-странице проекта. Если в трех словах да по-русски, sshuttle дает возможность получить доступ ко всем сетевым ресурсам удаленной подсети (или конкретного хоста в оной), имея лишь пользовательский ssh-доступ, причем как с компьютера, организовавшего подключение (инициаотора ssh-подключения), так и с любой рабочей станции из расположенной за ним локалки, если этот компьютер является шлюзом или может выполнять его функции. Короче, в мемориз.

Да, на удаленной стороне нужен лишь ssh и установленный питон (а где его щас не ставится).

Заполнение known_hosts

Иногда при настройке рабочей станции пользователя на базе Linux, или при создании образа тонкого клиента (особенно в этом случае!), или просто при загрузке образа с системой по сети требуется заполнить файл /home/user/.ssh/known_hosts, дабы ssh при подключении не ругался непонятными для человека буквами и цифрами. Вот как легко и просто это сделать:

ssh-keyscan -t rsa $server_ip >> ./known_hosts

О том, что это вообще за механизм такой, можно поглядеть, к примеру, тут. Или где-нибудь еще из выдачи Google. $)

ClusterSSH

Оказывается, есть такая круть. Как использовать это счастье - чтить сюда. Есть в репах Деба/Убунты.

Медленные ssh-соединения

Проблема: при хождении к удаленному linux-хосту с linux же машинки по ssh (авторизация по ключу), налицо некоторая задумчивость ssh-а. Запуск в verbose mode ( ssh -v) выдает много чего, но интерес вызвали следующие строки:

debug1: An invalid name was supplied
Cannot determine realm for numeric host address

debug1: An invalid name was supplied
A parameter was malformed
Validation error

debug1: An invalid name was supplied
Cannot determine realm for numeric host address

debug1: An invalid name was supplied
A parameter was malformed
Validation error

Гуглинг и "ман ридинг" привели к следующему решению.  В настройках ssh-клиента, глобальных (/etc/ssh/ssh_config), или локальных (~/.ssh/config) запрещаем GSSAPIAuthentication: GSSAPIAuthentication no. Проблема перестает проявляться после реконнекта к удаленному хосту, так как ssh перечитывает конфиги (локальный приритетнее) при создании новой сессии.