Различия между версиями 5 и 6
Версия 5 от 2008-09-08 21:41:42
Размер: 10188
Редактор: DmitryChistikov
Комментарий: попытка восстановить справедливость
Версия 6 от 2008-10-07 22:40:11
Размер: 10781
Комментарий:
Удаления помечены так. Добавления помечены так.
Строка 3: Строка 3:
Как видно, при каждой передаче информации нам приходится вводить пароль. В чем здесь может таиться опасность? Будучи ответственным за безопасность данных, администратор обязан принимать во внимание тот факт, что пароль может быть подсмотрен во время набора, или попросту подобран. В любом случае, каждый набор пользователем пароля --- лишнее беспокойство для администратора. Как видно, при каждой передаче информации нам приходится вводить пароль. В чем здесь может таиться опасность? Будучи ответственным за безопасность данных, администратор обязан принимать во внимание тот факт, что пароль может быть подсмотрен во время набора, или попросту подобран. Каждый набор пользователем пароля --- лишнее беспокойство для администратора.
Строка 5: Строка 5:
Что касается огина руту, ... Вобще логиниться рутом это вообще неопр. штука. Вы как адм. читаете лги и видите, что кто-т логинился рутом и чт-то там понаделал, поэтому даже локальн не реком. логиниться рутом и что-т там понаделал. Исходя из вышесказанного, стоит добавить, что пользоваться по ssh учетной записью суперпользователя --- небезопасно. Среди прочего, root может с помощью специальной команды (''скрипт'') посмотреть список выполненных команд любого пользователя.
Строка 7: Строка 7:
Есть альтернативный способ. До этого мы имели дело только с ключами со стороны хоста. Но пользователь имеет право обладать собственным ssh-ключом и раздавать открытые ключи, чтобы система аутентификации хоста могла затем просмотреть список имеющихся у нее ключей, найти его и убедиться в подлинности запрашивающего клиента. Есть альтернативный способ. До этого мы имели дело только с ключами со стороны хоста. Но пользователь имеет право обладать собственным ssh-ключом (закрытый и открытый) и раздавать открытые ключи, чтобы система аутентификации хоста могла затем просмотреть список имеющихся у нее ключей, найти его и убедиться в подлинности запрашивающего клиента.
Строка 9: Строка 9:
Утечка ключей возможна и здесь, но ключи не передаются и не набираются вручную. Разумеется, утеря носителя с ключом равносильна открытому разглашению ключа, но его можно, скажем, зашифровать под пароль. Попробуем сгенерировать ssh-ключ. Утечка ключей возможна и здесь, но ключи не передаются и не набираются вручную. Разумеется, утеря носителя с ключом равносильна открытому разглашению ключа, но ключи можно защищать.

(''за
головок типа "Без парольной фразы"'')

Попробуем сгенерировать ssh-ключ. (''скрипт!!'')
Строка 13: Строка 17:
Изначально данный файл не существует. Необходимо выполнить команду ssh-copy-id, которая есть только дистрибутиве AltLinux. Это скрипт shell, который занимается именно тем, о чем мы только что говорили - добавляет ключ в файл, в том числе и создает этот файл в случае его отсутствия. Если мы повторим команду ls, то увидим, что authorized_keys появился. Изначально данный файл не существует. Необходимо выполнить команду ssh-copy-id (''скрипт'') , которая есть только дистрибутиве AltLinux. Это скрипт shell, который занимается именно тем, о чем мы только что говорили - создает этот файл в случае его отсутствия и добавляет ключ в файл. Если мы повторим команду ls, то увидим, что файл authorized_keys появился.
Строка 15: Строка 19:
Очевидно, что ключом без пароля можно пользоваться только в пределах локальной сети, поскольку он хранится в файле и может "утечь" легче, чем набираемый пароль. В примеру, любой, кто имеет права суперпользователя на машине, где вы его храните, может просто найти и взять ваш ключ и воспользоваться им. Поэтому ключ следует защищать пассфразой. Пароль, которым мы защищаем ключ, очень ценен, так как он позволяет воспользоваться вашим логином на всех машинах, на которых этот ключ хранится. Потому желательно, чтобы пассфраза не совпадала с паролем. (''заголовок типа: "с пассфразой"'')
Строка 17: Строка 21:
Поместим теперь и пароль на удаленную машину и попробуем туда войти. Видно, что теперь у нас спрашивают пассфразу. Вопрос: в чём же удобство? Несмотря на ощущение, что мы вернулись к тому, с чего начали, то сейчас есть удобство, и пароль тут дин: если 10 разных машин, у которых 10 разных паролей, более того, можно на уд. машинах можно вообще убить пароль, чтобы можно было логиниться тодлько по ssh. Ещё дин бонус --- пассфраза не передаётся по сети. Есть один сущ. недстаток --- если машина, за которой вы сидите небезопасна, и там кейлоггер, то утекает горазд больше, чем огин и пароль до конкретной машины. Очевидно, что ключом без пароля можно пользоваться только в пределах локальной сети, поскольку он хранится в файле и может "утечь" легче, чем набираемый пароль. К примеру, любой, кто имеет права суперпользователя на машине, где вы его храните, может найти ваш ключ и воспользоваться им. Поэтому ключ следует защищать пассфразой. Пароль, которым мы защищаем ключ, очень ценен, так как он позволяет воспользоваться вашим логином на всех машинах, на которых этот ключ хранится. Потому желательно, чтобы пассфраза не совпадала с паролем.
Строка 19: Строка 23:
Поместим теперь и пароль на удаленную машину и попробуем туда войти. Видно, что теперь у нас спрашивают пассфразу. Вопрос: в чём же удобство? Несмотря на ощущение, что мы вернулись к тому, с чего начали, то сейчас есть удобство, и пароль тут один: если 10 разных машин, у которых 10 разных паролей, более того, можно на удаленных машинах можно вообще убить пароль, чтобы можно было логиниться только по ssh. Ещё один бонус --- пассфраза не передаётся по сети. Есть один существенный недостаток --- если машина, за которой вы сидите, небезопасна, и там кейлоггер, то утекает гораздо больше, чем логин и пароль до конкретной машины.
Строка 20: Строка 25:
Есть вариант ношения ключа на спец. флешках, есть модуль ссх, который умеет ей пользоваться, и тличие от хранения в файла в том, что ег нельзя считать. Недостаток в том, что часть пргр. реализ. перекладжывается на железку, котрая мжет не поддерж. Есть вариант ношения ключа на специальных флешках, есть модуль ssh, который умеет ей пользоваться, и отличие от хранения в файле в том, что его нельзя считать. Недостаток в том, что часть программной реализации перекладывается на железку, которая может не поддерживаться.
Строка 22: Строка 27:
Тем не менее, в каком-то смысле мы всё равно, как начали, так и закончили, на показали конфетку --- беспарольный вход, но всё равно теперь надо вводить пассфразу, которая желательно должна быть круче, чем обычный пароль. Тем не менее, в каком-то смысле мы всё равно, как начали, так и закончили, на показали конфетку --- беспарольный вход, но всё равно теперь надо вводить пассфразу, которая в идеале должна быть более криптостойкой, чем обычный пароль.
Строка 24: Строка 29:
Для того, чтобы много раз пассфразу не хранить, есть ssh-agent, с точки зрения стартовой вы вводите пассфразу один раз, и дальше при ссх сначала ходит к агенту, спрашивает, а нет ли её у него, и всё. ==== Ssh-агент ====
Строка 26: Строка 31:
Он запускается автматом (set| grep SSH), пск. эт всунуто в стартовые скрипты ПСПО, н мжно сделать это руками: ssh-agent/ Если сказать ssh-add -L, т увидим, что сейчас не добавлено ещё ни дного ключа. Дбавим наш ключ: ssha-add .ssh/id-rsa Для того, чтобы много раз пассфразу не хранить, есть ssh-agent, с точки зрения стартовой вы вводите пассфразу один раз, и дальше при ssh сначала ходит к агенту, спрашивает, а нет ли её у него, и всё.
Строка 28: Строка 33:
Зайдём епщё раз. Видим, что пассфразу нас не просили, но при -v увидим, чт она использовалась. Он запускается автоматом (set| grep SSH), поскольку это входит в стартовые сценарии ПСПО, но при необходимости можно сделать это руками:
Строка 30: Строка 35:
Про переброс агнета: можно прделать след. штуку: при переходе на др. машину. Если сказать ssh -A, то при ssh-add мы увидим наш ключ. При заходе на уд. машину можно сказать прт, по которому можно обр. к ссх-агенту. Эт переменная окружения. Это штука потенциально опасная, потому что рут на той машине мжет свершенн спокойно восп. вашим агентом для получ. доступа на те сайты, на которых вы этим агентом пользуетесь. С другой сторны, носить с собой агента удобно, потому что с той машины можно хдить на третью и так далее. {{{
ssh-agent
}}}
Строка 32: Строка 39:
У вас может быть некий дверенный хост, на котором и тлько на ём ледит закрытый ключ. Можно прделать след. штуку: можно зайти по парлю на доверенный хост, запустить здесь агента, сказать там ssh-add, чтобы нало кальной машине приехал оттуда ключ, чтобы с этим ключом ходить. То есть, у вас есть уверенность, чт ПО не модиф, но нет уверенности, что о псле вас не придёт человек и не задампает винчестер и потом не начнёт грубым перебором подбирать пассфразу. По умолчанию ssh-агент не хранит никаких ключей, в этом можно убедиться с помощью ssh-add -L
Строка 34: Строка 41:
Отн. ситуаций, когда вы не хотите хранить свй закр. ключ на конкретно этой машине. Добавим наш ключ: ssha-add .ssh/id-rsa (''скрипт'')

Зайдём ещё раз. Видим, что пассфразу нас не просили, но при -v увидим, что она использовалась.

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

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

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

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

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

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

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

(заголовок типа "Без парольной фразы")

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

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

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

(заголовок типа: "с пассфразой")

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

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

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

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

Ssh-агент

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

Он запускается автоматом (set| grep SSH), поскольку это входит в стартовые сценарии ПСПО, но при необходимости можно сделать это руками:

ssh-agent

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

Добавим наш ключ: ssha-add .ssh/id-rsa (скрипт)

Зайдём ещё раз. Видим, что пассфразу нас не просили, но при -v увидим, что она использовалась.

Про переброс агента: можно проделать следующую штуку: при переходе на другую машину (скрипт?). Если сказать 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)