Вот, например, такую картину я вижу постоянно при соединении со своим сервером, когда сессия неактивна долгое время:

$ ssh host.com
Linux host.com 2.6.32.12-linode25 #1 SMP Wed Apr 28 19:25:11 UTC 2010 i686

20:51 [ctrld@host][~]
17:14 [ctrld@host][~] Write failed: Broken pipe

Через какое-то время я получаю “Write failed: Broken pipe”. В данном случае переподключиться вручную просто, но всегда найдётся ситуация, когда это сделать гораздо труднее.

Но есть полезная терминальная программа autossh. Она запускает ssh, производит мониторинг сессии и при необходимости её рестартует.

Устанавливаем autossh с помощью Homebrew:

$ brew update
$ brew install autossh

Ключи (если они необходимы) аналогичны ключам ssh, а особенности можно посмотреть в “man autossh”.

Теперь моя сессия с сервером держится до момента, когда я сам не выйду:

$ autossh host.com
Linux host.com 2.6.32.12-linode25 #1 SMP Wed Apr 28 19:25:11 UTC 2010 i686

10:03 [ctrld@host][~]
...
20:39 [ctrld@host][~] logout

На идею использования autossh меня натолкнуло обсуждение на StackOverflow по поводу организации доступа к внешним репозиториям git с хостов, которые не могут напрямую соединиться с ним по ssh.

Идея решения такова – в локальной сети должен быть хост dmz.host.com, имеющий возможность соединения по ssh с внешним репозиторием. Через этот хост строится туннель ssh:

internal.host.com$ autossh -M 20000 -f -N -L 2222:git.host.com:22 user@dmz.host.com

Затем на внутреннем хосте в ~/.ssh/config описывается, что нужно ходить на репозитории через туннель:

Host git.host.com
        HostName localhost
        Port 2222

Уточню – я пока этот рецепт не использую и работоспособность не протестировал. Однако всё выглядит очень правдоподобно.

Давно я не писал про преодоление защиты сетей. Наверстываю.

Все разы, когда я ездил за границу, в отелях практически всегда был нормальный доступ по WiFi на базе NAT (в основном через transparent proxy для авторизации, но никаких телодвижений по настройке прокси со стороны клиента не требовалось). Только два раза я натыкался на “тупые” конфигурации – один раз в московском отеле, другой – в Амстердаме. Для работы приходилось прописывать прокси, руководствуясь информацией, полученной на receiption.

Конечно же, ssh через web-прокси не работает. Как назло во втором случае мне было очень нужно попасть на мой сервер. Я собирался выкручиваться путём записи на свой сайт скрипта, обеспечивающего доступ к shell, например, PHP and AJAX shell console, но @andy_shev мне порекомендовал corkscrew, утилиту для туннелирования SSH поверх HTTP-прокси. Ею я и воспользовался, за что Andy огромное спасибо.

Одно “но”. Corkscrew использует метод CONNECT, а squid, использующийся в качестве web-прокси в большинстве случаев, в конфигурации по умолчанию разрешает CONNECT только на порт 443:

acl SSL_ports port 443
acl CONNECT method CONNECT
http_access deny CONNECT !SSL_ports

Поэтому corkscrew выдаст “Proxy could not open connnection to host.com: Forbidden” при попытке соединения на любой порт, на котором обычно вешается ssh. Мне повезло, так как я на своём сервере держал ssh на порту 443. Если и вы собираетесь воспользоваться corkscrew, то предварительно перекиньте ssh на 443/tcp.

Приступим. Я использую менеджер пакетов HomeBrew.

Обновляемся:

$ brew update

Ставим corkscrew:

$ brew install corkscrew

Предположим, прокси-сервер находится на адресе 192.168.99.101 и порту 3128. Добавляем в начало конфиг-файла ssh строки:

$ vim ~/.ssh/config
Host *
    ProxyCommand /usr/local/bin/corkscrew 192.168.99.101 3128 %h %p

Если ssh находится не на порту 443, и squid разрешает только порт 443, то получим сообщение (при указании флага “-v”):

$ ssh -v host.com
...
debug1: Reading configuration data /etc/ssh_config
debug1: Executing proxy command: exec /usr/local/bin/corkscrew 192.168.99.101 3128 host.com 22
...
Proxy could not open connnection to host.com:  Forbidden
ssh_exchange_identification: Connection closed by remote host

Для решения проблемы нужно предварительно в конфиг-файле sshd на сервере поменять порт на 443 и перезапустить sshd (конечно же, на этом хосте не должен стоять web-сервер с https):

$ vim /etc/ssh/sshd_config
Port 443

Перезапуск sshd для разных систем делается по-своему, я делаю это через “ps ax | grep sshd”, а потом перезапускаю нужный sshd.

Всё, можно пользоваться:

$ ssh -v -p 443 host.com
Linux host.com 2.6.32-linode23 #1 SMP Sat Dec 5 16:04:55 UTC 2009 i686

12:02 [ctrld@host][~] 

Решений для выход за пределы сети существует много. Описанный мною метод – только один из многих. Любой грамотный IT-специалист навскидку найдёт несколько вариантов, и по крайней мере один из них будет вполне рабочим. Поэтому я всегда скептически отношусь к заявлениям “Специалистов По Корпоративной Безопасности”, что они способны закрыть доступ.

$ ssh 10.10.10.10

Если для немного большей защиты ssh-сервер находится на нестандартном порту, то команда слегка усложняется:

$ ssh -p 12345 10.10.10.10

А если имена пользователей не совпадают на разных системах, то команда ещё усложняется:

$ ssh -p 12345 username@10.10.10.10

Или вот команда копирования файла (не правда ли, бывает путаница между “-p” и “-P”):

$ scp -P 12345 filename.zip username@10.10.10.10:

Но всё можно упростить. Для этого нужно в файл ~/.ssh/config внести свои хосты, например:

Host srv
    User username
    Port 12345
    HostName 10.10.10.10

И тогда вы с облегчением вздохнёте, вместо длинной команды начав набирать:

$ ssh srv
$ scp filename.zip srv:

Хостов можно определить много.

И ещё один хинт. Если у вас есть несколько рабочих систем, то файл .ssh/config можно вполне синхронизировать через Dropbox.

Проблема, с которой я столкнулся, оказалась странной. В Snow Leopard наконец-то Terminal.app стал нормально обрабатывать русские буквы в кодировке UTF-8, раньше же были проблемы с их отображением (они или “бились”, или же преобразовывались в набор восьмеричных чисел). Я вздохнул облегчённо – наконец-то я смог при работе в консоли комфортно писать по-русски.

Если же у вас до сих пор есть эта проблема, то прочитайте статью Папаши “Отбивные из терминала“, и у вас всё получится. Правильная конфигурация такая:

Но когда я начал переносить свой сайт на второй ноутбук, я работал в основном с ним по ssh, и вот тут-то столкнулся с такой ситуацией – в локальном Terminal.app русские буквы работают идеально, а вот при заходе на такой же Mac OS X 10.6 по ssh вместо текста получаю набор восьмеричных чисел:

И это при том, что при работе через Screen Sharing с удалённым ноутбуком эта проблема не проявляется:

“Хммм…”, – сказал я и многозначительно почесал затылок. В чём же разница? А разница при всех прочих равных условиях (профайлы-то одинаковы) заключается в переменных окружения, которые выставляются при установке соединения по ssh. Идея намечена, проверяю.

Захожу через Screen Sharing, запускаю Terminal.app и сбрасываю переменные окружения в файл:

$ set > set.local

Захожу туда же через ssh:

$ set > set.ssh

Сравниваю и нахожу нужную мне переменную:

$ diff -u set.ssh set.local
+LC_CTYPE=UTF-8

Опять захожу через ssh и пробую выставить её вручную

$ export LC_CTYPE=UTF-8

Ничего не меняется, значит настройка кодировки производится при запуске bash. Так, за это отвечает библиотека readline, а параметры bash, связанные с ней, можно посмотреть через “bind -v”. Повторяю процесс сравнения, в чём же разница:

(screen sharing) $ bind -v > bind.local
(ssh) $ bind -v > bind.ssh
$ diff -u bind.ssh bind.local
-set convert-meta on
+set convert-meta off

-set input-meta off
+set input-meta on

-set meta-flag off
+set meta-flag on

-set output-meta off
+set output-meta on

Нашёл. Чтобы эти параметры задействовать, их нужно поместить в файл ~/.inputrc и перезпустить bash:

$ cat ~/.inputrc
set convert-meta off
set input-meta on
set meta-flag on
set output-meta on

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

Проблема-то решена, но сделаем ещё один шаг. Конфигурации-то одинаковы, почему же переменная LC_TYPE не передаётся через ssh? Смотрю man ssh и в секции ENVIRONMENT нахожу, что при соединении ssh выставляются только такие переменные окружения: DISPLAY, HOME, LOGNAME, MAIL, PATH, SSH_ASKPASS, SSH_AUTH_SOCK, SSH_CONNECTION, SSH_ORIGINAL_COMMAND, SSH_TTY, TZ, USER. И самое ценное:

Additionally, ssh reads ~/.ssh/environment, and adds lines of the format “VARNAME=value” to the envi-ronment environment if the file exists and users are allowed to change their environment.

Удаляю на удалённом хосте (тавтология) файл ~/.inputrc, делаю файл ~/.ssh/environment и правлю /etc/sshd_config:

$ rm ~/.inputrc
$ vim ~/.ssh/environment
LC_CTYPE=UTF-8
$ vim /etc/sshd_config
...
PermitUserEnvironment yes
...

Перезапускать sshd не нужно. Захожу по ssh, и вижу, что переменная окружения LC_TYPE выставилась, и русские буквы работают.

Вот такие два метода решения проблемы я нашёл. Каким из них воспользоваться – выбирать вам. Мне нравится второй, но нужно знать и первый. Только что проделал трюк с PermitUserEnvironment на удалённом хосте с FreeBSD – и там тоже проблема с русскими буквами исчезла.

Update. Спасибо @Ivader за подсказку – более правильно вместо PermitUserEnvironment использовать AcceptEnv:

$ vim /etc/sshd_config
AcceptEnv LANG LC_*

К сожалению, сейчас не могу попробовать этот рецепт на Mac OS X, но он должен работать.

Предположим типичную для системного администратора задачу – есть сервер где-то в глубине сети, на который нужно попасть, предположим, по http, но консольный lynx/elinks не подходит, а нужен именно Safari/Firefox/Chrome (например, сайт на flash или нужна Java). Причём прямого доступа с ноутбука из Интернет на этот сервер нет, но есть “jumpbox” (сервер, исключительно через который открыт доступ по ssh в закрытую сеть). У меня такая ситуация была, когда нужно было попасть на IP-KVM внутри закрытой firewall’ом сети (я использовал ssl, но здесь для простоты покажу на примере порта 80).

Итак, имеем:

1. notebook. Находится в Интернет.
2. server1 (8.8.8.9). На него разрешён доступ по ssh (желательно использовать технику port-knocking для предоставления доступа к ssh только после нескольких запросов на разные порты этого сервера, иначе отбой).
3. server2 (9.9.9.1). Шлюз сети, но по ssh из Интернет на него попасть нельзя, на него открыт доступ по ssh исключительно с server1. Второй интерфейс сервера смотрит во внутреннюю сети и с него есть доступ на webserver
4. webserver (10.10.10.2). Доступ на web-сервер есть только из внутренней сети, в частности с server 2

Задача: с notebook получить доступ к webserver по http.

Шаг 1. На ноутбуке строим ssh-туннель на server1 (конечно же, туннелирование не должно быть запрещено в /etc/sshd_config – параметр PermitTunnel по умолчанию включен)

ssh user_on_server1@8.8.8.9 -L 2000:9.9.9.1:22 -N

Начало туннеля на ноутбуке (localhost, порт 2000), конец – на server2 на порту 22.

-N – не выполнять команды на удалённом хосте, полезно для туннелирования.

Шаг 2. Строим второй туннель поверх первого туннеля на webserver. Заметьте, что при соединии на порт 2000 на localhost соединение пробрасывается на 9.9.9.1 порт 22 (server2, и нужно вводить пароль пользователя именно на server2):

ssh -p 2000 user_on_server2@localhost -L 80:10.10.10.2:80 -N

Учтите, что web-sharing на ноутбуке должен быть отключен, иначе соединение не установится. Если же отключить его нельзя, то можно перекинуть на другой порт начало туннеля.
Получили туннель с началом на localhost, порт 80, и концом – на порту 80 webserver’а.

Шаг 3. Запускаем браузер и указываем http://127.0.0.1. Поверх двух туннелей заходим через Интернет на web-сервер во внутренней сети.

Если на web-сервере явно прописано имя сайта, как в wordpress (например, www.site.com), то первый же линк сайта уведёт с localhost на www.site.com. Если такое случилось, то делаем трюк, явно пишем в /etc/hosts:

127.0.0.1	www.site.com

Главное потом убрать эту строку, когда понадобится прямой доступ.

Туннелирование очень мощный инструмент, но с первого раза просто запутаться. Пару экспериментов – и всё станет понятно. Конфигурацию с web-сервером я привёл для примера. Точно так же можно организовать проброс для соединения с сервером Windows по RDC, на VPN SSL-сервер и т.п.

Как я сказал ранее, к аутентификации по публичным ключам нужно подходить ответственно. Ставить пустой passphrase грозит компрометацией ваших удалённых хостов. А каждый раз вводить passphrase не всегда возможно. Для того, чтобы достигнуть разумного компромиса, используется ssh-agent. Это программа, хранящая приватные ключи, используемые для аутентификации по публичным ключам RSA/DSA.

Генерируем ключ (для простоты я предварительно удалил все ключи, так как некоторые были без passphrase). Будем использовать DSA, любители RSA могут посмотреть разницу в предыдущей статье. Обязательно указываем хорошую passphrase:

$ ssh-keygen -t dsa
Generating public/private dsa key pair.
Enter file in which to save the key (/Users/ctrld/.ssh/id_dsa):
Enter passphrase (empty for no passphrase):
Enter same passphrase again:
Your identification has been saved in /Users/ctrld/.ssh/id_dsa.
Your public key has been saved in /Users/ctrld/.ssh/id_dsa.pub.
The key fingerprint is:
12:1b:02:27:8b:70:44:0b:2c:3f:9c:4b:d0:ef:d9:5e ctrld@129-149-179-94.pool.ukrtel.net
The key's randomart image is:
+--[ DSA 1024]----+
|++* .            |
|+=.*             |
|o+oo. o          |
|  * .. +         |
| . + oo S        |
|  . o ..E        |
|     . .         |
|      .          |
|                 |
+-----------------+

Делаем по аналогии с предыдущей статьёй.

Копируем ключ

$ cat ~/.ssh/id_dsa.pub
ssh-dss AAAAB3...60QnQ== ctrld@hostname.local

Идём на удалённую машину и записываем этот публичный ключ в ~/.ssh/authorized_keys2 (желательно удалить из него ваши старые ключи):

$ vi ~/.ssh/authorized_keys2
$ chmod 600 ~/.ssh/authorized_keys2

Выходим, проверяем работу. А вот теперь удивляемся :-) ssh-agent и так запущен на Mac OS X, и мы получаем окошко, в котором вводим ключ, причём его можно запомнить в keychain:

Теперь, несмотря на то, что ваш ключ использует passphrase, она не будет запрашиваться. Я не могу сейчас ответить, сколько именно времени он не будет запрашиваться.

Если же вы уходите, но по какой-то причине даёте поработать кому-то на вашем Маке, да ещё под вашим account’ом (ладно, пример неудачный, этот кто-то может попытаться посмотреть ваш keychain, и если он не запаролен, то узнает ваш ключ), то можете заблокировать доступ к ssh-agent, и при попытке соединения будет снова запрашиваться passphrase.

Блокировка (нужно указать любой пароль):

$ ssh-add -x
Enter lock password:
Again:
Agent locked.

Разблокировка (с запросом установленного пароля)

$ ssh-add -X
Enter lock password:
Agent unlocked.

Если вдруг ssh-agent не запущен, то его можно запустить самому (детальнее – в “SSH and ssh-agent“):

$ eval `ssh-agent`

Перечень всех добавленных ключей:

$ ssh-add -l
1024 12:1b:02:27:8b:70:44:0b:2c:3f:9c:4b:d0:ef:d9:5e /Users/ctrld/.ssh/id_dsa (DSA)

Ручное добавление ключей из ~/.ssh:

$ ssh-add
Enter passphrase for /Users/ctrld/.ssh/id_dsa:
Identity added: /Users/ctrld/.ssh/id_dsa (/Users/ctrld/.ssh/id_dsa)

Давайте рассмотрим, как настроить аутентификацию.

Действия на локальном компьютере

Ключи находятся в каталоге ~/.ssh:

$ ls -al ~/.ssh/
total 32
drwx------   6 ctrld  staff   204 Oct 23 17:39 .
drwxr-xr-x+ 40 ctrld  staff  1360 Oct 22 21:01 ..
-rw-r--r--   1 ctrld  staff    78 Sep 26 20:02 config
-rw-------   1 ctrld  staff   668 Oct 23 17:39 id_dsa
-rw-r--r--   1 ctrld  staff   626 Oct 23 17:39 id_dsa.pub
-rw-r--r--   1 ctrld  staff  2410 Oct 13 11:44 known_hosts

Если каталог .ssh отсутствует, то достаточно попытаться зайти куда-нибудь по ssh. Если файлов id_dsa.* (я использую DSA, но можно и RSA) нет, то их нужно сгенерировать. Во время генерации ssh-keygen спросит passphrase (можно просто нажать Enter и она при входе не будет спрашиваться).

$ ssh-keygen -t dsa
Generating public/private dsa key pair.
Enter file in which to save the key (/Users/ctrld/.ssh/id_dsa):
Enter passphrase (empty for no passphrase):
Enter same passphrase again:
Your identification has been saved in /Users/ctrld/.ssh/id_dsa.
Your public key has been saved in /Users/ctrld/.ssh/id_dsa.pub.
The key fingerprint is:
e3:9a:18:f0:4c:6e:3e:44:8f:d3:a3:cc:c2:db:e0:b5 ctrld@129-149-179-94.pool.ukrtel.net
The key's randomart image is:
+--[ DSA 1024]----+
|                 |
|                 |
|                 |
|    .            |
|  ...+  S        |
|   *+ +. .       |
| ..+Bo ..        |
| .o*=+ o         |
|  ooE.o          |
+-----------------+

Если вы предпочитаете RSA, то:

$ ssh-keygen -t rsa

Копируем строку с публичным ключом – он нам понадобится на удалённом компьютере (remote, а не removed :)

$ cat ~/.ssh/id_dsa.pub
ssh-dss AAAAB3............Pbec= ctrld@hostname.local

Для RSA:

$ cat ~/.ssh/id_rsa.pub
ssh-rsa AAAAB3............IJAw== ctrld@hostname.local

Действия на удалённом компьютере

Конечно же, на удалённом сервере должен быть запущен SSH-сервер. Обычно это OpenSSH, но встречаются и недобитые динозавры с коммерческими SSH-серверами (это вызывает моё искреннее удивление – да, есть и такое).

Заходим на удалённый сервер:

$ ssh ctrld@remote.net

Проверяем, есть ли каталог .ssh:

$ ls -al ~/.ssh

Если его нет, то делаем простой трюк – “ssh ctrld@localhost”, и .ssh создаётся автоматически.

Редактируем файл с публичными ключами, и добавляем соответствующий скопированный ключ.

Для DSA (authorized_keys2):

$ vi ~/.ssh/authorized_keys2

Вариант:

$ echo "ssh-dss AAAAB3............Pbec= ctrld@hostname.local" >> ~/.ssh/authorized_keys2

Для RSA (authorized_keys):

$ vi ~/.ssh/authorized_keys

Сохраняем файл, и (!) обязательно меняем права доступа на 0600, иначе файл публичных ключей не будет восприниматься:

$ chmod 600 ~/.ssh/authorized_keys*

Выходим с удалённого компьютера и пытаемся зайти на него снова по ssh. Если всё было сделано правильно, то будет запрошен passphrase, а если он был пустой, то будет произведён вход без запроса.

Альтернатива – скрипт ssh-copy-id

@andy_shev и @akaDimiG порекомендовали гораздо более простой вариант – использовать скрипт ssh-copy-id (по домену вижу, что это разработчики Putty, поэтому доверять можно). Но его первый недостаток в том, что он не входит в штатную поставку Mac OS X. Списать скрипт можно по простому рецепту:

sudo curl "http://www.chiark.greenend.org.uk/ucgi/~cjwatson/cvsweb/openssh/contrib/ssh-copy-id?rev=1.8;content-type=text%2Fplain" -o /usr/bin/ssh-copy-id
sudo chmod +x /usr/bin/ssh-copy-id

Второй недостаток – для использования нестандартных портов ssh скрипт нужно модифицировать. Третий – он использует ключи RSA, я же – DSA. Но если вас эти недостатки не смущают, то скрипт можно вполне использовать. Я же буду пользоваться описанным выше методом :-)

А вот скрипт с MacOSXHints, который мне понравился гораздо больше (спасибо за ссылку @akaDimiG):

#!/bin/sh

KEY="$HOME/.ssh/id_dsa.pub"

if [ ! -f ~/.ssh/id_dsa.pub ];then
    echo "private key not found at $KEY"
    echo "* please create it with "ssh-keygen -t dsa" *"
    echo "* to login to the remote host without a password, don't give the key you create with ssh-keygen a password! *"
    exit
fi

if [ -z $1 ];then
    echo "Please specify user@host.tld as the first switch to this script"
    exit
fi

echo "Putting your key on $1... "

KEYCODE=`cat $KEY`
ssh -q $1 "mkdir ~/.ssh 2>/dev/null; chmod 700 ~/.ssh; echo "$KEYCODE" >> ~/.ssh/authorized_keys; chmod 644 ~/.ssh/authorized_keys"

echo "done!"