Веб-сервер lighttpd

До недавнего времени, Apache не имел серьезных конкурентов с открытым исходным кодом. В последнем обзоре веб-серверов, проведенном Netcraft, мы можем видеть нечто новое. Как и обычно, Apache возглавляет список, Microsoft IIS второй, а знаменитый unknown — третий. Четвертым является Sun Java Web Server (ранее известный как ONE, бывший iPlanet, бывший Netscape). Но пятым номером, обслуживая около 1,4 миллиона сайтов, нечто под названием lighttpd. Откуда это взялось? Мы изучим историю lighttpd, начальную установку и настройку, а также некоторые взгляды на будущее проекта.

Вы можете произносить это название как лайт-ти-пи-ди или, меньше плюясь, лайти. Как бы вы не говорили/выплевывали название этого веб-сервера, вы найдете много информации на его веб-сайте, вики, блоге, или на форумах. lighttpd проектировался как высокоэффективный веб-сервер с низким использованием ресурсов. Он использует гораздо меньше памяти, чем Apache и, как правило, работает быстрее. lighttpd тихо усиливает много высоконагруженных сайтов, включая YouTube, Wikipedia, Meebo и A List Apart; вы увидете, что он часто используется вместо Apache вместе с популярными инструментами, такими как Ruby on Rails и Trac.

Что не так с Apache?

Не смотря на свою популярность, иногда использование Apache не является лучшим решением. Apache предоставляет различные Мульти-Процессные Модели (MPMs) для использования в различных средах работы. Модель prefork — наиболее популярная в Linux — создает определенное число процессов Apache при его запуске и управляет ими в пуле. Альтернативной моделью является worker, которая использует несколько потоков вместо процессов. Хотя потоки легче, чем процессы, вы не можете их использовать до тех пор, пока весь ваш сервер не будет безопасен для потоков (thread safe). Хотя Apache и mod_php — безопасны для потоков, это не гарантирует, что все сторонние модули могут использоваться. Сайт PHP не одобряет использование Apache 2 с потоковой MPM; это замедляет переход разработчиков с Apache 1.3 на 2.x. А модель prefork имеет свои проблемы: каждый процесс (Apache + PHP + сторонние модули) занимает много памяти (30 МБ не является чем-то необычным). Когда вы увеличиваете число одновременных процессов Apache, доступная вам память может быстро кончиться.

lighttpd в тумане.

Некоторые сайты параллельно обрабатывают тысячи файлов, будучи при этом ограничены в памяти и максимальным числом потоков или процессов. Дэн Кегел (Dan Kegel) подробно описал проблемы при обработки тысяч одновременных запросов на своей странице в C10K problem. В 2003 немецкий разработчик MySQL по имени Ян Кнешке (Jan Kneschke) заинтересовался в этой проблеме и решил, что сможет написать веб-сервер, который будет быстрее Apache, сфокусировавшись на правильных методиках. Он спроектировал lighttpd как один процесс с одним потоком и неблокирующимся вводом-выводом. Вместо select, он использовал быстрейшие обработчики событий в целевой системе: poll, epoll, kqueue или /dev/poll. Он выбрал безэкземлярные системные вызовы, как sendfile вместо read и write. В течение нескольких месяцев lighttpd стал обрабатывать статичные файлы быстрее, чем Apache.

Следующим шагом было обработать динамические (CGI) приложения, в частности PHP. Кнешке сдул пыль с FastCGI, разработанном Open Market в самых ранних днях существования интернета, в целях улучшения работы CGI. Вместо того, чтобы веб-сервер запускал ту же внешнюю CGI-программу при каждом вызове, FastCGI по существу был демоном для предварительного запуска CGI-приложения и управления связью между ним и веб-сервером. Это было быстрее, но Perl и PHP позже были внедрены в Apache в качестве модулей, которые были даже быстрее и получали доступ к внутренним действиям Apache по обработке HTTP. FastCGI для Apache стал пренебрегаться, но после того, как он был добавлен в lighttpd и к нему подключили PHP, его производительность равнялась или превышала ту, что показывал Apache с mod_php. В качестве дополнения, в реализацию lighttpd была добавлена автоматическая балансировка загрузки.

lighttpd был также расширен модулями для управления виртуальными хостами, переадресации, перезаписи URL, аутентификации и других полезных вещей. В большинстве случаев, все, что вы можете сделать в Apache, вы можете сделать в lighttpd. В следующих разделах я покажу, как установить и настроить lighttpd с оглядкой на Apache.

Установка lighttpd.

Давайте установим lighttpd и поковыряемся в нем образными палочками. Страница установки на вики дает примеры установки бинарников или из исходников для различных дистрибутивов Linux. Для разработчиков с волосатой грудью (эти волосы не обязательно должны быть вашими), полная установка из исходников выглядит так:

    # wget http://www.lighttpd.net/download/lighttpd-1.4.13.tar.gz
    # tar xvzf lighttpd-1.4.13.tar.gz
    # cd lighttpd-1.4.13
        # ./configure
    # make
    # make install

Это установит lighttpd в /usr/local. Если сборка не удалась, проверьте, что требуемые пакеты разработки pcre и zlib установлены в вашей системе.

Если вы хотите запускать и останавливать lighttpd вручную, то вперед. А чтобы установить lighttpd как сервис вроде Apache, отредактируйте и установите скрипт инициализации:

    # sed -e 's/FOO/lighttpd/g' doc/rc.lighttpd > lighttpd.init
    # chmod a+rx lighttpd.init
    # cp lighttpd.init /etc/init.d/lighttpd
    # cp -p doc/sysconfig.lighttpd /etc/sysconfig/lighttpd
    # install -Dp ./doc/lighttpd.conf /etc/lighttpd/lighttpd.conf
        # chkconfig lighttpd on

Начальная настройка.

С виду синтаксис файлов настройки lighttpd может иметь отличия от Apache. Примеры со страницы настройки из вики выглядят больше похожими на Perl (или PHP, или Python), нежели чем на стиль XML httpd.conf в Apache. Для простого сайта со статическими файлами, вам нужно указать те же вещи, что и в Apache: document root, расположение access и error логов и имена user и group для работы сервера. Вот эквивалентные варианты Apache (httpd.conf) и lighttpd (lighttpd.conf):

Apache:

DocumentRoot /var/www/html
 
CustomLog /var/www/logs/access
 
ErrorLog /var/www/logs/error
 
User www
 
Group www

lighttpd:

server.document-root = "/var/www/html"
 
accesslog.filename = "/var/www/logs/access"
 
server.errorlog = "/var/www/logs/error"
 
server.username = "www"
 
server.groupname = "www"
 
server.modules = ( "mod_accesslog" )

Механизм включения модулей в lighttpd похож на тот, что в Apache, так что файл lighttpd.conf не должен расти. Чтобы использовать дополнительный модуль, вам нужно включить его и установить его опции. В Apache это делается с помощью LoadModule, а lighttpd просто включает незакомментированный модуль в массиве server.modules. Пока что вам нужен только mod_accesslog.

Аутентификация и авторизация.

lighttpd не поддерживает файлы .htaccess, так что вам нужно указывать все настройки в файле lighttpd.conf, или в файлах, к нему подключенным. Он понимает файлы пользователей Apache для простой и общей аутентификации, но поддержка групповых файлов ещё не реализована. Вот пример, как защитить паролем высокоуровневый каталог под названием special:

Apache:

  AuthName "My Special Directory"
 
  AuthType Basic
 
  AuthUserFile /var/www/passwords/users
 
  Order deny,allow
 
  require valid-user

lighttpd:

auth.backend = "htpasswd"
 
auth.backend.htpasswd.userfile = "/var/www/passwords/users"
 
auth.require = ( "/special/" =>
 
  (
 
  "method"   => "basic",
 
  "realm"    => "My Special Directory",
 
  "require"  => "valid-user"
 
  )
 
)

Виртуальные хосты.

Вот другая задача для вашего нагруженного и недооцененного веб-сервера: управлять двумя сайтами с названиями scratch.example.com и sniff.example.com:

Apache:

NameVirtualHost *
 
  ServerName "scratch.example.com"
 
  DocumentRoot "/var/www/hosts/scratch/docs"
 
  ServerName "sniff.example.com"
 
  DocumentRoot "/var/www/hosts/sniff/docs"

lighttpd:

$HTTP["host"] == "scratch.example.com" {
 
  server.document-root = "/var/www/hosts/scratch/docs/" }
 
$HTTP["host"] == "sniff.example.com" {
 
  server.document-root = "/var/www/hosts/sniff/docs/" }

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

Apache:

LoadModule vhost_alias_module modules/mod_vhost_alias.so
 
VirtualDocumentRoot /var/www/hosts/%1/docs

lighttpd:

server.modules = ( ..., "mod_evhost", ... )
 
evhost.path-pattern = "/var/www/hosts/%3/docs"

Server-Side Includes (SSI)

Первым шагом к динамическому контенту будет простое включение SSI для файлов с расширением .shtml:

Apache:

AddHandler server-parsed .shtml

lighttpd:

server.modules = ( ..., "mod_ssi", ... )
 
ssi.extension = ( "shtml" )

PHP

lighttpd оптимизирует производительность обработки статичного файла с помощью выгрузки динамического контента, загружающего ЦПУ в другой процесс. Вместо обработки PHP внутри, как делает Apache с mod_php, lighttpd передает эту задачу FastCGI. Следующие примеры конфигурации превращают скучные, безжизненные .php-файлы в живые PHP скрипты. Чтобы ознакомиться с более пикантными деталями, чем те, что мы можем показать на этом сайте, посмотрите эту страницу.

Apache:

LoadModule php5_module modules/libphp5.so
 
AddType application/x-httpd-php .php

lighttpd:

server.modules = ( ..., "mod_fastcgi", ... )
 
fastcgi.server =
 
  ( ".php" =>
 
    ( "localhost" =>
 
      (
 
      "socket" => "/tmp/php-fastcgi.socket",
 
      "bin-path" => "/usr/local/bin/php"
 
      )
 
    )
 
  )

Достоинства lighttpd

lighttpd включает в себя модули, эквивалентные модулям Apache для сжатия, просмотра каталогов, пользовательских каталогов, SSL, WebDAV, перезаписи URL и переадресации. Вы можете прочитать об этом на сайте. Другие интересные модули lighttpd являются уникальными.

Если вы хотите сделать мини-YouTube, мы можете параллельно показывать тысячи флеш-роликов с помощью модуля mod_flv_streaming. YouTube обрабатывает его собственные статические файлы с помощью lighttpd, хотя ещё не использует этот модуль.

Если у вас есть такой сайт с большим количеством флеш-файлов, как вам защититься от хотлинкинга? Решением этой проблемы в lighttpd, подходящим для любых типов файлов, является mod_secdownload. Вы пишете функцию (примеры по ссылке написаны на PHP и Ruby) для генерирования специального URL, а модуль обрабатывает этот URL для предоставления доступа к определенному файлу на определенный период времени.

Лайти Один Пять Ноль.

В данный момент Кнешке разрабатывает версию 1.5.0, которая увеличит производительность и гибкость. Новая подсистема ввода-вывода улучшает производительность с помощью тредов (в данном случае треды имеют смысл) и асинхронный ввод-вывод, будь то POSIX, собственный в Linux или пользовательская оболочка gthread в glib 2.0.

Модуль mod_proxy_core объединяет три бэкенд модуля: mod-proxy, mod-fastcgi и mod-scgi. Отделение протоколов от основной обработки дает балансировку нагрузки (четырех видов!), преодоление отказа, удержание соединения и внутреннее формирование очереди к основной функции прокси.

Ожидается, что новый модуль под названием mod_magnet сыграет большую роль в будущем lighttpd. Он дает доступ к разным фазам HTTP запроса и ответа, включая задачи вроде перезаписи URL и генерации контента. Интересным выбором было использование в нем встроенного скриптового языка Lua вместо сложной грамматики, как в mod_rewrite Apache. Посмотрим, понравится ли это разработчикам, или они будут придерживаться знакомым, хотя иногда и сложным, правилам Apache.

Куда Лайти?

Кнешке видит будущее lighttpd в двух направлениях:

— Высокопроизводительные, широкодоступные поставщики контента

— Встроенные сервера, кросс-компиляция, использовать мало памяти

После 1.5.0, mod_magnet будет предоставлять больше динамической конфигурации сервера. Это может привлечь некоторых пользователей Apache, отказавшихся от перехода на lighttpd из-за отсутствия поддержки .htaccess. Я с нетерпением жду запланированную поддержку Comet — обратная сторона AJAX, в которой сервер обновляет клиента при поступлении новых данных. Это имеет приложения к панелям управления веб-приложений, чатам и другим высокоинтерактивным приложениям. С помощью AJAX и Comet, веб-приложения могут выглядеть гораздо более похожими на приложения с традиционным GUI. Но даже без этих новых возможностей, lighttpd уже является сильным конкурентом для Apache, особенно при ограничениях в памяти или обработке множества статических файлов. Легкость — это хорошо.

Хранение изображений в базе данных MySQL

Для хранения изображений в базе данных MySQL необходимо определить одно из полей таблицы как производное от типа BLOB. Сокращение BLOB означает большой двоичный объект. Тип хранения данных BLOB обладает несколькими вариантами:

  • TINYBLOB — может хранить до 255 байт
  • BLOB — может хранить до 64 килобайт информации
  • MEDIUMBLOB — до 16 мегабайт
  • LONGBLOB — до 4 гигабайт

Соответсвенно, для хранения изображений нам надо создать таблицу images с двумя полями:

  • id — уникальный ID изображения
  • content — поле для хранения изображения

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

<form action="putimage.php" enctype="multipart/form-data" method="post"> Изображение: <input name="image" type="file" />
<input type="submit" value="Загрузить" />
</form>Обработчик формы - файл putimage.php:
// Проверяем пришел ли файл
if( !empty( $_FILES['image']['name'] ) ) {
// Проверяем, что при загрузке не произошло ошибок
if ( $_FILES['image']['error'] == 0 ) {
// Если файл загружен успешно, то проверяем - графический ли он
if( substr($_FILES['image']['type'], 0, 5)=='image' ) {
// Читаем содержимое файла
$image = file_get_contents( $_FILES['image']['tmp_name'] );
// Экранируем специальные символы в содержимом файла
$image = mysql_escape_string( $image );
// Формируем запрос на добавление файла в базу данных
$query="INSERT INTO `images` VALUES(NULL, '".$image."')";
// После чего остается только выполнить данный запрос к базе данных
mysql_query( $query );
}
}
}
?>

Извлечь сохраненный файл изображения можно следующим образом (файл image.php):

if ( isset( $_GET['id'] ) ) {
// Здесь $id номер изображения
$id = (int)$_GET['id'];
if ( $id > 0 ) {
$query = "SELECT `content` FROM `images` WHERE `id`=".$id;
// Выполняем запрос и получаем файл
$res = mysql_query($query);
if ( mysql_num_rows( $res ) == 1 ) {
$image = mysql_fetch_array($res);
// Отсылаем браузеру заголовок, сообщающий о том, что сейчас будет передаваться файл изображения
header("Content-type: image/*");
// И  передаем сам файл
echo $image['content'];
}
}
}
?>

Чтобы вывести изображение в HTML-документе, делаем так:

<img src="image.php?id=17" alt="" />

И последнее: графические файлы иногда имеют довольно большой размер, убедитесь, что настройки сервера позволяют работать с таким объемом данных. В файле php.ini это директивы post_max_size — определяет максимальный объем данных передаваемых методом POST, и upload_max_filesize — определяет максимальный размер загружаемого файла. Так же проверьте, позволяют ли настройки MySQL обрабатывать запросы с большим объемом данных (директива max_allowed_packet файла my.ini).

Проброс TCP соединения через ICMP туннель

Утилита PingTunnel (http://www.cs.uit.no/~daniels/PingTunnel/) позволяет организовать
TCP тунель поверх ICMP ‘echo’ или 53 UDP порта. Подобное может оказаться полезным для обеспечения
работы клиента, для которого пакетным фильтром заблокирован весь трафик, кроме ICMP или 53 UDP порта.
Для работы PingTunnel необходим запуск прокси-процесса на удаленной машине
(не важно, под какой ОС, утилитой поддерживается даже Windows), имеющей выход в сеть.

Ставим ptunnel.
В Debian/Ubuntu:

   apt-get install ptunnel

В RedHat/CentOS/Fedora:

   yum install ptunnel

Во FreeBSD:

   cd /usr/ports/net/ptunnel && make && make install

На внешней машине, имеющей выход в сеть, запускаем icmp-прокси («-x пароль» можно не указывать,

но тогда пустит любого):

   ptunnel -x пароль

На локальной машине, на которой ничего кроме ICMP не работает, поднимаем туннель:

   ptunnel -p хост_прокси -lp локальный_порт_туннеля -da адрес_дальнейшего_проброса \
      -dp порт_дальнейшего_проброса -x пароль

Например:

    ptunnel -p proxy.testhost.ru -lp 2222 -da server.testhost.ru -dp 22 -x пароль

На proxy.testhost.ru у нас должен быть запущен icmp-прокси.
При коннекте на 2222 порт локальной машины мы будем переброшены на 22 порт хоста server.testhost.ru
Например, для входа на server.testhost.ru по SSH нужно набрать:

   ssh -p 2222 localhost

В случае проблем можно попробовать указать имя внешнего сетевого интерфейса через опцию «-c»,

например «-c eth1».
Для создания туннеля через 53 UDP порт на локальной и удаленной стороне нужно запустить ptunnel c опцией «-udp».

Источник

10 трюков в командной строке bash

1. Простой способ перехватить вывод и ошибки

Хотите направить stdout и stderr в один файл?

command &> file

Может вы разбираетесь в некой программе при помощи strace, и желали бы видеть системные вызовы вместе с ошибками программы?

strace badapp &> errors_and_output

Плюсы: легко запоминается, и проще чем «послать ошибки на вывод, а затем всё это в файл».
Совместимость: любой линукс.

2. Распараллеливание циклов

Почти любому администратору знакома мощь циклов — как сделать что-либо для одного, сотни или тысячи пользователей, файлов, машин, процессов, или чего угодно. Большинство строят циклы последовательно, так что каждое задание завершается перед стартом следующего. Но можно посылать каждое задание в фон, и не ждать его завершения:

for HOST in $(< ListOfHosts); do ssh $HOSTsudo apt-get update& done

Может вам нужна куча ssh-туннелей одновременно:

for HOST in $(< ListOfHosts); do ssh -C -N -R 80:localhost:80 $HOST & done

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

Плюсы: сберегает метрическую туеву хучу (2/3 имперской туевой хучи) времени ожидания завершения.
Совместимость: любой линукс.
Минусы: у баша должны быть ограничения на количество одновременных задач, но пока автор (и переводчик) в них не упёрся.

3. Ловля утечек памяти через крон

Утечки памяти в линуксе нечасты, но бывают, особенно с бета-дистрибутивами или самодельным софтом. Часто выявить программу с подтёком не так-то просто. В линуксе есть программа Out-Of-Memory, позволяющая отыскивать и убивать такие процессы, но пока она сработает, система уже может начать сильно тормозить — настолько, что вы теряете терпение и перезагружаетесь.

Обычный способ узнать потреблении памяти программой это запуск top (или его графического эквивалента, наподобие System Monitor), и проверка Размера Резидентной Части (Res или RSS) интересующих процессов (память, отведённая программой, вам не нужна — утечки происходят от использования, а не от отведения, и программа может отвести (allocate) кучу памяти без вреда для системы). Большинство граждан не в курсе, что top можно запускать пакетно, что означает, что можно использовать cron и top для создания простого отчёта об использовании программой памяти:

  • запустите top
  • кнопками < и > добейтесь сортировки процессов по RSS (размер резидентной части)
  • нажмите W для записи конфигурации в файл
  • добавьте крон-задачу:
  • crontab - <<< '*/15 * * * * top -n 1 -b'

    И каждые 15 минут будете получать письмо с выводом топа.

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

    4. stdin прямо из командной стоки

    Не поняли, что это была за фигня (<<<)? Баш позволяет слать процессам стандартный ввод прямо из командной стоки.

    Плюсы: позволяет писать команды с командной стоки, даже для альтернативно дружественных программ, которые требуют ВСЁ со стандартного ввода. [Грозит кулаком MySQL-ю].
    Совместимость: bash 3 и новее.
    Минусы: всё ещё немало систем с bash 2.

    5. Установить первичный пароль, который надо поменять

    Многие организации имеют хорошие и надёжные политики паролей. Пароли хранятся на виндозных машинах. Линукс либо не не покрывается политикой, либо политика не соблюдается — люди не в курсе авторизации под линукс (большинство граждан не понимают PAM, а линуксовые админы часто не осознают, что линукс может чудесно авторизоваться через Active Directory), и было время, что разработчики OpenSSH не любили PAM (это с тех пор поменялось).

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

    umask u=rw,go=
    openssl rand -base64 6 | tee -a PasswordFile | passwd –stdin joe
    chage -d 0 joe

    Пароль сохранён в файл PasswordFile, который доступен для четния только под своим акаунтом. После этого сообщите начальный пароль пользователю по надёжному каналу, вроде телефона или зашифрованного письма (Переводчику приходилось встречать систему, при которой начальный пароль высылался по обычному емэйлу. Пикантность была в том, что это был не фейсбук и не одноклассники. Это был онлайн-банк.)

    Плюсы: пользователи не будут с начальным паролем бесконечно.
    Совместимость: любой линукс с обновлённым OpenSSH (если ваши пользователи заходят в первый раз по SSH). РедХат утверждает, что это всё ещё не работает в RHEL 3/4, но после приложения их обновлений, всё хорошо.
    Минусы: нет.

    6. Простое добавление публичного ключа на удалённый хост

    Для логина но новый хост по ключу надо сначала на этот хост записать публичную часть ключа. Конечно, это можно делать вручную, но вскоре это надоедает (и почему у ssh нет authorized_keys.d…), а ведь для этого есть специальная утилита:

    ssh-copy-id -i .ssh/id_rsa.pub hostname

    Введите пароль последний раз, ssh скажет:

    Now try logging into the machine, with “ssh ‘hostname’”, and check in:

    .ssh/authorized_keys

    to make sure we haven’t added extra keys that you weren’t expecting.

    Попробуйте. До свидания, пароли!

    7. Распаковка RPM без дополнительного софта

    На дебиано-подобных дистрибутивах это не проблема, потому что .deb файлы есть просто .ar архивы. Каждое руководство по РедХату упоминает rpm2cpio (идёт по умолчанию с rpm), но если честно, я не способен запомнить синтаксис cpio, античный формат, сейчас использующийся только, мм, пожалуй, только рпм-ом.

    Эта команда ставит пакет во временную директорию, но не меняет RPM базу (только во временной диркетории, которую вы потом сотрёте). Поскольку в ней нет больше ничего, мы запрещаем зависимости и скрипты.

    mkdir /tmp/deleteme
     
    rpm -ivh –root /tmp/deleteme –nodeps –noscripts package.rpm

    8. Изменился ли файл с момента поставки

    Это простой способ узнать, не менялся ли файл из пакета. Сперва определите пакет, в который входит файл:

    dpkg -S /etc/foo/foo.conf
     
    rpm -qf /etc/foo/foo.conf

    Потом разверните оригинальный пакет при помощи tar (DPKg) или трюка с rpm, данного выше (RPM), и запустите:

    diff /etc/foo/foo.conf /tmp/deleteme/etc/foo/foo.conf

    И найдите разницу.

    Плюсы: быстрое нахождение плохих конфиг-файлов (strace тут тоже может пригодиться)
    Совместимость: любой линукс.
    Минусы: у вас остаётся больше времени на работе, чтобы читать Digg.

    9. — Первым делом отключите связь… Ало? ало? идиоты!

    Ковыряетесь в файрволе удалённо? Нервно как-то, правда? Не то нажал, и связь потеряна.

    Почему бы не откатить ошибку? Зарядите откат того, что вы собираетесь менять.

    at now + 5 minutes <<< 'cp /etc/ssh/sshd_config.old /etc/ssh/sshd_config; service sshd restart'

    Если ошибётесь, процесс выполнится и восстановит установки. А если не ошибётесь, запустите atq, и atrm <номер задачи> для удаления.

    Плюсы: прикрывает задницу на случай ошибки.
    Совместимость: любой линукс, в котором разрешён at, а он обычно да.
    Минусы: помнить, что это надо сделать перед рискованным действием.

    10. Открыт ли порт

    Хотите проверить, запущен ли сетевой сервис? Netcat с опцией -w (сколько ждать) будет полезен:

    nc -w 3 server ssh <<< ' '

    Соединиться на ssh порт на хосте по имени server, ждать 3 секунды перед тем, как послать, мм, ничего, и закрыть соединение. Был ли порт открыт, будет отражено в статусе nc.

    if nc -w 3 localhost 22 <<< ''&> /dev/null
    then
    echo 'Port is open'
    else
    echo 'Port is closed'
    fi

    Источник

    SOCKS proxy в SSH

    Допустим, у нас есть рабочая станция в локальной сети за firewall’ом; также имеется ssh-доступ на сервер в Интернете. Кроме ssh, никакой связи с внешним миром не имеется, а очень хочется, например, подключиться к какому-нибудь jabber-серверу.

    На рабочей станции запускаем простую команду:

    ssh -D 5555 user@remotehost -f -N

    Теперь, указав в настройках XMPP-клиента (например, Pidgin’а) в качестве SOCKS5 прокси localhost:5555, получим желаемый результат: Pidgin соединяется с сервером через внешний сервер.

    Еще один неизвестный мне доселе ssh tip: в комплект поставки ssh входит программка ssh-copy-id, автоматически прописывающая ваш .ssh/.id_rsa.pub в .ssh/authorized_keys на целевом сервере и устанавливающая правильные права. Использовать это проще простого:

    ssh-copy-id user@remotehost