Ключевые слова:ssh, security, crypt, pgp, (найти похожие документы)
From: Андрей Лаврентьев <lavr@unix1.jinr.ru>
Original: http://unix1.jinr.ru/~lavr/Subject: SSH - Работа с публичными ключами
Автор: Андрей Лаврентьев (lavr@unix1.jinr.ru), http://unix1.jinr.ru/~lavr/
o О шифровании методом публичных ключей
o Создание вашего ключа аутентикации и изменение парольной фразы
o Авторизация доступа, директории и права
o Вход на удаленную систему
o Хранение ключей авторизации в памяти
- запуск системы X11 на локальном дисплее
- запуск системы X11 через сессию xdm
o Управление ключами авторизации в памяти
o Запуск команд на удаленной системе
o Копирование файлов между системами
o Изменение стандартных настроек
o Ссылки на другие полезные источники информации
О шифровании методом публичных ключей
Шифрование методом публичного ключа использует public key для шифрации и
private key для дешифрации данных. Сам термин public key укзывает на тот
факт, что использовать этот метод можно без страха за безопасность пере-
даваемых данных или ключ дешифрации, ибо последний просто не передается
по данной технологии.
Это означает, что нет опасности передачи вашего public key или содержимого
файла $home/.ssh/identity.pub по электронной почте или другими методами
системному администратору удаленного сервера чтобы ое помечтил эти данные
в файл $home/.ssh/authorized_keys на удаленном сервере.
Если кто-либо хочет получить несанкционированный доступ к вашим данным или
воспользоваться вашим входом при авторизации, то ему необходимо сначала
получить доступ к вашему личному ключу $home/.ssh/identity и соответственно
дешифровать его для идентификации сперва самого себя.
Однако для большей защиты вашего private key, при его генерации с помощью
программы keygen необходимо задать passphrase - парольную-фразу для шифрации
содержимого файла, когда он будет записываться на файловую систему. Это
должно предотвратить от дешифрации личного ключа даже если кто-либо имеет
доступ в вашу домашнюю директорию и файлам.
Создание вашего ключа аутентикации и изменение парольной фразы
Итак, первое что вам необходимо сделать - это использовать команду
"ssh-keygen" для создания собственных ключей авторизации. Достаточно
просто запустить эту команду, ключи использованные в этой команде по-умолча-
нию обычно удовлетворяют все потребности.
Совет, перед запуском "ssh-keygen" сначала придумайте и запомните фразу-
пароль, которая должна удовлетворять следующим рекомендациям:
- содержать последовательность отдельных слов
- удобнее и лучше, если слова будут разделяться пробелами; это не только
допускается, но и приветствуется в целях увеличения секретности
- изменить некоторые слова на предмет неверного произношения(соответственно
и их написание должно быть изменено)
- заменить некоторые буквы в словах на цифры или добавить набор цифр в вашу
"секретную" пароль-фразу
Чем большему количеству перечисленных выше рекомендаций будет соответствовать
ваша пароль-фраза, тем надежнее будет она сама и ваш личный ключ - private key
далее приведен пример создания личного, публичного ключа и их криптование:
/* не забудьте что вводимая passphrase не высвечивается */
unix1% ssh-keygen
Initializing random number generator...
Generating p: .............................................++ (distance 830)
Generating q: .......................................++ (distance 636)
Computing the keys...
Testing the keys...
Key generation complete.
Enter file in which to save the key ($HOME/.ssh/identity):
Enter passphrase: pust' vsegda 2000
Enter the same passphrase again: pust' vsegda 2000
Your identification has been saved in /home/lavr/.ssh/identity.
Your public key is:
1024 37 [lots of numbers] lavr@unix1
Your public key has been saved in /home/lavr/.ssh/identity.pub
unix1%
Если вы имеете несколько accounts (входов в разные системы), то можете создать
несколько отдельных и разных ключей для каждого из них, например:
- для оффиса
- для личной системы
- для Internet service provider (ISP) системы
- для унивеситета
- для научно-исследовательского центра или интститута
Это разграничение позволяет существенно ограничить доступ между этими
организаациями, например использование доступа из одной в другую и отслежи-
вать несанкционированный доступ по регистрационной информации
Помните что при необходимости, вы всегда можете изменить свою пароль-фразу
выполнив команду "ssh-keygen" с опцией -p , например:
/* не забудьте что вводимая passphrase не высвечивается */
unix1% ssh-keygen -p
Enter file in which the key is ($HOME/.ssh/identity):
Enter old passphrase: pust' vsegda 2000
Key has comment 'lavr@sunhe'
Enter new passphrase: budet new 3000
Enter the same passphrase again: budet new 3000
Your identification has been saved with the new passphrase.
unix1%
Авторизация доступа, директории и права
Для того чтобы расширить или ограничить список систем с которых разрешен
разрешен доступ необходимо создать файл $home/.ssh/authorized_keys в который
поместить список public key тех систем которым разрешен доступ.
Обычно пользователи хотят иметь авторизованный доступ на _локальную_ систему
использую локальный ключ(этод метод хорош там где используется метод разделяе
мых домашних директорий с использованием NFS)
В данном случае достаточно просто скопировать файл с public key в файл
$home/.ssh/authorized_keys.
unix1% cd ~/.ssh
unix1% cp identity.pub authorized_keys
Теперь вы можете скопировать файл authorized_keys на другие удаленные системы
чтобы позволить доступ к ним с локальной системы. Передать это файл вы можете
по ftp или через rcp/scp.
При появлении доступа к новым или закрытия к старым системам вы можете изме
нять соответственно ваш файл authorized_keys используя текстовый редактор.
Помните, что каждый ключ - это одна строка файла, а также то что добавляемые
вами ключи всегда "public key" из файлов с расширением ".pub".
Всегда следите за правами доступа к любым вашим файлам, но особенно к тем, с
которыми связана безопасность вашей работы и сохранность данных.
Если после всех проделанных мероприятий, удаленная система отказывает вам
в доступе, попробуйте проверить права и доступ к :
∙ the home directory itself
∙ the ~/.ssh directory
∙ the ~/.ssh/authorized_keys file
Права на запись должны быть только у вас - владельца. Следующий пример
показывает какими они должны быть:
unix1% cd
unix1% ls -ld . .ssh .ssh/authorized_keys
drwxr-xr-x 36 lavr dug 4096 Jul 25 02:24 .
drwxr-xr-x 2 lavr dug 512 Apr 10 02:30 .ssh
-rw-r--r-- 1 lavr dug 1674 Apr 10 02:29 .ssh/authorized_keys
unix1%
Чтобы удаленная система позволила удаленный доступ вы можете запретить права
на запись все за исключением владельца:
unix1% cd
unix1% chmod go-w . .ssh .ssh/authorized_keys
unix1%
Запомните, проделав эту процедуру на всех система вы получите полный доступ
ко всем вашим accounts.
Вход на удаленную систему
Для интерактивного входа на удаленную систему можно использовать либо
slogin, либо ssh команду, что собственно одно и то же. Достаточно указать
только один входной параметр - имя удаленной системы. Не забывайте, что
пароль или пароль-фраза при вводе с клавиатуры не будет отображаться на
экране.
unix1% slogin spp
Enter passphrase for RSA key 'lavr@spp.jinr.dubna.su': pust' vsegda 2000
Last login: Wed Oct 16 20:37:00 1996 from idefix
[more output from the remote machine]
spp%
Вы можете избежать приглашения для ввода passphrase сохранив до этого ключи
аутентикации в памяти. Но все равно вы будете вынуждены ввести passphrase,
но лишь однажды, когда будете добавлять их в память.
(см. использование ssh-add)
Если ваше регистрационное имя на обоих системах, локальной и удаленной,
различаются, вы можете использовать опцию "-l username" для указания имени
на удаленной системе. Как например:
unix1% slogin -l lavr nusun
Last login: Sun Oct 13 14:55:17 1997 from nusun.jinr.ru
[more output from the remote machine]
nusun%
Или изменить настройки в файле конфигурации для удаленной системы.
Если у вас возникли какие-либо проблемы при входе на удаленную систему
используйте опцию -v для просмотра отладочной информации и все ваши проблемы
исчезнут после того как вы установите в чем ошибка.
Например:
unix1% slogin -v cv
SSH Version 1.2.22 [i386-unknown-freebsd2.2.5], protocol version 1.5.
Standard version. Does not use RSAREF.
unix1.jinr.dubna.su: Reading configuration data /usr/local/etc/ssh_config
unix1.jinr.dubna.su: ssh_connect: getuid 310 geteuid 0 anon 0
unix1.jinr.dubna.su: Connecting to cv [159.93.17.13] port 22.
unix1.jinr.dubna.su: Allocated local port 777.
unix1.jinr.dubna.su: Connection established.
unix1.jinr.dubna.su: Remote protocol version 1.5, remote software version 1.2.22
unix1.jinr.dubna.su: Waiting for server public key.
unix1.jinr.dubna.su: Received server public key (768 bits) and host key (1024 bits).
unix1.jinr.dubna.su: Host 'cv' is known and matches the host key.
unix1.jinr.dubna.su: Initializing random; seed file /home/lavr/.ssh/random_seed
unix1.jinr.dubna.su: Encryption type: idea
unix1.jinr.dubna.su: Sent encrypted session key.
unix1.jinr.dubna.su: Received encrypted confirmation.
unix1.jinr.dubna.su: Trying rhosts or /etc/hosts.equiv with RSA host authentication.
unix1.jinr.dubna.su: Remote: Accepted by .shosts.
unix1.jinr.dubna.su: Received RSA challenge for host key from server.
unix1.jinr.dubna.su: Sending response to host key RSA challenge.
unix1.jinr.dubna.su: Remote: Rhosts with RSA host authentication accepted.
unix1.jinr.dubna.su: Rhosts or /etc/hosts.equiv with RSA host authentication accepted by server.
unix1.jinr.dubna.su: Requesting pty.
unix1.jinr.dubna.su: Failed to get local xauth data.
unix1.jinr.dubna.su: Requesting X11 forwarding with authentication spoofing.
unix1.jinr.dubna.su: Requesting authentication agent forwarding.
unix1.jinr.dubna.su: Requesting shell.
unix1.jinr.dubna.su: Entering interactive session.
Last login: Tue Jun 30 08:21:28 1998 from cv.jinr.dubna.su
Welcome to ConvexOS
CONVEX computer Corporation
/cern (CERN Soft) dirs tree
and
/local dirs tree
mounted from BCV due to h/w problem.
Samba services disabled temporary(?).
Sorry.
No mail.
Message 107:
From: popovla
Date: Fri Jun 19 11:41:38 1998
Subject: LCTA 2-d floor servers
(8 lines) Display this message? (y)es, (n)o, (q)uit, (h)elp [y]: n
--Flushed--
cv:/home/b17c/lavr>
Хранение ключей авторизации в памяти
Если вам приходится часто открывать соединения с удаленной системой, то
вероятно будет удобней запускать ваш сеанс через "ssh-agent". Агент будет
обеспечивать дешифрацию ключей аутентикации для всех команд при создании
новых соединений.
Для запуска ssh-agent в качестве параметра необходимо указать имя команды
которая будет им запущена, обычно это либо ваш "shell" либо команда запуска
оконной среды. Соответствено по выходу из такой команды все ключи будут
удалены из памяти.
unix1% ssh-agent $SHELL
unix1%
Теперь нам только осталось добавить ключи в память чтобы они были доступны
для других команд.
Рассмотрим запуск оконной среды X11 на локальный дисплей
Если у вас имеется локальная машина с установленной и настроенной средой
X window system, вы можете получить полноценную оконную среду но с ключами
в памяти при запуске через ssh-agent. Обычно X window system запускается
отработкой скрипта startx с инициализацией клиентов из домашнего - .xinitrc
или при его отсутствии системного файла xinitrc.
Например это можно выполнить так:
unix1% ssh-agent startx &
Если ваша рабочая станция имеет виртуальные косоли, как в этом примере, то
довольно удобно запускать X11 в фоновом режиме,при котором остается возможность
продолжать использовать для работы ту консоль с которой мы стартовали X11,
независимо от них.
Системным администраторам могу описать свой путь решения запуска X11:
a) запуск X11 только через ssh-agent
b) обычный запуск и с использованием ssh-agent
Первый способ состоит в том что пользователя заставляют в принудительном
порядке стартовать оконную среду ичсключительно с использованием ssh-agent.
Здесь можно придумать массу разнообразных вариантов со своими плюсами и
минусами, например создание alias на команду startx во входных скриптах:
unix1% ls -la /usr/local[/etc]/.[a-z]*
-rw-r--r-- 1 root wheel 6 Jun 6 1997 /usr/local/etc/.bash_logout
-rw-r--r-- 1 root wheel 2361 Dec 29 1997 /usr/local/etc/.bash_profile
-rw-r--r-- 1 root wheel 1543 Dec 29 1997 /usr/local/etc/.bashrc
-rwxr-xr-x 1 root wheel 1267 May 18 13:46 /usr/local/etc/.cshrc
-rwxr-xr-x 1 root wheel 1534 Jan 23 14:59 /usr/local/etc/.login
unix1%
На моих серверах пользователи в основном используют в качестве SHELL:
sh,bash,csh,tcsh, я как и большая масса системных администраторов заменяю
стандартные скрипты, которые обычно находятся в директории /etc/skel или
в зависимости от системы в иной директории на болванки с одной строкой-вызовом
скриптов доработанных и проверенных системным администратором, в которые
и вставляется alias на startx.
Примеры:
пользовательские файлы настройки среды:
unix1% cat .cshrc
source /usr/local/etc/.cshrc
unix1% cat .login
source /usr/local/etc/.login
unix1% cat .bashrc
. /usr/local/etc/.bashrc
unix1% cat .bash_profile
. /usr/local/etc/.bash_profile
unix1%
вырезки из /usr/local/etc/.bashrc и /usr/local/etc/.cshrc[.login] соответствен
но (почему указан .login думаю системные администраторы меня поймут)
unix1% grep startx /usr/local/etc/.[a-z]*
/usr/local/etc/.bashrc:alias startx='ssh-agent startx'
/usr/local/etc/.cshrc:alias startx 'ssh-agent startx'
unix1%
Соответствующие изменения производятся и с системныи xinitrc в который
добавляется проверка на собственно аутентикацию.
unix1% grep ssh /usr/X11/lib/X11/xinit/xinitrc
#-ssh-auth
until ssh-askpass | ssh-add -p; do true; done
unix1%
Указанная выше строка должна запускаться до инициализации X clients и вызова
оконного менеджера.
----------------------- cut from xinitrc -----------------------------------
...
until ssh-askpass | ssh-add -p; do true; done
xterm -geometry 80x40+8+9 -name login -ls -sb &
xconsole -geometry 480x130+0-0 -daemon -notify -verbose -fn fixed &
exec fvwm
----------------------- end of cut from xinitrc ----------------------------
Минусы этого способа в том что пользователь может использовать только свои
входные настройки среды - имеет право, и соответственно свой .xinitrc.
Остается лишь одно средство оповещения через различные системы сообщений
и предупреждений, если пользователь либо просто глуп, либо достаточно умен
и игнорирует соблюдение методов предосторожностей, он способствует нарушению
безопасности вашей системы. К такому пользователю должны быть применены
соответствующие санкции, вплоть до полного отключения не только от отдельных
серверов, но и от сети в целом.
Второй способ технически мало отличается от первого ибо приемы могут быть
взаимодополнены или заменены, я подразумевал саму идею, в первом случае
принудительный запуск X11 через ssh-agent, а в данном способе использовать
некий переходной этап - разрешить использование как обычного запуска, так
и с использованием ssh-agent.
Просто переименовываем известный скрипт startx допустим в startX
unix1% mv startx startX
А startx изображаем следующим образом:
#!/bin/sh
if [ -d $HOME/.ssh ]
then ssh-agent startX
else startX
fi
Соответствующие дополнения вносим и в системный xinitrc до старта x-clients
и оконного менеджера
------------------ cut from xinitrc ---------------------------------------
if [ -d $HOME/.ssh ]
then until ssh-askpass | ssh-add -p; do true; done
fi
------------------ cut here -----------------------------------------------
Примечания: все вышеизложенное может использоваться обычными пользователями
в собственных настройках вызова X11 через ssh-agent. Для этого им необходимо
сделать следующее:
unix1% cd
unix1% cp /usr/X11[R...]/lib/X11/xinit/xinitrc .xinitrc
Далее вставить строку "until ssh-askpass | ssh-add -p; do true; done" в
свой .xinitrc, в нужное место, описано выше и в зависимости от используемого
SHELL вставить alias на вызов startx, описано выше.
Будьте аккуратны, все вышеизложенное касается запуска X11 на локальной машине!
[R...] - означает что путь зависит от того как и какая версия X11 установлена.
Рассмотрим запуск X11 через сессию xdm
Если на вашем сервере или рабочей станции X11 запускается через сеанс XDM,
вам необходимо создание неких условий благодаря которым клиенты будут запущены
под ssh-agent. Простейший способ, практически схожий с предыдущим - startx.
Произвести инициализацию клиентов через .xinitrc, который в свою очередь
будет вызываться из стартового файла .xsession.
В качестве примера смотрите .xsession ниже, ssh-agent стартует только при
наличии в домашней директории пользователя поддиректории .ssh.
#!/bin/sh
if [ -d $HOME/.ssh ]
then EXEC="exec ssh-agent"
else EXEC="exec"
fi
if [ -x $HOME/.xinitrc ]
then $EXEC $HOME/.xinitrc
else $EXEC xterm -geometry 80x24+0-60 -ls
fi
Не забудьте проверить статус ваших скриптов и сделайте их исполняемыми:
unix1% chmod a+x ~/.xinitrc ~/.xsession
Примечания: если ваш администратор не позаботился об настройках системы
вам достаточно настроить свои файлы .xinitrc и .xsession, однако если в
вашей системе X11 запускается иным - нестандартным способом лучше всего
обратититься к системному администратору.
На мой взгляд лучше заранее обратиться к администратору и выяснить все
вопросы и это касается любой темы, не только безопасности системы.
Важное: все изложенное не может быть применено к X-terminal'у который
остается узким местом в безопасности вашей системы и сети.
Управление ключами авторизации в памяти
До того как ваше соединение будет авторизовано без использования
passphrase, вы можете использовать ssh-add для добавления необходимых ключей
в память. Для добавления обычных ключей в память локальной системы не требу
ется дополнительных опций. А passphrase будет затребован для дешифрации
этих ключей и не будет отображаться при вводе с клавиатуры.
unix1% ssh-add
Need passphrase for /home/lavr/.ssh/identity (lavr@unix1.jinr.dubna.su).
Enter passphrase: pust' vsegda 2000
Identity added: /home/lavr/.ssh/identity (lavr@unix1.jinr.dubna.su)
Можно указать отличное имя файла от identity где будет хранится ваш личный
ключ, если вас не устраивают значения по умолчанию, только не забывайте
затем что там будет храниться ваш private key.
Опция -d позволяет удалять ключи из памяти, не забудьте что в SSH нет
команды "ssh-delete".
unix1% ssh-add -d ~/.ssh/isp
Получить список всех текущих ключей в памяти - опция -l .
unix1% ssh-add -l
1024 33 [lots of numbers] lavr@unix1.jinr.dubna.su
Ну и конечно вы можете использовать ключ -D для удаления всех ключей из
памяти.
unix1% ssh-add -D
Этого достаточно если вы добавили ключи в память на удаленной системе и
не хотите заново установить соединение до тех пор пока ключи не будут
удалены.
Запуск команд на удаленной системе
Команда ssh может оказаться удобной для использования запуска программ или
команд на удаленной системе без осуществления интерактивного входа на нее.
Результат действия которых - вывод, может быть отображен и управляться на
локальной системе. Ниже приведен подобный пример.
unix1% ssh cv who
ckoch tty03 Jun 30 14:09
lavr ttyp0 Jun 30 11:21 (cv.jinr.dubna.su)
shchepun ttyp1 Jun 30 14:21 (axpls7.lns.infn.)
grom ttyp2 Jun 29 15:27 (unix0.jinr.dubna)
veron ttyp3 Jun 30 13:32 (159.93.22.23)
ruben ttyp4 Jun 30 13:29 (159.93.17.40)
grom ttyp5 Jun 30 12:32 (unix0.jinr.dubna)
luna ttyp6 Jun 30 11:38 (dct160.jinr.dubn)
annask ttypa Jun 30 13:40 (xct174:0.0)
vvm ttypb Jun 29 16:18 (cv.jinr.dubna.su)
smanosh ttypd Jun 30 14:03 (bcv.jinr.dubna.s)
unix1%
Если вы работаете в X Window System, то можете запустить xterm для получения
интерактивного сеанса на удаленной машине:
unix1% ssh -n cv xterm &
[1] 15866
unix1%
Использование опции -n запрещает чтение со стандартного вывода (в /dev/nul)
и запускает ssh в фоновом режиме. Однако не стоит использовать данный метод
запуска если удаленная сторона пытается запрашивать вас ввести passphrase или
passowrd.
Копирование файлов между системами
Вы можете копировать файлы между локальной и удаленной системами или между
двумя удаленными системами используя команду scp и все это не требует какого
либо вашего присутствия на удаленной системе. Для указания файла на удаленной
машине достаточно лишь перед именем файла указать имя удаленной маштны и
отделить от файла двоеточием, host:filename.
Если вы опустили имя выходного файла или директории при копировании, тогда
будет использоваться имя источника копирования. Самый простой способ задания
имени сохранения копируемого файла и помещения в текущую директорию это
указание точки:
unix1% scp -p spp:dead.letter .
unix1%
Опция -p необязательна, она указывает на то чтобы все атрибуты файла, такие
ка время модификации, доступа и другие режимы сохранились от оригинального
копируемого файла. Однако это для каждого пользователя индивидуально и зависит
от личных задач и целейю
unix1% scp -r cv:source src
unix1%
В данном примере опция -r означает что необходимо рекурсивно скопировать
директорию source расположенную на машине "cv" в директорию src на "unix1".
Можно также отметить еще ряд полезных ключей:
-C - копирование с компрессией, понятно что нет смысла использовать данную
опцию для копирования уже сжатых данных
-v - как и в остальных утилитах ssh[slogin] служит для вывода отладочной
информации.
Необходимо заметить что относительные имена на локальной и удаленной системах
разрешаются по разному:
- на локальной за базу принимается текущая директория
- на удаленной за базу принимается домашняя директория пользователя
unix1% scp bcv:ftptmp/ftp.out spp:temp/ftp.out.bcv
unix1%
Примечание: необходимо отметить, что при копировании с удаленной машины на
удаленную, копирование происходит непосредственно между теми двумя
машинами без участия локальной.
Изменение стандартных настроек
Значения по умолчанию могут устанавливаться и изменяться каждым пользователем
в файле ~/.ssh/config в дополнение или альтернативу системному файлу -
/etc/ssh_config.
Каждая строка в конфигурации начинается с ключего слова HOST. Для задания
общих значений можно использовать образцы соответствия:
* ? соответсвует любому символу
* * соответствует пустой или последовательности любого количества символов
обычно используются следующие ключевые слова (умолчание в кавычках):
Compression yes/no (no)
использование компрессии в соединениях
CompressionLevel 1-9 (6)
уровень сжатия: 1 - самый быстрый, 9 - самый медленный (достигается
максимальная компрессия), имеет смысл использовать на медленных
соединениях
FallBackToRsh yes/no (yes)
если не удается установить секретное соединение с использованием SSH,
пытаться перейти на использование Rsh, в системах со строгим соблюдением
секретности данная опция отключается
KeepAlive yes/no (yes)
Управляет использование сообщения TCP keepalive. Когда используется,
позволяет определять наличие связи в сети и автоматически закрывать
соединение при обрыве или потере соединения.
User account (local account)
Укзывает имя на удаленной системе. Можете добавить эту характеристику
вместо использования опции -l.
Ниже пример файла ~/.ssh/config.
Host nusun.jinr.ru
User lavr
Compression no
Host sunhe.jinr.ru
User lavr
CompressionLevel 6
FallBackToRsh no
KeepAlive yes
Host *
Compression yes
CompressionLevel 9
FallBackToRsh yes
KeepAlive no
Не забывайте, что host-зависимые переменные следует определять до задания
остальных - общих параметров (по-умолчанию), те, общие параметры для ssh
укажите в самом конце конфигурационного файла, а выше задайте конкретные
и специфические значения для индивидуальных host'ов и подсетей.
Из верхнего примера видно, что для всех hosts приписывается работать со
сжатием данных - уровень 9, с переходом на rsh и без keepalive.
И тем не менее с nusun работать под account=lavr, с sunhe с более быстрой
компрессией и сваливанием на rsh ибо там отключен sshd и проверкой связи.
Для изучения полного списка опций читайте руководство по ssh/sshd.
Ссылки на другие полезные источники информации
/* данный пункт готовиться */
