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

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

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

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

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

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 может получить к нему доступ, тогда может быть что-то другое, которому удалось получить тот же доступ. Это то, или отказаться от удобства без присмотра.

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

  • Как использовать sed для замены строки, используя номер строки на удаленной машине, используя ssh?
  • Как использовать SSH для перемещения файла из Ubuntu в Windows?
  • Разрешить постоянным пользователям SSH использовать закрытый ключ, который они не могут прочитать.
  • используя часы с ssh
  • Как временно переключиться с ssh на локальную оболочку?
  • Указание исходящего интерфейса для туннеля SSH
  • перезапустить X11 / Xwindows без отключения сеанса ssh
  • Загрузите файл с удаленной машины, а SSH'd в него?
  • Порт открыт, но я не могу ssh к нему
  • ssh_config: добавить раздел хоста, который соответствует IP-адресам, даже при подключении через имя хоста
  • Ограничить вход SSH в локальную сеть: подключение VPN не разрешено
  • Автозаполнение и раскраска не работают, при использовании ssh в оболочке emacs
  • Linux и Unix - лучшая ОС в мире.