Различия между версиями 10 и 11
Версия 10 от 2008-10-09 14:57:20
Размер: 12015
Комментарий:
Версия 11 от 2008-10-09 19:54:27
Размер: 13115
Комментарий:
Удаления помечены так. Добавления помечены так.
Строка 17: Строка 17:
$ssh-keygen $ ssh-keygen
Строка 31: Строка 31:
$ls .ssh $ ls .ssh
Строка 38: Строка 38:
$ls -l .ssh/ $ ls -l .ssh/
Строка 51: Строка 51:
$ssh-copy-id saj@10.30.5.197 $ ssh-copy-id saj@10.30.5.197
Строка 60: Строка 60:
Если мы повторим команду ls, то увидим, что файл authorized_keys появился. Если мы повторим команду ls на удаленном компьютере, то увидим, что файл authorized_keys появился:

{{{
$ ssh 10.30.5.197 'ls -l .ssh'
итого 8
srw------- 1 saj saj 0 Июл 30 14:13 agent
-rw-r--r-- 1 saj saj 406 Июл 30 16:17 authorized_keys2
-rw-r--r-- 1 saj saj 393 Июл 19 17:41 known_hosts
}}}
Строка 64: Строка 72:
Очевидно, что ключом без пароля можно пользоваться только в пределах локальной сети, поскольку он хранится в файле и может "утечь" легче, чем набираемый пароль. К примеру, любой, кто имеет права суперпользователя на машине, где вы его храните, может найти ваш ключ и воспользоваться им. Поэтому ключ следует защищать пассфразой. Пароль, которым мы защищаем ключ, очень ценен, так как он позволяет воспользоваться вашим логином на всех машинах, на которых этот ключ хранится. Потому желательно, чтобы пассфраза не совпадала с паролем. Очевидно, что ключом без пароля можно пользоваться только в пределах локальной сети, поскольку он хранится в файле и может "утечь" легче, чем набираемый пароль. К примеру, любой, кто имеет права суперпользователя на машине, где вы его храните, может найти ваш ключ и воспользоваться им. Поэтому ключ следует защищать пассфразой. Пароль, которым мы защищаем ключ, очень ценен, так как он позволяет воспользоваться вашим логином на всех машинах, на которых этот ключ хранится. Потому желательно, чтобы пассфраза не совпадала с паролем. Создание ключа, защищенного парольной фразой аналогично созданию незащищенного ключа.
Строка 66: Строка 74:
Поместим теперь и пароль на удаленную машину и попробуем туда войти. (''скрипт'') Видно, что теперь у нас спрашивают пассфразу. Вопрос: в чём же удобство? Несмотря на ощущение, что мы вернулись к тому, с чего начали, то сейчас есть удобство, и пароль тут один: если 10 разных машин, у которых 10 разных паролей, более того, можно на удаленных машинах можно вообще убить пароль, чтобы можно было логиниться только по ssh. Ещё один бонус --- пассфраза не передаётся по сети. Есть один существенный недостаток --- если машина, за которой вы сидите, небезопасна, и там кейлоггер, то утекает гораздо больше, чем логин и пароль до конкретной машины. Поместим теперь и пароль на удаленную машину и попробуем туда войти:
Строка 68: Строка 76:
Есть вариант ношения ключа на специальных флешках, есть модуль ssh, который умеет ей пользоваться, и отличие от хранения в файле в том, что его нельзя считать. Недостаток в том, что часть программной реализации перекладывается на железку, которая может не поддерживаться. {{{
$ ssh 10.30.5.197
Enter passphrase for key '/home/saj/.ssh/id_rsa':
Last login: Wed Jul 30 15:52:19 2008 from 10.30.5.1
}}}
Строка 70: Строка 82:
Тем не менее, в каком-то смысле мы всё равно, как начали, так и закончили, на показали конфетку --- беспарольный вход, но всё равно теперь надо вводить пассфразу, которая в идеале должна быть более криптостойкой, чем обычный пароль. Видно, что теперь у нас спрашивают пассфразу. Вопрос: в чём же удобство? Несмотря на ощущение, что мы вернулись к тому, с чего начали, сейчас есть удобство: пароль всего один, его вполне можно импользовать для 10 разных машин, к которым, иначе, пришлось бы создавать 10 разных паролей. Более того, можно на удаленных машинах можно вообще убить пароль, запретив таким образом локальный вход и оставив только удаленный доступ по ssh. Ещё один бонус --- пассфраза не передаётся по сети. Есть один существенный недостаток --- если машина, за которой вы сидите, небезопасна, и там кейлоггер, то злоумышленник получит доступ не к одному конкретному компьютеру, а ко всем, на которых хранится открытый ключ.

Есть вариант ношения ключа на специальных флешках, есть модуль ssh, который умеет ей пользоваться. Отличие от хранения в файле в том, что его нельзя считать. Недостаток в том, что часть программной реализации перекладывается на железку, которая может не поддерживаться.

Тем не менее, в каком-то смысле мы всё равно, как начали, так и закончили, нам показали конфетку --- беспарольный вход, но всё равно теперь надо вводить пассфразу, которая в идеале должна быть более криптостойкой, чем обычный пароль.
Строка 76: Строка 92:
Он запускается автоматом (set | grep SSH), поскольку это входит в стартовые сценарии ПСПО, но при необходимости можно сделать это руками: Он запускается автоматом, поскольку это входит в стартовые сценарии ПСПО:
Строка 79: Строка 95:
ssh-agent $echo set | grep SSH
SSH_AGENT_PID=4328
SSH_AUTH_SOCK=/home/saj/.ssh/agent
Строка 82: Строка 100:
При необходимости можно установить такой запуск вручную. (''дописать бы из скрипта...'')
Строка 97: Строка 116:
Зайдём ещё раз. Видим, что пассфразу нас не просили, но при -v увидим, что она использовалась. Зайдём ещё раз на удаленный компьютер:
Строка 99: Строка 118:
Про переброс агента: можно проделать следующую штуку: при переходе на другую машину (''скрипт?''). Если сказать ssh -A, то при ssh-add мы увидим наш ключ. При заходе на удаленную машину можно сказать порт, по которому можно обратиться к ssh-агенту. Это переменная окружения. Это штука потенциально опасная, потому что root на той машине может совершенно спокойно воспользоваться вашим агентом для получения доступа на те хосты, на которых вы этим агентом пользуетесь. С другой стороны, носить с собой агента удобно, потому что с той машины можно ходить на третью и так далее. {{{
$ ssh 10.30.5.197
Last login
: Wed Jul 30 16:23:00 2008 from 10.30.5.
}}}

Видно, что пассфразу у нас не просили. Если задать кл
юч -v, то мы увидим, что она, тем не менее, использовалась:

{{{
$ ssh -v 10.30.5.197
}}}

(''здесь я не разобрал скрипт'')

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

SSH: использование ключей

Как видно, при каждой передаче информации нам приходится вводить пароль. В чем здесь может таиться опасность? Будучи ответственным за безопасность данных, администратор обязан принимать во внимание тот факт, что пароль может быть подсмотрен во время набора, или попросту подобран. Каждый набор пользователем пароля --- лишнее беспокойство для администратора.

Исходя из вышесказанного, стоит добавить, что пользоваться по ssh учетной записью суперпользователя --- небезопасно. Среди прочего, root может с помощью специальной команды (скрипт? аудио?) посмотреть список выполненных команд любого пользователя.

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

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

Незащищенные ключи

(м-да, хорошо звучит %))

Попробуем сгенерировать ssh-ключ:

$ ssh-keygen
Generating public/private rsa key pair.
Enter file in which to save the key (/home/saj/.ssh/id_rsa): 
Enter passphrase (empty for no passphrase): 
Enter same passphrase again: 
Your identification has been saved in /home/saj/.ssh/id_rsa.
Your public key has been saved in /home/saj/.ssh/id_rsa.pub.
The key fingerprint is:
38:7b:6c:46:bd:44:77:45:47:ef:6c:a0:3b:e2:1b:a1 saj@class305.mpgu.edu.ru

Заглянем в локальный каталог .ssh:

$ ls .ssh
agent id_rsa id_rsa.pub known_hosts known_hosts~

Теперь там есть файлы id_rsa и .pub. Стоит обратить внимание на права доступа к этим файлам: публичный ключ доступен всем, закрытый - только владельцу:

$ ls -l .ssh/
итого 16
srw------- 1 saj saj    0 Июл 30 14:54 agent
-rw------- 1 saj saj 1675 Июл 30 16:13 id_rsa
-rw-r--r-- 1 saj saj  406 Июл 30 16:13 id_rsa.pub
-rw-r--r-- 1 saj saj 2046 Июл 30 15:51 known_hosts
-rw-r--r-- 1 saj saj 2046 Июл 30 15:46 known_hosts~

Для того, чтобы по ключу можно было соединиться с удаленной машиной, надо добавить открытый ключ в файл authorized_keys на удаленном компьютере. Изначально данный файл не существует. Необходимо выполнить команду ssh-copy-id, которая есть только дистрибутиве AltLinux. Это скрипт shell, который создает этот файл в случае его отсутствия и добавляет ключ в файл:

$ ssh-copy-id saj@10.30.5.197
Adding 1 SSH2 identity... 
saj@10.30.5.197's password: 
done.
Now try logging to the remote host, with "ssh saj@10.30.5.197", and check in:
.ssh/authorized_keys2
to make sure we haven't added extra keys that you weren't expecting.

Если мы повторим команду ls на удаленном компьютере, то увидим, что файл authorized_keys появился:

$ ssh 10.30.5.197 'ls -l .ssh'
итого 8
srw------- 1 saj saj   0 Июл 30 14:13 agent
-rw-r--r-- 1 saj saj 406 Июл 30 16:17 authorized_keys2
-rw-r--r-- 1 saj saj 393 Июл 19 17:41 known_hosts

Защита ключа с помощью парольной фразы

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

Поместим теперь и пароль на удаленную машину и попробуем туда войти:

$ ssh 10.30.5.197
Enter passphrase for key '/home/saj/.ssh/id_rsa': 
Last login: Wed Jul 30 15:52:19 2008 from 10.30.5.1

Видно, что теперь у нас спрашивают пассфразу. Вопрос: в чём же удобство? Несмотря на ощущение, что мы вернулись к тому, с чего начали, сейчас есть удобство: пароль всего один, его вполне можно импользовать для 10 разных машин, к которым, иначе, пришлось бы создавать 10 разных паролей. Более того, можно на удаленных машинах можно вообще убить пароль, запретив таким образом локальный вход и оставив только удаленный доступ по ssh. Ещё один бонус --- пассфраза не передаётся по сети. Есть один существенный недостаток --- если машина, за которой вы сидите, небезопасна, и там кейлоггер, то злоумышленник получит доступ не к одному конкретному компьютеру, а ко всем, на которых хранится открытый ключ.

Есть вариант ношения ключа на специальных флешках, есть модуль ssh, который умеет ей пользоваться. Отличие от хранения в файле в том, что его нельзя считать. Недостаток в том, что часть программной реализации перекладывается на железку, которая может не поддерживаться.

Тем не менее, в каком-то смысле мы всё равно, как начали, так и закончили, нам показали конфетку --- беспарольный вход, но всё равно теперь надо вводить пассфразу, которая в идеале должна быть более криптостойкой, чем обычный пароль.

Ssh-агент

Для того, чтобы много раз пассфразу не хранить, есть ssh-agent, с точки зрения стартовой вы вводите пассфразу один раз, и дальше при ssh сначала ходит к агенту, спрашивает, а нет ли её у него, и всё.

Он запускается автоматом, поскольку это входит в стартовые сценарии ПСПО:

$echo set | grep SSH
SSH_AGENT_PID=4328
SSH_AUTH_SOCK=/home/saj/.ssh/agent

При необходимости можно установить такой запуск вручную. (дописать бы из скрипта...) По умолчанию ssh-агент не хранит никаких ключей, в этом можно убедиться с помощью ssh-add -L:

$ ssh-add -L
The agent has no identities.

Добавим наш ключ:

$ ssh-add .ssh/id_rsa
Enter passphrase for .ssh/id_rsa: 
Identity added: .ssh/id_rsa (.ssh/id_rsa)

Зайдём ещё раз на удаленный компьютер:

$ ssh 10.30.5.197
Last login: Wed Jul 30 16:23:00 2008 from 10.30.5.

Видно, что пассфразу у нас не просили. Если задать ключ -v, то мы увидим, что она, тем не менее, использовалась:

$ ssh -v 10.30.5.197

(здесь я не разобрал скрипт)

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

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


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

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

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

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

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

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

Level

Maintainer

Start date

End date

37

1

1

1

1

GeorgeTarasov + ПетрНикольский, GeorgeTarasov, MaximByshevskiKonopko


CategoryLectures CategoryPspo CategoryMpgu CategoryUneex

PspoClasses/080730/03SshKeys (последним исправлял пользователь MaximByshevskiKonopko 2008-10-19 15:15:35)