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

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

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

  • ошибка при подключении удаленного сервера с помощью ssh
  • SSH. Возможно ли, чтобы сеанс SSH полностью контролировал клиента?
  • Убить tcpdump процесс, порожденный ssh, когда ssh умирает
  • Почему crontab не хранится в домашних каталогах пользователей?
  • Добавить одноразовую запланированную задачу через сценарий оболочки?
  • Порядок выполнения с несколькими командами
  • Я увидел еще одну статью, в которой кто-то просто пропустил кодовую фразу, чтобы cron мог легко использовать ключ для входа в систему, но это не кажется правильным, но это нормально делать на практике? Я имею в виду, что если кто-то завладеет этим ключевым файлом, они смогут нанести ущерб машине, которая будет подкреплена.

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

  • `ssh-agent` запрашивает парольную фразу после ее добавления
  • Опасности использования команды rm с переменными
  • Как интерпретировать символ в строке, переданной через SSH
  • ssh висит тогда тайм-аут
  • Экспортируемые переменные внутри сеанса ssh пусты
  • Возможно ли обходить ретранслятор 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 может получить к нему доступ, тогда может быть что-то другое, которому удалось получить тот же доступ. Это то, или отказаться от удобства без присмотра.

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

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