# ssh-keygen -t rsa -N '' -f /etc/ssh/ssh_host_rsa_key
# ssh-keygen -t dsa -N '' -f /etc/ssh/ssh_host_dsa_key
Для версии 1 воспользуйтесь таким вариантом:
# ssh-keygen -t rsa1 -N '' -f /etc/ssh/ssh_host_key
Сервер SSH и клиенты применяют также файл ключей ssh_known_hosts, который содержит открытые ключи от других хостов. Если вы намерены использовать аутентификацию на основе хостов, файл ssh_known_hosts на сервере должен содержать открытые ключи хостов для всех надежных клиентов. Знание о файлах ключей пригодится, когда вы приступите к замене компьютера. При настройке нового компьютера с нуля можно импортировать файлы ключей со старого компьютера, чтобы у пользователей не возникло несоответствие ключей при подключении к новому компьютеру.
Запуск сервера SSH
Хотя в большинстве версий ОС присутствует оболочка SSH, сервер sshd обычно не запускается по умолчанию. В Ubuntu и Debian при установке пакета SSH-сервера создаются ключи, запускается сервер и заносится информация о запуске в конфигурацию загрузки системы. В Fedora сервер sshd установлен по умолчанию, но отключен. Чтобы запустить сервер sshd при загрузке системы, воспользуйтесь командой chkconfig таким образом (при этом сервер не будет запущен сразу же; для его запуска используйте команду service sshd start):
# chkconfig sshd on
В Fedora при первом запуске сервера sshd обычно создаются все отсутствующие файлы хост-ключей.
Если у вас еще не установлена поддержка системы init, то при запуске команды sshd с корневыми правами запускается сервер и во время запуска сервер sshd записывает свой идентификатор PID в файл /var/run/sshd.pid.
Можно также запустить сервер sshd в качестве модуля сокета в версии systemd или с помощью команды inetd, но это, как правило, не очень корректно, поскольку серверу иногда требуется создавать файлы ключей, а на это требуется довольно много времени.
10.3.2. Клиент SSH
Чтобы подключиться к удаленному хосту, запустите команду:
$ ssh remote_username@host
Можно опустить параметр remote_username@, если ваше локальное имя пользователя такое же, как и для хоста. Команду ssh можно также встраивать в «конвейер», как показано в приведенном ниже примере, в котором каталог dir копируется на другой хост:
$ tar zcvf–dir | ssh remote_host tar zxvf -
Файл ssh_config глобальной конфигурации клиента SSH должен располагаться в каталоге /etc/ssh вместе с вашим файлом sshd_config. Как и в файле конфигурации сервера, файл конфигурации клиента содержит пары «ключ — значение», но вам не следует их изменять.
Наиболее часто проблемы при использовании клиентов SSH возникают, если открытый ключ в локальных файлах ssh_known_hosts или .ssh/known_hosts не совпадает с ключом на удаленном хосте. Неправильные ключи могут вызвать ошибку или появление подобного предупреждения:
@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@
@ WARNING: REMOTE HOST IDENTIFICATION HAS CHANGED! @
@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@
IT IS POSSIBLE THAT SOMEONE IS DOING SOMETHING NASTY!
Someone could be eavesdropping on you right now (man-in-the-middle attack)!
It is also possible that the RSA host key has just been changed.
The fingerprint for the RSA key sent by the remote host is
38:c2:f6:0d:0d:49:d4:05:55:68:54:2a:2f:83:06:11.
Please contact your system administrator.
Add correct host key in /home/user/.ssh/known_hosts to get rid of this
message.
Offending key in /home/user/.ssh/known_hosts:12
RSA host key for host has changed and you have requested
strict checking.
Host key verification failed.
Обычно это означает лишь, что администратор удаленного хоста изменил ключи (такое часто происходит при замене аппаратных средств), но никогда не повредит спросить об этом у самого администратора, если вы не уверены. В любом случае предыдущее сообщение говорит вам о том, что неправильный ключ находится в строке 12 пользовательского файла known_hosts (отмечено маркером
При отсутствии каких-либо подозрений просто удалите ошибочную строку или замените ее правильным открытым ключом.
Клиенты передачи файлов в оболочке SSH
Оболочка OpenSSH содержит команды для передачи файлов, scp и sftp, которые призваны заменить старые, незащищенные команды rcp и ftp.
Команду scp можно использовать для передачи файлов между удаленным компьютером и вашим или от одного хоста к другому. Она работает подобно команде cp. Приведем несколько примеров:
$ scp user@host:file .
$ scp file user@host:dir
$ scp user1@host1:file user2@host2:dir
Команда sftp работает подобно клиенту ftp из командной строки, используя команды get и put. На удаленном хосте должна быть установлена команда sftp-server, наличие которой можно ожидать, если удаленный хост также применяет оболочку OpenSSH.
примечание
Если вам необходимо больше функций и гибкости, чем предлагают команды scp и sftp (например, если вы часто передаете большие числа или файлы), обратите внимание на команду rsync, о которой рассказано в главе 12.
Клиенты SSH для платформ, отличных от Unix
Существуют клиенты SSH для всех популярных операционных систем, как указано на веб-странице проекта OpenSSH (http://www.openssh.com/). Какой из них следует выбрать? Подойдет клиент PuTTY — базовый клиент для Windows, который содержит команду защищенного копирования файлов. Клиент MacSSH хорошо работает в Mac OS 9.x и более ранних версиях. Система Mac OS X основана на Unix и уже содержит клиент OpenSSH.
10.4. Демоны inetd и xinetd
Реализация автономных серверов для каждой службы была бы неэффективной. Каждый сервер должен быть отдельно настроен на прослушивание порта, контроль доступа и конфигурирование порта. Эти действия выполняются одинаково для большинства служб, различия возникают только в способе обработки связи, когда сервер принимает соединение.
Один из традиционных способов упрощения использования серверов — демон inetd, своеобразный суперсервер, предназначенный для стандартизации доступа к сетевым портам и интерфейсов между командами сервера и сетевыми портами. После запуска демон inetd читает свой файл конфигурации, а затем прослушивает сетевые порты, указанные в этом файле. При возникновении новых сетевых соединений демон inetd подключает вновь стартовавший процесс к соединению.
Новая версия демона inetd под названием xinetd обеспечивает упрощенную конфигурацию и лучший контроль доступа, однако роль демона xinetd сокращается в пользу применения варианта systemd, который может обеспечить такую же функциональность с помощью модулей сокетов, как описано в подразделе 6.4.7.
Хотя демон inetd уже не используется широко, его конфигурация демонстрирует все необходимое для настройки службы. Оказывается, демон sshd может быть также вызван с помощью демона inetd, а не как автономный север, что видно из файла конфигурации /etc/inetd.conf:
ident stream tcp nowait root /usr/sbin/sshd sshd -i
Семь полей, присутствующих здесь, таковы:
• имя службы — имя службы из файла /etc/services (см. подраздел 9.14.3);
• тип сокета — обычно это stream для протокола TCP и dgram для протокола UDP;
• протокол — транспортный протокол, обычно tcp или udp;
• поведение сервера дейтаграмм — для протокола UDP это wait или nowait. Службы, которые применяют другой транспортный протокол, должны использовать вариант nowait;