Differences between revisions 1 and 15 (spanning 14 versions)
Revision 1 as of 2008-08-01 00:34:56
Size: 9433
Editor: eSyr
Comment:
Revision 15 as of 2008-10-09 21:08:24
Size: 15425
Comment:
Deletions are marked like this. Additions are marked like this.
Line 3: Line 3:
Вот мы попередавали файлы, ... . Каждый раз мы вводили пароль. Некоторым кажется, что жто плох. Почему плохо? Мы, как адм. этой машины, каждый раз, когда присх. авт. по парлю, мы принимаем в внимание, что у этого человека стоит недруг за спиной. Кроме того, есть такая штука, как тупой надор паролей. В любм случае, захд в ссх п парлю сопр. некоторым напряжением со стороны адм., по скольку с ой стороны он каждый раз засвечивается. Как видно, при каждой передаче информации нам приходится вводить пароль. В чем здесь может таиться опасность? Будучи ответственным за безопасность данных, администратор обязан принимать во внимание тот факт, что пароль может быть подсмотрен во время набора, или попросту подобран. Каждый набор пользователем пароля --- лишнее беспокойство для администратора.
Line 5: Line 5:
Что касается огина руту, ... Вобще логиниться рутом это вообще неопр. штука. Вы как адм. читаете лги и видите, что кто-т логинился рутом и чт-то там понаделал, поэтому даже локальн не реком. логиниться рутом и что-т там понаделал. Исходя из вышесказанного, стоит добавить, что пользоваться по ssh учетной записью суперпользователя --- небезопасно. Среди прочего, root может с помощью специальной команды посмотреть список выполненных команд любого пользователя.
Line 7: Line 7:
Есть альтернативный способ. Мы тут д этого имели дело с ключами со сторны хоста. Пользователю не возмб иметь свой ключ персональный ssh-шный и раздавать открыте ключи, чтобы система аутентификации смотрела на список имеющихся ключей и видела, что этоимено тото пользователь. ## (''скрипт? аудио?'')
## специальной команды? Вроде надо стать там рутом и посмотреть ~/bash_history юзера
Line 9: Line 10:
Ключи акже утекают, но они не светятся и не передаются. Да, при утере носителя с ключём это равносильно разглашению пароля, на ключ мжн запарлить. Сгенерируем ключ. Есть альтернативный способ. До этого мы имели дело только с ключами со стороны хоста. Но пользователь имеет право обладать собственным ssh-ключом (закрытым и открытым) и раздавать открытые ключи, чтобы система аутентификации хоста могла затем просмотреть список имеющихся у нее ключей, найти его и убедиться в подлинности запрашивающего клиента.
Line 11: Line 12:
Псмотрите локльный .ssh. Там появился id_rsa и .pub. посмтрим их права. Публичный доступен всем, закрытый тлько владельцу. Для обесп. логина п ключу на уд. машине, надо добавить ткр. ключ в файл authorized_keys. Утечка ключей возможна и здесь, но ключи не передаются и не набираются вручную. Разумеется, утеря носителя с ключом равносильна открытому разглашению ключа, но ключи можно защищать.
Line 13: Line 14:
Этого фалйа там не существует. Теперь вып. команду ssh-copy-id, которая есть только в альте. Это шеллскрипт, который занимается рвно тем, чт сказано. Если повторим команду ls, заметим, что теперь пароль не запрашивали, и увидим, чт файл появится. === Незащищенные ключи ===
Line 15: Line 16:
Понятно, что ключом без пароля можн пользоваться только в пределах лок. сети. Поск. этт ключ лежит в файле, и он мжет утеч легче, чем парль. В конце концов, рут той машины взьмёт ваш ключ и зайдёт на уд. машину, где вы рут. Поэтому ключ следует защищать пассфразой. Пароль, ктрым мы защищ. этот ключ эт довольн важный пароль, пск. он позволяет восп. им для логина на всех машинах, где ежит ключ. Желательно, чтобы пассфраза не совп. с парлем. ## (''м-да, хорошо звучит %)'')
Line 17: Line 18:
Запихаем его тоже на уд. машину. Попрбуем залогиниться туда.ю треперь на спрашивает пассфразу. В чём же удбств? Не смотря на то, что кажется, что чем начали, тем и закочили, то сейчас есть удобство, и пароль тут дин: если 10 разных машин, у которых 10 разных паролей, более того, можно на уд. машинах можно вообще убить пароль, чтобы можно было логиниться тодлько по 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
}}}
Line 19: Line 31:
Есть вариант ношения ключа на спец. флешках, есть модуль ссх, который умеет ей пользоваться, и тличие от хранения в файла в том, что ег нельзя считать. Недостаток в том, что часть пргр. реализ. перекладжывается на железку, котрая мжет не поддерж. Заглянем в локальный каталог .ssh:
Line 21: Line 33:
Тем не менее, в каком-то смысле мы всё равно, как начали, так и закончили, на показали конфетку --- беспарольный вход, но всё равно теперь надо вводить пассфразу, которая желательно должна быть круче, чем обычный пароль. {{{
$ ls .ssh
agent id_rsa id_rsa.pub known_hosts known_hosts~
}}}
Line 23: Line 38:
Для того, чтобы много раз пассфразу не хранить, есть ssh-agent, с точки зрения стартовой вы вводите пассфразу один раз, и дальше при ссх сначала ходит к агенту, спрашивает, а нет ли её у него, и всё. Теперь там есть файлы id_rsa и .pub. Стоит обратить внимание на права доступа к этим файлам: публичный ключ доступен всем, закрытый - только владельцу:
Line 25: Line 40:
Он запускается автматом (set| grep SSH), пск. эт всунуто в стартовые скрипты ПСПО, н мжно сделать это руками: ssh-agent/ Если сказать ssh-add -L, т увидим, что сейчас не добавлено ещё ни дного ключа. Дбавим наш ключ: ssha-add .ssh/id-rsa {{{
$ 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~
}}}
Line 27: Line 50:
Зайдём епщё раз. Видим, что пассфразу нас не просили, но при -v увидим, чт она использовалась. Для того, чтобы по ключу можно было соединиться с удаленной машиной, надо добавить открытый ключ в файл authorized_keys на удаленном компьютере.
Изначально данный файл не существует. Необходимо выполнить команду ssh-copy-id, которая есть только дистрибутиве !AltLinux. Это скрипт shell, который создает этот файл в случае его отсутствия и добавляет ключ в файл:
Line 29: Line 53:
Про переброс агнета: можно прделать след. штуку: при переходе на др. машину. Если сказать ssh -A, то при ssh-add мы увидим наш ключ. При заходе на уд. машину можно сказать прт, по которому можно обр. к ссх-агенту. Эт переменная окружения. Это штука потенциально опасная, потому что рут на той машине мжет свершенн спокойно восп. вашим агентом для получ. доступа на те сайты, на которых вы этим агентом пользуетесь. С другой сторны, носить с собой агента удобно, потому что с той машины можно хдить на третью и так далее. {{{
$ 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.
}}}
Line 31: Line 63:
У вас может быть некий дверенный хост, на котором и тлько на ём ледит закрытый ключ. Можно прделать след. штуку: можно зайти по парлю на доверенный хост, запустить здесь агента, сказать там ssh-add, чтобы нало кальной машине приехал оттуда ключ, чтобы с этим ключом ходить. То есть, у вас есть уверенность, чт ПО не модиф, но нет уверенности, что о псле вас не придёт человек и не задампает винчестер и потом не начнёт грубым перебором подбирать пассфразу. Если мы повторим команду ls на удаленном компьютере, то увидим, что файл authorized_keys появился:
Line 33: Line 65:
Отн. ситуаций, когда вы не хотите хранить свй закр. ключ на конкретно этой машине. {{{
$ 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
}}}

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

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

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

{{{
$ 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
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/saj/.ssh/id_rsa type 1
debug1: identity file /home/saj/.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/saj/.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/saj/.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
}}}

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

У вас может быть некий доверенный компьютер, на котором и только на нём храниться закрытый ключ. Можно зайти по паролю на доверенный хост, запустить здесь агента, сказать там ssh-add, чтобы на локальной машине приехал оттуда ключ, чтобы с этим ключом ходить. То есть, у вас есть уверенность, что ПО не модифицировано, но нет уверенности, что после вас не придёт человек и не получит прямым перебором паролей доступ к вашему закрытому ключу (удаление ключа в такой ситуации не является гарантией безопасности) задампает винчестер и потом не начнёт грубым перебором подбирать пассфразу.
Line 43: Line 182:
|| 0 || 1 || 1 || 1 || || 1 || ConstantinYershow, GeorgeTarasov, MaximByshevskiKonopko || || || || 37 || 1 || 1 || 1 || || 1 || GeorgeTarasov + ПетрНикольский, GeorgeTarasov, MaximByshevskiKonopko || || ||

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

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

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

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

$ 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
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/saj/.ssh/id_rsa type 1
debug1: identity file /home/saj/.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/saj/.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/saj/.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

Переброс агента. Если использовать ключ 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 (last edited 2008-10-19 12:15:35 by MaximByshevskiKonopko)