LINUX.ORG.RU
ФорумAdmin

Авторизация по ssh

 , ,


0

3

Доброго времени суток. Почитал про преимущества авторизации на SSH по ключу и решил сделать себе также. Вот только в некоторых моментах запутался.

  • Правильнее делать публичный ключ для root пользователя? Я сделал для root, и подключаюсь по ssh root@somedomain.xx. Однако в гайдах почему то люди использовали ту же учётку что и на десктопе.

    Если я создам на сервере учётку faiwer и запишу в нём мой публичный ключ, а затем буду авторизовываться по ssh faiwer@somedomain.xx, то мне для всех административных действий (а других я там и не провожу) придётся указывать sudo, или переключаться на root-а, а при этом придётся вводить пароль (зачем тогда вообще суетиться).

    Если же правильнее подключаться ssh root@..., то как быть если «админов» несколько. Я могу беспрепятственно указать много ключей в authorized_keys для разных декстоп-учёток? Судя по key"s" могу.

    В общем запутался.

  • Кодовая фраза нужна только на случай если мой кот решит хакнуть сервер через мой же ПК, или без его указания есть риск взлома извне?

1) не работай от рута. тем более не подключайся к нему извне

2) кодовая фраза спасает при утечке приватного ключа

derlafff ★★★★★ ()
Ответ на: комментарий от derlafff

1. 99.5% команд, прописываемых мною на сервере требует привелегии суперпользователя. Всегда писать sudo? о_Щ 2. Т.е. без доступа к приватному ключу я ничем не рискую?

faiwer ()
Ответ на: комментарий от faiwer

1. 99.5% команд, прописываемых мною на сервере требует привелегии суперпользователя. Всегда писать sudo? о_Щ

sudo -i
Deleted ()
Ответ на: комментарий от Deleted

mironov_ivan, ну дык я про это тоже отписал. Там же придётся снова вводить пароль (я правда не знаю - своей учётки или рутовской).

faiwer ()

1. аутентификация

2. судо

leave ★★★★★ ()
Ответ на: комментарий от Deleted

В общем пришёл к такой схеме:

ssh faiwer@domain
sudo -i
# enter faiwer password
# => root

Теперь всё правильно?

faiwer ()
Ответ на: комментарий от shell-script

Я тут подумал. Логично поставить себе не сильно сложный пароль (для удобства) на сервере и запретить авторизацию не по ключу. Тогда получается что серверный пароль понадобится для защиты уже открытой консоли с ssh, а ключ перебором не возьмёшь. Вроде всё круто и безопасно.

Однако возникает дилемма, что делать если секретный ключ потерялся (сгорел винт, нашествие динозавров, дебилизм и т.д.) или потребовался доступ вне ПК с ключом. Можно конечно держать в запороленном архиве на почте и пр. подобные варианты. Но всё равно это «не то». Можно ли запретить авторизацию по паролю конкретному пользователю(ям) и оставить root-у?

faiwer ()
Ответ на: комментарий от ptah_alexs

ptah_alexs, а как тогда решить проблему с ключём? Таскать с собой на флешке или хранить в запароленом виде в сети? :)

faiwer ()

можно вообще выкинуть sudo и в /etc/pam.d/su заглянуть.

auth	sufficient	pam_wheel.so trust use_uid
auth	required	pam_wheel.so use_uid
auth	sufficient   pam_listfile.so item=ruser sense=allow onerr=fail file=/etc/security/suauth.nopass
выбирай, что нравится.

lnx ()
Ответ на: комментарий от faiwer

Зачем такие сложности?

Настраивается авторизация по ключу для пользователя. Для этого же пользователя в sudo прописываются те несколько административных команд, которые нужны с опцией беспарольным доступом и всё.

Далее ssh user@host sudo rm -rf ./* и всё рабоатет автоматом. Если ключ потерян, заходим по паролю, делаем новый. Если ключ угнали, у злодея нет возможности посмотреть в /etc/sudoerc и узнать, что какие-то команды разрешены, поэтому есть некоторый запас времени, чтобы сменить угнанный ключ. Ну, это самый простой вариант. Настраивается в пять минут. Всяко безопаснее, чем открытый root по ssh.

shell-script ★★★★★ ()
Ответ на: комментарий от faiwer

Что-то совсем неясна задача получается.

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

shell-script ★★★★★ ()
Ответ на: комментарий от shell-script

С других компов ведь можно как обычно по паролю заходить

Ну так люди пишут что это не кошерно, а для рута так вообще критично.

faiwer ()
Ответ на: комментарий от faiwer

Чего-чего? Рутом по ssh - это вообще глупо. А вот что такого некошерного в авторизации по паролю с других компов, не знаю. Разумеется, пароль должен быть не 123456. От стандартных ботов можно ещё перевесить ssh на другой порт и настроить бан после n неудачных попыток. А для параноиков есть ещё целая куча рецептов, только надо ли оно?

shell-script ★★★★★ ()

Правильнее делать публичный ключ для root пользователя?

Только если система однопользовательская, то есть ее админишь только ты, тогда для удобства можно в ~/.ssh/authorized_keys прописать свой публичный ключ.

Если же правильнее подключаться ssh root@..., то как быть если «админов» несколько. Я могу беспрепятственно указать много ключей в authorized_keys для разных декстоп-учёток? Судя по key"s" могу.

То как только тебя поломают( например сбрутят пароль рута, ведь он один), то хакер просто добавит свой ключ и тебе придется отслеживать кто, когда и зачем заходил на твой сервер.

Кодовая фраза нужна только на случай если мой кот решит хакнуть сервер через мой же ПК, или без его указания есть риск взлома извне?

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

Marchael ()
Ответ на: комментарий от Marchael

Marchael, спасибо. Задумался. Теперь у меня вырисовывается такая схема:

  • авторизацию по паролю оставляю
  • своей учётке ставлю сложный пароль
  • настраиваю sudo так, чтобы не надо было вводить пароль для sudo -i
  • авторизуюсь по ключу

Что я получаю:

  • нет нужды запоминать пароли
  • вроде безопасно, если не подпускать к уже открытой ssh-консоли пьяных админов
  • можно потерять свой ключ и зайти под паролем

Теперь всё ок? :)

faiwer ()
Ответ на: комментарий от faiwer

своей учётке ставлю сложный пароль

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

настраиваю sudo так, чтобы не надо было вводить пароль для sudo -i

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

нет нужды запоминать пароли

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

Marchael ()
Ответ на: комментарий от Marchael

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

В таком случае от меня ускользает сам смысл использования ключей, при доступной авторизации по паролю. В чём выигрыш?

faiwer ()
Ответ на: комментарий от shell-script

у злодея нет возможности посмотреть в /etc/sudoerc и узнать, что какие-то команды разрешены,

блажен кто верует

$ sudo -l
Matching Defaults entries for sergey on this host:
    env_reset,
    secure_path=/usr/local/sbin\:/usr/local/bin\:/usr/sbin\:/usr/bin\:/sbin\:/bin

User sergey may run the following commands on this host:
    (ALL) ALL, (ALL) NOPASSWD: /usr/bin/apt-get update, 
    (ALL) /usr/bin/apt-get upgrade,
    (skype) NOPASSWD: /usr/local/bin/skype.sh

sdio ★★★★★ ()
Ответ на: комментарий от faiwer

Почитал про преимущества авторизации на SSH по ключу и решил сделать себе также.

В таком случае от меня ускользает сам смысл использования ключей

Так что ты там прочитал про «реимущества авторизации на SSH по ключу»?

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

sdio ★★★★★ ()
Ответ на: комментарий от sdio

Ух ты. Давненько я маны не читал. Спасибо, что ткнул носом.

shell-script ★★★★★ ()
Ответ на: комментарий от faiwer

В таком случае от меня ускользает сам смысл использования ключей, при доступной авторизации по паролю. В чём выигрыш?

Основной и главный смысл этой идеи - повысить безопасность, а не удобство.

И на мой взгляд слова «удобство» и «безопасность» по сути антонимы.

Но удобно это стало потому, что существуют различные key-chain менеджеры для ssh ключей(типа pinetry под xfce), благодаря которым ты можешь вводить ключ 1 раз за сессию, а так же настройкой sudo(например, в debian или ubuntu, после первой успешной авторизации, sudo не запрашивает пароль в течение какого-то промежутка времени)

Marchael ()

Я сделал для root, и подключаюсь

После инстала сразу делаю sudo passwd -l root.

vahtu ()
Вы не можете добавлять комментарии в эту тему. Тема перемещена в архив.