Должен ли ключ для автоматического запуска задания cron, который выполняется поверх ssh, не имеет ключевой фразы?

Я читаю статью в Master Linux Now 2013 под названием OpenSSH: Easy Logins и она использует ssh-agent чтобы вы могли вводить ключевую фразу для своего ключа один раз, а затем вы можете свободно подключиться к удаленной машине, не набрав ее снова во время работы ssh-agent.

Причина, по которой я был привлечен к статье, в первую очередь, за исключением того, что мне не нужно повторно вводить мой пароль миллион раз; было так, что я мог делать автоматические резервные копии с / на удаленные компьютеры, вызывая rsync из cron на удаленной машине на сервер по ssh;

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

Мне кажется, было бы безопаснее следить за тем, чтобы пользователь вошел в систему при перезагрузке и чтобы они вводили парольную фразу один раз, когда они вошли в систему, чтобы запустить агент, а затем просто ждать выполнения задания cron с заблокированным экраном; но я, вероятно, что-то пропустил здесь, например, о том, с какими пользовательскими или пользовательскими типами выполняются задания cron.

  • Неважно, какой компьютер (хост или клиент) я генерирую пару ключей SSH?
  • Какова цель группы «ssh»?
  • Если ssh-add будет тихим, если ключ уже есть
  • Могу ли я перенаправить существующий (полный) сеанс gnome-сессии на удаленную рабочую станцию?
  • Как задать вопрос пользователям при входе в систему?
  • Сессия экрана не работает при отсоединении
  • Как начать два процесса, поддерживаемых свиньями? Итак, первый заканчивается, когда второй заканчивается?
  • SSH продолжает пропускать свой паб и запрашивать пароль
  • One Solution collect form web for “Должен ли ключ для автоматического запуска задания cron, который выполняется поверх ssh, не имеет ключевой фразы?”

    Ограничьте команды, которые могут быть вызваны ключом

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

    Используйте что-то вроде этого в ~/.ssh/authhrized_keys :

     command="/usr/sbin/the-backup-daemon" ssh-rsa AAAAAAAAAAAAXXXXXX..... 

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

    Вы также можете ограничить IP-адреса, разрешенные для подключения с помощью этого ключа, и отключить множество других функций SSH, таких как переадресация портов для соединений, в которых используется этот ключ:

     from="10.1.2.3",no-port-forwarding,no-X11-forwarding,no-agent-forwarding,no-pty,command="/usr/sbin/the-backup-daemon" ssh-rsa AAAAAAAAAAAAXXXXXX..... 

    Все, что должно идти по одной строке в ~/.ssh/authorized_keys .

    Защита ключа

    Это зависит от вашей модели угрозы.

    Если вы беспокоитесь о том, что ключ был украден во время «холодного», например, если компьютер, на котором он был сохранен, физически украден, вы не захотите его сохранить без кодовой фразы в этом месте.

    Вы можете запустить своего рода базовый SSH-агент вручную после загрузки сервера, добавить ключ к этому агенту и записать $SSH_AUTH_SOCK для будущего использования заданием cron, но, честно говоря, это звучит как больше проблем, чем того стоит. Вы можете просто сохранить незашифрованный ключ в файловой системе tmpfs и получить доступ к работе cron оттуда. В любом случае ключ живет только в памяти (если у вас нет свопа или зашифрованного свопа). Конечно, вы должны chown и chmod файл, так что только целевой пользователь может получить к нему доступ.

    Опять же, если вы беспокоитесь об этом, вы, вероятно, уже создали этот компьютер с зашифрованной корневой файловой системой и swap (например, luks), поэтому вам может и не нужно беспокоиться об этом как таковом.

    Если вы беспокоитесь о том, что ключ был украден во время «горячего» (загружен в память), вы вряд ли сможете это сделать. Если задание cron может получить к нему доступ, тогда может быть что-то другое, которому удалось получить тот же доступ. Это то, или отказаться от удобства без присмотра.

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

    Interesting Posts

    Разрешения чтения / записи для демона, выполняемого как не root

    Нажмите кнопку html через скрипт оболочки?

    Окно обмена между рабочими пространствами в Xmonad

    Как получить доступ к рейд-разделам после отказа контроллера

    Связывание переменной с конкретным для файла цикла

    Сколько места мне нужно для установки Fedora 23 Gnome (в корне косой черты)

    Как разблокировать ключи в рыбе?

    как показать общий размер файлов в папке путем фильтрации расширения без отображения каждого размера файла

    Как выполнить удаленную команду для существующей сессии ssh

    Расширение поиска истории в zsh

    Двойная загрузка Linux Mint в жестком диске стиля GPT вместе с Windows 8

    Использование переменной для выполнения команды curl

    Что использовать для тестирования брандмауэра (порт открыт или нет)

    Использование ip addr вместо ifconfig отчетов «RTNETLINK ответы: файл существует» в Debian

    Можете ли вы запустить функцию в фоновом режиме?

    Linux и Unix - лучшая ОС в мире.