Настройка SSH

Программное окружение в операционной системе Linux состоит из файлов и утилит для работы с ними, которые можно запускать и редактировать из командной строки терминала. Таким образом, если организовать терминальный доступ к машине с Linux'ом, появляется возможность ею управлять. Безусловно, при этом настройка системы всё ещё доступна через alterator, который по своей сути является лишь графической оболочкой, изменяющей те же самые конфигурационные файлы, но чаще работают с ними напрямую.

Первым делом на машине нужно настроить удалённый доступ. Есть проблема, что когда вы неизвестно откуда должны подключиться к своему компьютеру, вы должны рассказать логин и пароль. Когда вы это делаете, было бы нехорошо, если какой-то злоумышленник пароль подглядел и потом им воспользовался. Поэтому та служба, которая организует доступ к любому ресурсу, требующему логин и пароль, должна быть защищённой. Ввиду недостатка времени лектор не будет рассказывать, почему доступ по ssh защищённый, надо только помнить две вещи: та машина, с которой вы осуществляете доступ, может быть взломана (пароль будет подсмотрен кейлоггером), второе - есть некая дисциплина начального подключения клиента и сервера, связанная с обменм уникальными идентификационными данными клиента и сервера, то, что называется host key. Дисциплина состоит в следующем: когда вы впервые подключаетесь с неизвестного места по защищённому ssl протоколу, происходит обмен идентификационной информацией. В этот момент возможна атака следующего рода - кто-то перехватит идентификационную инфрмацию, вместо неё подсунет свою, вы, воспользовавшись ей, произведёте шифрование данных, этот кто-то перехватит обратный поток зашифрованных данных, которые зашифрованы с помощью его идентификационной информации, расшифрует, посомтрит, перешифрует и отправит дальше. Эта технология называется monkey in the middle, подробнее по неё лектор расскажет, когда будет рассказывать про ssl. Посему первоначальный обмен идентификационной информацией должен быть очень строго проверен. Самый простой способ - запомнить fingerprint'ы тех машин, на которые вы ходите и сравнивать каждый раз при подключении. Считается, что подделать fingerprint невозможно. По умолчанию в линукс-мастере пакет openssh (это метапакет, который содержит и сервер, и клиент и ещё кое-что) надо поставить.

# apt-get install openssh

Конкретно для сервера надо поставить openssh-server. Этот самый сервер потянет за собой всё, что нужно. Он называется opensshd. Чтобы его запустить, нужно сказать

# service sshd start 

При первом запуске он сгенерирует ключи машины (в последствии это можно сделатьс ssh-keygen). Эти ключи было бы неплохо сохранять при переустановке системы (если они не утекли). Иначе происходит следующая ситуация: если вы переставили систему на машине, а потом подключаетесь к ней по ssh, происходит не просто новое подключение к неизвестной машине, а гораздо хуже - подключение к известной машине, у кторой изменился идентификационный ключ. И SSH скажет "вы чего делаете?! У этой машины ключ изменился! Скорее всего, вас уже взломали!" Более того, теперь нас даже не спрашивают, всё равно идти туда или нет, а отказывается работать, пока не исправят ситуацию. Теперь эта служба запущена, у нас есть терминальный сервер, и к нему можно подключиться.

Проверим, как оно работает, заодно увидим fingerprint. Вернёмся в консоль и попробуем добыть fingerprint из ключа. Нужно сказать

ssh-keygen -l -f /etc/openssh/ssh_host_dsa_key.pub

(Здесь есть вариант, host_rsa_key или host_dsa_key).

Теперь зайдём в lite и проверим, как оно работает.

[user@localhost ~]$ ssh user@172.16.0.1
The authenticity of host '172.16.0.1 (172.16.0.1)' can't be established.
RSA key fingerprint is 86:f8:82:2e:bc:9c:0f:1b:35:c6:a7:a1:11:75:5b:2b.
Are you sure you want to continue connecting (yes/no)? yes
Warning: Permanently added '172.16.0.1' (RSA) to the list of known hosts.
user@172.16.0.1's password: 
Last login: Wed Jul  9 19:12:24 2008
[user@demo ~]$ 

В процессе лекции возникла необходимость записать протокол в файл. Обычно используется script, который записывает в файл всё, что происходит в терминале. В данном случае мы только-только запустили клиент, и такой программы не запустили. Как выйти из положения? Проблема такая, что есть одна машина, на которой мы всё это делаем, и другая машина, на которой мы храним журналы. Поскольку речь идёт о терминальном доступе, мы зашли на ту машину, где накапливаются журналы, посему с использованием команды cat и выделения мышкой мы сохранили этот лог в файл на удалённой машине. "Вот тебе и первая выгода от твоего длинного носа". Ровно ту задачу, которую нам нужно было решить, мы тут же и решили. Идея иллюстрации состоит в том, что в процессе неё мы решаем задачу создания этой иллюстрации.

feedback

Отдельный небольшой кусок, связанный с темой обратная связь.

Речь идёт о чём. Если вы нашли ошибку, желательно её задокументировать и сделать так, чтобы о ней стало известно разработчику. Здесь есть разные варианты. Например написать письмо. Но для ошибок, которые вы исправили (в особенности), есть специальный интерфейс, который много всякой социальной работы автоматизирует. Конкретно, было бы неплохо, чтобы сообщение об ошибке получили все заинтересованные, чтобы можно проследить процесс её обработки и вообще чтобы всё это где-то лежало. Конкретно, рассмотрим процесс добавления бага в багзиллу.

../bugzilla_logining.png

Для начала логинимся в багзиллу на https://bugzilla.altlinux.org/. Если логина нет, то регистрируемся.

../bugzilla_after_login.png

Дальше идём в добавить баг, выбираем distributions...

../bugzilla_section_select.png

...а затем altlinux branch.

../bugzilla_distro_select.png

Выбираем компонент

../bugzilla_bugreport_component_select.png

Пишем в суть: "ulogd: неправильное определение статуса"

../bugzilla_bugreport_compose.png

Подрбности: всё, что может прояснить проблему.

При проверке статуса и останове демона ulogd неправильно задаётся пользователь (root вместо ulogd), от лица которого он запущен. В результате программа start-stop-daemon не может определить его PID и возвращает ошибку.

[root@demo ~]# service ulogd status
ulogd is dead, but stale PID file exists
[root@demo ~]# grep root /etc/init.d/ulogd
        stop_daemon --pidfile "$PIDFILE" --expect-user root -HUP -- $ULOGD
                status --pidfile "$PIDFILE" --expect-user root -- $ULOGD
[root@demo ~]# start-stop-daemon --stop --test --exec /usr/sbin/ulogd --user-fallback-to-name --pidfile /var/run/ulogd.pid --user root
No /usr/sbin/ulogd found running; none killed.
[root@demo ~]# ps -ef | grep ulogd
ulogd     2253     1  0 19:11 ?        00:00:00 /usr/sbin/ulogd -d
[root@demo ~]# start-stop-daemon --stop --test --exec /usr/sbin/ulogd --user-fallback-to-name --pidfile /var/run/ulogd.pid --user ulogd
Would send signal 15 to 2253.

Жмём "сохранить".

../bugzilla_bugreport_sent.png


Сведения о ресурсах

Готовность (%)

Продолжительность (ак. ч.)

Подготовка (календ. ч.)

Полный текст (раб. д.)

Предварительные знания

Level

Maintainer

Start date

End date

20

1

1

1

1

ConstantinYershow, BorisTsema


CategoryLectures CategoryPspo CategoryMpgu CategoryUneex