Различия между версиями 6 и 26 (по 20 версиям)
Версия 6 от 2008-10-07 22:40:11
Размер: 10781
Комментарий:
Версия 26 от 2008-10-19 15:15:35
Размер: 15084
Редактор: MaximByshevskiKonopko
Комментарий:
Удаления помечены так. Добавления помечены так.
Строка 5: Строка 5:
Исходя из вышесказанного, стоит добавить, что пользоваться по ssh учетной записью суперпользователя --- небезопасно. Среди прочего, root может с помощью специальной команды (''скрипт'') посмотреть список выполненных команд любого пользователя. Стоит добавить, что пользоваться по ssh учетной записью суперпользователя просто-напросто небезопасно.
## (''скрипт? аудио?'')
## специальной команды? Вроде надо стать там рутом и посмотреть ~/bash_history юзера
Строка 7: Строка 9:
Есть альтернативный способ. До этого мы имели дело только с ключами со стороны хоста. Но пользователь имеет право обладать собственным ssh-ключом (закрытый и открытый) и раздавать открытые ключи, чтобы система аутентификации хоста могла затем просмотреть список имеющихся у нее ключей, найти его и убедиться в подлинности запрашивающего клиента. Есть альтернативный способ аутентификации. До этого мы имели дело только с ключами со стороны хоста. Но пользователь имеет право обладать собственным ssh-ключом (закрытым и открытым) и раздавать открытые ключи, чтобы система аутентификации хоста могла затем просмотреть список имеющихся у неё ключей, найти его и убедиться в подлинности запрашивающего клиента.
Строка 11: Строка 13:
(''заголовок типа "Без парольной фразы"'') === Незащищённые ключи ===
Строка 13: Строка 15:
Попробуем сгенерировать ssh-ключ. (''скрипт!!'') ## (''м-да, хорошо звучит %)'')
Строка 15: Строка 17:
Заглянем в локальный каталог .ssh. Теперь там есть файлы id_rsa и .pub. Стоит обратить внимание на права доступа к этим файлам: публичный ключ доступен всем, закрытый - только владельцу. Для того, чтобы по ключу можно было соединиться с удаленной машины, надо добавить открытый ключ в файл authorized_keys. Попробуем сгенерировать ssh-ключ:
{{{
$ ssh-keygen
Generating public/private rsa key pair.
Enter file in which to save the key (/home/user/.ssh/id_rsa):
Enter passphrase (empty for no passphrase):
Enter same passphrase again:
Your identification has been saved in /home/user/.ssh/id_rsa.
Your public key has been saved in /home/user/.ssh/id_rsa.pub.
The key fingerprint is:
38:7b:6c:46:bd:44:77:45:47:ef:6c:a0:3b:e2:1b:a1 user@class305.mpgu.edu.ru
}}}
Строка 17: Строка 30:
Изначально данный файл не существует. Необходимо выполнить команду ssh-copy-id (''скрипт'') , которая есть только дистрибутиве AltLinux. Это скрипт shell, который занимается именно тем, о чем мы только что говорили - создает этот файл в случае его отсутствия и добавляет ключ в файл. Если мы повторим команду ls, то увидим, что файл authorized_keys появился. Заглянем в локальный каталог .ssh:
Строка 19: Строка 32:
(''заголовок типа: "с пассфразой"'') {{{
$ ls .ssh
agent id_rsa id_rsa.pub known_hosts
}}}
Строка 21: Строка 37:
Очевидно, что ключом без пароля можно пользоваться только в пределах локальной сети, поскольку он хранится в файле и может "утечь" легче, чем набираемый пароль. К примеру, любой, кто имеет права суперпользователя на машине, где вы его храните, может найти ваш ключ и воспользоваться им. Поэтому ключ следует защищать пассфразой. Пароль, которым мы защищаем ключ, очень ценен, так как он позволяет воспользоваться вашим логином на всех машинах, на которых этот ключ хранится. Потому желательно, чтобы пассфраза не совпадала с паролем. Теперь там есть файлы id_rsa и .pub. Стоит обратить внимание на права доступа к этим файлам: публичный ключ доступен всем, закрытый - только владельцу:
Строка 23: Строка 39:
Поместим теперь и пароль на удаленную машину и попробуем туда войти. Видно, что теперь у нас спрашивают пассфразу. Вопрос: в чём же удобство? Несмотря на ощущение, что мы вернулись к тому, с чего начали, то сейчас есть удобство, и пароль тут один: если 10 разных машин, у которых 10 разных паролей, более того, можно на удаленных машинах можно вообще убить пароль, чтобы можно было логиниться только по ssh. Ещё один бонус --- пассфраза не передаётся по сети. Есть один существенный недостаток --- если машина, за которой вы сидите, небезопасна, и там кейлоггер, то утекает гораздо больше, чем логин и пароль до конкретной машины. {{{
$ ls -l .ssh/
итого 16
srw------- 1 user user 0 Июл 30 14:54 agent
-rw------- 1 user user 1675 Июл 30 16:13 id_rsa
-rw-r--r-- 1 user user 406 Июл 30 16:13 id_rsa.pub
-rw-r--r-- 1 user user 2046 Июл 30 15:51 known_hosts
}}}
Строка 25: Строка 48:
Есть вариант ношения ключа на специальных флешках, есть модуль ssh, который умеет ей пользоваться, и отличие от хранения в файле в том, что его нельзя считать. Недостаток в том, что часть программной реализации перекладывается на железку, которая может не поддерживаться. Для того, чтобы по ключу можно было соединиться с удалённой машиной, надо добавить открытый ключ в файл authorized_keys на удалённом компьютере.
Изначально данный файл не существует. Необходимо выполнить команду ssh-copy-id (!AltLinux-специфичная утилита). Это скрипт shell, который создаёт этот файл в случае его отсутствия и добавляет ключ в файл:
Строка 27: Строка 51:
Тем не менее, в каком-то смысле мы всё равно, как начали, так и закончили, на показали конфетку --- беспарольный вход, но всё равно теперь надо вводить пассфразу, которая в идеале должна быть более криптостойкой, чем обычный пароль. {{{
$ ssh-copy-id user@10.30.5.197
Adding 1 SSH2 identity...
user@10.30.5.197's password:
done.
Now try logging to the remote host, with "ssh user@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 user user 0 Июл 30 14:13 agent
-rw-r--r-- 1 user user 406 Июл 30 16:17 authorized_keys2
-rw-r--r-- 1 user user 393 Июл 19 17:41 known_hosts
}}}

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

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

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

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

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

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

Тем не менее, в каком-то смысле мы всё равно закончили тем же, с чего и начали --- добившись-таки наконец беспарольного входа, мы заполучили необходимость каждый раз вводить парольную фразу, которая в идеале должна быть ещё более надёжной, чем ваш обычный пароль.
Строка 31: Строка 91:
Для того, чтобы много раз пассфразу не хранить, есть ssh-agent, с точки зрения стартовой вы вводите пассфразу один раз, и дальше при ssh сначала ходит к агенту, спрашивает, а нет ли её у него, и всё. Ssh-агент позволяет не вводить кодовую фразу множество раз. При использовании агента вы вводите фразу один раз, и далее при каждом подключении программа ssh обращается к агенту с вопросом, содержится ли в нем нужная фраза.
Строка 33: Строка 93:
Он запускается автоматом (set| grep SSH), поскольку это входит в стартовые сценарии ПСПО, но при необходимости можно сделать это руками: Агент запускается автоматически, его запуск входит в стартовые сценарии ПСПО:
Строка 36: Строка 96:
ssh-agent $echo set | grep SSH
SSH_AGENT_PID=4328
SSH_AUTH_SOCK=/home/user/.ssh/agent
Строка 39: Строка 101:
По умолчанию ssh-агент не хранит никаких ключей, в этом можно убедиться с помощью ssh-add -L При необходимости можно установить такой запуск вручную.
Строка 41: Строка 103:
Добавим наш ключ: ssha-add .ssh/id-rsa (''скрипт'') ##(''дописать бы из скрипта...'')
Строка 43: Строка 105:
Зайдём ещё раз. Видим, что пассфразу нас не просили, но при -v увидим, что она использовалась. Первоначально ssh-агент, разумеется, не хранит никаких ключей, и вы можете в этом убедиться, набрав команду ssh-add -L:
Строка 45: Строка 107:
Про переброс агента: можно проделать следующую штуку: при переходе на другую машину (''скрипт?''). Если сказать ssh -A, то при ssh-add мы увидим наш ключ. При заходе на удаленную машину можно сказать порт, по которому можно обратиться к ssh-агенту. Это переменная окружения. Это штука потенциально опасная, потому что root на той машине может совершенно спокойно воспользоваться вашим агентом для получения доступа на те хосты, на которых вы этим агентом пользуетесь. С другой стороны, носить с собой агента удобно, потому что с той машины можно ходить на третью и так далее. {{{
$ ssh-add -L
The agent has no identities.
}}}
Строка 47: Строка 112:
У вас может быть некий доверенный компьютер, на котором и только на нём храниться закрытый ключ. Можно зайти по паролю на доверенный хост, запустить здесь агента, сказать там ssh-add, чтобы на локальной машине приехал оттуда ключ, чтобы с этим ключом ходить. То есть, у вас есть уверенность, что ПО не модифицировано, но нет уверенности, что после вас не придёт человек и не получит прямым перебором паролей доступ к вашему закрытому ключу (удаление ключа в такой ситуации не является гарантией безопасности) задампает винчестер и потом не начнёт грубым перебором подбирать пассфразу. Добавим наш ключ:
Строка 49: Строка 114:
{{{
$ ssh-add .ssh/id_rsa
Enter passphrase for .ssh/id_rsa:
Identity added: .ssh/id_rsa (.ssh/id_rsa)
}}}
Строка 50: Строка 120:
##Добавить про запрос подтверждений ссх-агентом Зайдём теперь снова на удалённый компьютер:

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

Ввод кодовой фразы на этот раз не потребовался. Но, если запустить ssh с ключом -v, то можно увидеть, что она, тем не менее, использовалась:

{{{
$ ssh -v 10.30.5.197
OpenSSH_5.0p1, OpenSSL 0.9.8d 28 Sep 2006
debug1: Reading configuration data /etc/openssh/ssh_config
debug1: Applying options for *
debug1: Connecting to 10.30.5.197 [10.30.5.197] port 22.
debug1: Connection established.
debug1: identity file /home/user/.ssh/id_rsa type 1
debug1: identity file /home/user/.ssh/id_dsa type -1
debug1: Remote protocol version 2.0, remote software version OpenSSH_4.7
debug1: match: OpenSSH_4.7 pat OpenSSH*
debug1: Enabling compatibility mode for protocol 2.0
debug1: Local version string SSH-2.0-OpenSSH_5.0
debug1: SSH2_MSG_KEXINIT sent
debug1: SSH2_MSG_KEXINIT received
debug1: kex: server->client aes256-ctr hmac-md5 none
debug1: kex: client->server aes256-ctr hmac-md5 none
debug1: SSH2_MSG_KEX_DH_GEX_REQUEST(1024<4096<8192) sent
debug1: expecting SSH2_MSG_KEX_DH_GEX_GROUP
debug1: SSH2_MSG_KEX_DH_GEX_INIT sent
debug1: expecting SSH2_MSG_KEX_DH_GEX_REPLY
debug1: Host '10.30.5.197' is known and matches the RSA host key.
debug1: Found key in /home/user/.ssh/known_hosts:4
debug1: ssh_rsa_verify: signature correct
debug1: SSH2_MSG_NEWKEYS sent
debug1: expecting SSH2_MSG_NEWKEYS
debug1: SSH2_MSG_NEWKEYS received
debug1: SSH2_MSG_SERVICE_REQUEST sent
debug1: SSH2_MSG_SERVICE_ACCEPT received
debug1: Authentications that can continue: publickey,password
debug1: Next authentication method: publickey
debug1: Offering public key: /home/user/.ssh/id_rsa
debug1: Server accepts key: pkalg ssh-rsa blen 277
debug1: Authentication succeeded (publickey).
debug1: channel 0: new [client-session]
debug1: Entering interactive session.
debug1: Sending environment.
debug1: Sending env LANG = ru_RU.UTF-8
Last login: Wed Jul 30 16:37:02 2008 from 10.30.5.1
}}}

===== Проброс (''forwarding'') агента =====

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

Другой вариант --- выделить некий доверенный компьютер, такой, что закрытый ключ хранится на нём и ''только'' на нём. Режим работы в таком случае будет: зайти по паролю на доверенный хост, запустить на нем ssh-агент, выполнить ssh-add, чтобы на локальную машину пришел ключ, и использовать этот ключ подобающим образом. Разумеется, это имеет смысл только в уверенности, что на текущей машине нет кейлоггера или иных средств слежения за клавиатурой.
Строка 58: Строка 183:
|| 37 || 1 || 1 || 1 || || 1 || GeorgeTarasov, GeorgeTarasov, MaximByshevskiKonopko || || || || 90 || 1 || 1 || 1 || || 1 || GeorgeTarasov + ПетрНикольский, GeorgeTarasov, MaximByshevskiKonopko || || ||

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

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

Стоит добавить, что пользоваться по ssh учетной записью суперпользователя просто-напросто небезопасно.

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

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

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

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

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

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

$ ls .ssh
agent id_rsa id_rsa.pub known_hosts

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

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

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

$ ssh-copy-id user@10.30.5.197
Adding 1 SSH2 identity... 
user@10.30.5.197's password: 
done.
Now try logging to the remote host, with "ssh user@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 user user   0 Июл 30 14:13 agent
-rw-r--r-- 1 user user 406 Июл 30 16:17 authorized_keys2
-rw-r--r-- 1 user user 393 Июл 19 17:41 known_hosts

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

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

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

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

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

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

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

Ssh-агент

Ssh-агент позволяет не вводить кодовую фразу множество раз. При использовании агента вы вводите фразу один раз, и далее при каждом подключении программа ssh обращается к агенту с вопросом, содержится ли в нем нужная фраза.

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

$echo set | grep SSH
SSH_AGENT_PID=4328
SSH_AUTH_SOCK=/home/user/.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.

Ввод кодовой фразы на этот раз не потребовался. Но, если запустить ssh с ключом -v, то можно увидеть, что она, тем не менее, использовалась:

$ ssh -v 10.30.5.197
OpenSSH_5.0p1, OpenSSL 0.9.8d 28 Sep 2006
debug1: Reading configuration data /etc/openssh/ssh_config
debug1: Applying options for *
debug1: Connecting to 10.30.5.197 [10.30.5.197] port 22.
debug1: Connection established.
debug1: identity file /home/user/.ssh/id_rsa type 1
debug1: identity file /home/user/.ssh/id_dsa type -1
debug1: Remote protocol version 2.0, remote software version OpenSSH_4.7
debug1: match: OpenSSH_4.7 pat OpenSSH*
debug1: Enabling compatibility mode for protocol 2.0
debug1: Local version string SSH-2.0-OpenSSH_5.0
debug1: SSH2_MSG_KEXINIT sent
debug1: SSH2_MSG_KEXINIT received
debug1: kex: server->client aes256-ctr hmac-md5 none
debug1: kex: client->server aes256-ctr hmac-md5 none
debug1: SSH2_MSG_KEX_DH_GEX_REQUEST(1024<4096<8192) sent
debug1: expecting SSH2_MSG_KEX_DH_GEX_GROUP
debug1: SSH2_MSG_KEX_DH_GEX_INIT sent
debug1: expecting SSH2_MSG_KEX_DH_GEX_REPLY
debug1: Host '10.30.5.197' is known and matches the RSA host key.
debug1: Found key in /home/user/.ssh/known_hosts:4
debug1: ssh_rsa_verify: signature correct
debug1: SSH2_MSG_NEWKEYS sent
debug1: expecting SSH2_MSG_NEWKEYS
debug1: SSH2_MSG_NEWKEYS received
debug1: SSH2_MSG_SERVICE_REQUEST sent
debug1: SSH2_MSG_SERVICE_ACCEPT received
debug1: Authentications that can continue: publickey,password
debug1: Next authentication method: publickey
debug1: Offering public key: /home/user/.ssh/id_rsa
debug1: Server accepts key: pkalg ssh-rsa blen 277
debug1: Authentication succeeded (publickey).
debug1: channel 0: new [client-session]
debug1: Entering interactive session.
debug1: Sending environment.
debug1: Sending env LANG = ru_RU.UTF-8
Last login: Wed Jul 30 16:37:02 2008 from 10.30.5.1

Проброс (''forwarding'') агента

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

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


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

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

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

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

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

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

Level

Maintainer

Start date

End date

90

1

1

1

1

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


CategoryLectures CategoryPspo CategoryMpgu CategoryUneex

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