Настройка SSH

Может изменить название? Тут только введение в SSH -- про настройку ни слова. А так же под каким соусом подавать раздел feedback?BorisTsema

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

Первым делом на машине нужно настроить удалённый доступ. При этом возникает проблема с безопасностью: при подключении к удалённому компьютеру вы должны передать логин и пароль, который может быть перехвачен злоумышленником. Поэтому служба, организующая доступ к любому ресурсу, требующему идентификационные данные, должна отвечать повышенным требованиям к безопасности. Служба Secure Shell (ssh) является таковой с большой степенью надёжности. Кратко расскажем почему.

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

Чтобы использовать ssh в линукс-матере надо установить метапакет openssh. Он содержит и сервер и клиент.

# apt-get install openssh

Непосредственно для сервера надо запустить службу opensshd, для чего требуется установить openssh-server.

# service sshd start 

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

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

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

В зависимости от применяемого способа шифрования будет показан host_rsa_key host_dsa_key.

Для подключения на удалённой машине надо ввести команду ssh пользователь@удалённая машина

[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

29

1

1

1

1

ConstantinYershow, BorisTsema


CategoryLectures CategoryPspo CategoryMpgu CategoryUneex