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

В принципе эта проверка очень даже полезна, так как значительно снижает вероятность атаки “человек посередине”, но внутри собственной сети от нее часто больше бед, чем пользы. Уже несколько раз наталкивался в своей практике, как страдали бекапы через ssh от проверки fingerprint хоста. Как правило, такое происходит при переустановки ОС, смене доменного имени, или IP. Если машин немного – проблем особых нет, сам все вовремя отловишь. Но когда число серверов переваливает за второй десяток, да еще серверами и бекапами занимаются разные люди – быть беде.
Решение есть – не проверять fingerprint. Конечно же оно связано с определенным риском получить MITM, так что нужно сперва взвесить все плюсы и минусы. Реализация же очень простая:

ssh -o StrictHostKeyChecking=no host.ru

Можно еще запретить добавление fingerprint в known_hosts

ssh -o StrictHostKeyChecking=no -o UserKnownHostsFile=/dev/null host.ru

Источник: http://linuxcommando.blogspot.com

Линки:
Статья про время в linux на opennet
Tz database

P.S
Я написал соответствующий PR в FreeBSD, с запросом как же быть с системами, которые будут поддерживать еще несколько лет (7.3 например), но имеют старые файлы зон для России. Мне вежливо ответили, что понимают мое беспокойство, но ничего сделать не могут. В базовую систему изменения вносятся только в случае проблем с безопасностью. Т.е. ждем, когда кто-нибудь придумает, как использовать старый файл зоны для проникновения в систему? Забавно.

P.S 2
Как мне подсказал Максим Коновалов из Russian FreeBSD Team, можно использовать порт:
misc/zoneinfo

P.S 3
Самый простой и самый некрасивый вариант:
cp /usr/share/zoneinfo/Etc/GMT+4 /etc/localtime

sysctl_start()
{
        parse_file /etc/sysctl.conf $1
        parse_file /etc/sysctl.conf.local $1
}

Разработчики FreeBSD уже подумали о этой проблеме =) Все кастумные настройки добавляем в /etc/sysctl.conf.local

UNIX          |  SED
--------------+----------------------------------------------------------------
 cat          |  sed ':'
 cat -s       |  sed '1s/^$//p;/./,/^$/!d'
 tac          |  sed '1!G;h;$!d'
 grep         |  sed '/patt/!d'
 grep -v      |  sed '/patt/d'
 head         |  sed '10q'
 head -1      |  sed 'q'
 tail         |  sed -e ':a' -e '$q;N;11,$D;ba'
 tail -1      |  sed '$!d'
 tail -f      |  sed -u '/./!d'
 cut -c 10    |  sed 's/\(.\)\{10\}.*/\1/'
 cut -d: -f4  |  sed 's/\(\([^:]*\):\)\{4\}.*/\2/'
 tr A-Z a-z   |  sed 'y/ABCDEFGHIJKLMNOPQRSTUVWXYZ/abcdefghijklmnopqrstuvwxyz/'
 tr a-z A-Z   |  sed 'y/abcdefghijklmnopqrstuvwxyz/ABCDEFGHIJKLMNOPQRSTUVWXYZ/'
 tr -s ' '    |  sed 's/ \+/ /g'
 tr -d '\012' |  sed 'H;$!d;g;s/\n//g'
 wc -l        |  sed -n '$='
 uniq         |  sed 'N;/^\(.*\)\n\1$/!P;D'
 rev          |  sed '/\n/!G;s/\(.\)\(.*\n\)/&\2\1/;//D;s/.//'
 basename     |  sed 's,.*/,,'
 dirname      |  sed 's,[^/]*$,,'
 xargs        |  sed -e ':a' -e '$!N;s/\n/ /;ta'
 paste -sd:   |  sed -e ':a' -e '$!N;s/\n/:/;ta'
 cat -n       |  sed '=' | sed '$!N;s/\n/ /'
 grep -n      |  sed -n '/patt/{=;p;}' | sed '$!N;s/\n/:/'
 cp orig new  |  sed 'w new' orig
 hostname -s  |  hostname | sed 's/\..*//'

netstat -ntp --tcp | fgrep ESTABLISHED | awk '{ if ($7 == "-") arrQueue[$4]=arrQueue[$4]+1; } END { for (service in arrQueue) print service" "arrQueue[service]}'

Так же awk может показать сколько памяти (в КБ) расходует сетевая подсистема. Делается это опять же при помощи netstat

netstat -na | awk 'BEGIN { RecvQ=0; SendQ=0; } { RecvQ+=$2; SendQ+=$3; } END { print "RecvQ " RecvQ/1024; print "SendQ " SendQ/1024; }'

2) Такие процессы, как mysql используют потоки, которые top не выводит отдельными строчками, а показывает сколько потоков у данного процесса в поле THR. Можно заставить показывать каждый поток отдельно, для этого нужно запустить top с ключом -H или нажать H в процессе работы.

3) Jail – замечательный механизм изоляции различных окружений на одной машине.
top позволяет определить какому из jail принадлежит процесс при помощи jail id. 0 – это host система, остальные номера смотрим через jls. Или при запуске нужно запустить top с ключом -j, или при работе нажать j.

4) Поиск утилизирующего диск приложения – top помогает и с этой задачей.
Опция -m с параметром io (или m в процессе работы) переводит top в режим отображения IO активности, вместо CPU. Очень полезно.

5) Опция -S показывает системные процессы, полезная опция на загруженных системах.
Например, можно подсмотреть сколько процессора потребляет работа сетевой карты, выглядит это примерно так:

39 root          1 -68    -     0K    16K WAIT    6 117.6H  8.69% irq256: em0

6) Все мы уже привыкли, что процессоров у нас много, ядер в них тоже много и SMP включен, но top упорно показывает всего одну строчку про процессор:

 CPU:  0.4% user,  1.6% nice,  1.4% system,  1.4% interrupt, 95.3% idle

Можно заставить top показывать статистику по каждому ядру/процессору, для этого нужно указать опцию -P.
Возможность была бы совершенно бесполезная, если бы не cpuset! (читайте man cpuset).

7) Частота обновления top задается опцией -s в качестве параметра нужно указать время в секундах. В время работы меняется нажатием s.

Вот и все про top!

trap [action] signal ...

Т.е. команде нужно передать как минимум два параметра, действие при получении сигнала и сигнал, для которого будет выполняться указанное действие. Сигналов можно указать несколько подряд. В качестве пример напишем скрипт, которые при получении SIGHUP будет продолжать работать. Т.е. при закрытии консоли, в которое выполняется наш скрипт, он спокойно продолжит выполнение, а не завершится. При получении SIGINT скрипт удалит временные файлы и завершит работу, SIGINIT вызывается при нажатии Ctrl+C.

#!/bin/sh

TEMPFILE=`mktemp /tmp/XXXXXXX`

signalhandler() {
  local signal=$1

  case $signal in
    SIGHUP)
      echo "Do nothing"
    ;;
    SIGINT)
      rm -f $TEMPFILE
      exit
    ;;
  esac
}

trap "signalhandler SIGINT "  SIGINT
trap "signalhandler SIGHUP "  SIGHUP

# do something good

rm -f $TEMPFILE
exit 0

Для обработки сигналов используется наша функция signalhandler, которая в качестве параметра принимает имя сигнала, и в зависимости от него выполняет разные действия. Чтобы передать разные имена сигналов приходится вызывать trap несколько раз.
Как видите, все просто.

echo $PATH | sed s'/\/etc/\/usr\/local\/etc/g'

Читать это невозможно, да и ошибиться с экранирование легче легкого!
На самом деле sed воспринимает и другие символы в качестве разделителей, а использование ‘/’ является “исторической традицией’. Данную конструкцию легко заменить на такую:

echo $PATH | sed s':/etc:/usr/local/etc:g'

Или такую:

echo $PATH | sed s'|/etc|/usr/local/etc|g'

Согласитесь, так намного лучше!

2) Выполнение нескольких команд sed подряд
Иногда нужно выполнить несколько команд подряд, самый простой способ – сделать несколько pipe, но выглядит это так себе.

echo "New string" | sed 's/New/Old/' | sed 's/string/letter/'

Вместо этого можно задать последовательность при помощи опции -e:

echo "New string" | sed -e 's/New/Old/' -e 's/string/letter/'

Или можно задать последовательность команд через ‘;’:

echo "New string" | sed 's/New/Old/; s/string/letter/'

3) Экранирование команд sed в разных оболочках
Очень важная тема, особенно в контексте написания скриптов. Например если /bin/csh ввести такую команду:

cat /etc/resolv.conf | sed /search/ a\
nameserver 127.0.0.1 \
'
sed: 1: "/search/ a
1 ...": command a expects \ followed by text

Получаем неприятную ошибку вместо ожидаемого результата. Решение – добавить еще один ‘\’ после ‘a\’:

cat /etc/resolv.conf | sed /search/ a\ \
nameserver 127.0.0.1 \
'

В общем случае для sed в C shell экранировать нужно так:

#!/bin/csh -f
sed 's/a/A/g \
s/e/E/g \
s/i/I/g \
s/o/O/g \
s/u/U/g' <old>new

Для Bash все проще:

#!/bin/sh
sed '
s/a/A/g
s/e/E/g
s/i/I/g
s/o/O/g
s/u/U/g' <old >new

4) Основные команды sed

Собственно они есть в любом нормальном описании по sed, здесь я их привожу, как шпаргалку и за одно несколько примеров.
Поиск номера строки по определенному шаблону, опция -n запрещает вывод всех остальных строк:

cat /path/to/file | sed -n '/some/='

Поиск строки по шаблону:

cat /path/to/file | sed -n '/some/p'

Удалим все строки со словом some из файла /path/to/file:

sed -I '' -e '/some/d' /path/to/file

Удалим строки с первой по третью:

sed -I '' -e '1,3d' /path/to/file

Удалим последнюю строку

sed -I '' -e '$d' /path/to/file

Опция -I нужна для редактирования указанного файла, а параметр ” говорит, что не нужно создавать резервную копию.
Добавление и изменение строк работает аналогично.

5) Хорошая документация по sed
В принципе для какого-то просто скриптинга всех этих приемов более чем хватает, но всегда может получить больше, например на сайте.

#!/bin/sh

TEMPROOT=/var/tmp/temproot
ARCH=`uname -p`

if [ -d ${TEMPROOT} ]; then
     chflags -R noschg ${TEMPROOT}
     rm -rf ${TEMPROOT}
fi
mkdir ${TEMPROOT}

od=${MAKE_TEMPROOT}/usr/obj
make_opts="TARGET_ARCH=${ARCH} -m /usr/src/share/mk"

make $make_opts DESTDIR=${TEMPROOT} distrib-dirs
MAKEOBJDIRPREFIX=$od make $make_opts _obj SUBDIR_OVERRIDE=etc
MAKEOBJDIRPREFIX=$od make $make_opts everything SUBDIR_OVERRIDE=etc
MAKEOBJDIRPREFIX=$od make $make_opts DESTDIR=${TEMPROOT} distribution

rm -f ${TEMPROOT}/etc/*.db ${TEMPROOT}/etc/passwd
find ${TEMPROOT}/usr/obj -type f -delete
find ${TEMPROOT} -type f -size 0 -delete

Теперь нужно сравнить /var/tmp/temproot с корнем, делаем это вот таким скриптом

#!/bin/sh
cd /var/tmp/temproot/

for file in `find . -type f`; do
  root_file="/jail/dnl/"${file#./}
  if [ `md5 -q $file` != `md5 -q $root_file` ]; then
    echo file $root_file changed
  fi
done

Получаем список файлов, которые изменились по сравнению с системой из коробки.

mergemaster – это обычный shell скрипт! Очень длинный, слегка запутанные и требующий неплохого знания программирования на sh (man sh, man test, man mtree вам в помощь!), но все же всего лишь скрипт.
Если очень упрощенно рассказывать, как он работает, то получится примерно такая схема:

• Из свежих /usr/src собирается новый корень в отдельном каталоге. По умолчанию это /var/tmp/temproot
• Запускается цикл сравнения всех файлов из нового корня с аналогичными по названию файлами в текущем корне
• По результатам сравнения принимается решение, что делать с этим файлом

Результатов сравнения может быть не так много:
1) Файл есть в новом корне, но нет в текущем
2) Файлы не отличаются
3) Файлы имеют разный тип (например в текущем корне это линк, а в новом обычный файл
4) Файлы отличаются
Но вот число файлов при проверке исчисляется сотнями.
Если запускать mergemaster с минимальным набором опций и без подготовки, то вся тяжесть выбора ложится на системного администратора. Но выход есть, и есть он в самом mergemaster!
Скрипт имеет несколько механизмов автоматического выбора действия при сравнении.

Механизмы автоматического выбора

• 1) mtree база данных

Допустим у нас есть конфигурационный файл, который никак не менялся пользователем. Значит его можно спокойно обновить до новой версии, так как никаких правок, специфичных для данного сервера в него не вносилось. Логика простая, но как узнать, что файл не изменился с момента установки системы?
Ответом может стать утилита mtree. При ее помощи можно создать текущий снимок дерева каталогов (права и размер файлов их чексуммы и т.п.). Такую базу данных можно использовать для сравнения с состоянием того же дерева каталогов, но в другой момент времени. mtree покажет, какие файлы изменились.
mergemaster активно использует mtree, и в конце своей работы создает снимок системы. При следующем запуске mergmaster, он вам задаст куда меньше вопросов, чем прошлый раз именно потому, что теперь у него есть база mtree.
Проблема в том, что при установки сервера никто такую базу специально не делает и потому первое обновление будет очень долгим.
Но можно создать такую базу самому, делается это так:

mtree -ci -p / -k size,time, md5digest -X /usr/src/exclude.list > /var/db/mergemaster.mtree

/usr/src/exclude.list – это текстовый файл с элементами, которые не стоит включать в базу mtree. Это значительно уменьшает время ее создания и время проверки.

cat /usr/src/exclude.list
./usr/src/*
./usr/obj/*
./usr/.snap/*
./jail/*
./usr/ports/*

/var/db/mergemaster.mtree – это путь, где mergemaster будет искать базу данных mtree.
Как mergemaster использует mtree? При запуске скрипт проверяет, есть ли файл mtree. Если он его находит, то сравнивает корень с ним. Получается список измененных файлов.
При сравнении всех файлов из нового корня с текущем, если файл изменился, то проверяется, есть ли этот файл в списке измененных файлов, полученный из mtree. Если в списке его нет, то mergemaster просто заменит файл (нужно указать ключ -U), если файл есть в списке, то будет выведен diff двух файлов и решение об обновлении придется принимать вам.
Но что же делать, если при первой настройке сервера mtree базу данных никто не делал? Ведь если создать ее сразу перед выполнением mergemaster все файлы будут считаться неизмененными? Т.е. с ключом -U mergemaster обновить нам все файлы, даже те, которые мы совсем не хотим обновлять (/etc/group /etc/master.passwd и еще массу полезных файлов)? В общем-то да, так и будет, из обновления систему получится катастрофа, но выход есть в разделе 3) mergemaster.rc и IGNORE_FILES

• 2) Теги в файлах конфигов

Если выбрать какой-нибудь системный конфиг FreeBSD, то вы сразу заметете в его шапке что-то похожее на:
# $FreeBSD: src/etc/group,v 1.35.8.1 2009/04/15 03:14:26 kensmith Exp $
Это тег файла, при его помощи определяют версию конфига. Но фишка в том, что в файле от релиза к релизу может измениться только сам тег, а конфиг ничем не будет отличаться. Т.е. вполне логично, что если в файле изменился только тег, то стоит его просто заменить. Именно так и работает mergemaster c ключом -F. Всегда ставьте ключ -F при запуске mergemaster!

• 3) mergemaster.rc и IGNORE_FILES

Было бы здорово заставить mergemaster не проверять какие-то файлы вообще. Например /etc/group или /etc/master.passwd. Видимо такая мысль пришла в голову автора mergemaster и он реализовал ее через переменную IGNORE_FILES. Для хранения таких переменных используется файл /etc/mergemaster.rc. В IGNORE_FILES нужно добавить не такой большой список файлов, но жизнь это упростит значительно:
IGNORE_FILES=’/etc/master.passwd /etc/group /etc/mail/aliases /etc/sysctl.conf /etc/syslog.conf /etc/newsyslog.conf /etc/crontab /etc/login.conf /etc/ssh/sshd_config /root/.cshrc /.cshrc’
Теперь можно смело создавать базу mtree перед запуском mergemaster, все нужные файлы мы “защитили”.
Тут правда есть одна проблема проблема! Мы можем разойтись с новой версией в опциях, которые вообще-то было бы лучше установить. Т.е. нам нужно смерджить эти файлы с новыми конфигами или хотя бы узнать, что в них изменилось. Как подсмотреть, что же изменилось я расскажу в 6) Подсматриваем в /usr/src

• 4) А если нет такого файла?

Может так случиться, что появится какой-то новый конфигурационный файл, которого в прошлой версии не было. Логично его просто скопировать, а не спрашивать, что же с ним делать у администратора. Именно так и сделает megremaster, если указать ключ -i.

• 5) На всякий случай все сохраняем

Вообще сохранить конфиги перед тем, как что-то делать с ними – хорошая идея. И эта идея реализована в mergemaster. Если задать ключ -P, то будет создан каталог /var/tmp/mergemaster. В нем можно будет найти копию измененных файлов.

• 6) Подсматриваем в /usr/src

Нам нужно сравнить текущие файлы, которые мы решили не обновлять и эти же файлы в новой версии. Ничего нет проще! В каталоге /usr/src/etc лежат все конфиги. Например, мы хотим узнать не появилось ли каких-то новых системных пользователей:

diff -u /etc/master.passwd /usr/src/etc/master.passwd

Собираем все вместе:
1 ) Создаем /etc/mergemaster.rc со списком IGNORE_FILES
2 ) Создаем базу mtree
3 ) делаем csup
4 ) собираем ядро и мир
5 ) устанавливаем ядро
6 ) запускаем mergemaster -piUP
7 ) устанавливаем мир
8 ) mergemaster -iUFP
9 ) Удаляем старые файлы и либы