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

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

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

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

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

  • ssh-agent: как настроить его, чтобы мой CentOS-сервер запрашивал только парольную фразу?
  • Запуск qsub на кластере через ssh
  • Как сделать скрипт автоматическим для самостоятельного ввода пароля?
  • Использовать git pull через команду ssh invoke
  • Как скопировать файл, который все еще записывается поверх ssh?
  • Ограничить доступ ssh для каждого пользователя на основе условий
  • ssh key_load_public: предупреждение о недопустимом формате
  • количество сеансов 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

    Подсчитайте общее количество подпроцессов (рекурсивно), порожденных командой

    Звук Linux: как это работает и почему мне нужно связать 3 архитектуры для использования JACK?

    Прокладывайте все через VPN, за исключением SSH на порте 22

    Каков самый последний файл журнала в утилите logrotate

    Сколько времени занимает пользователь => переход в режим ядра?

    Применение и привязка всех настроек / двоичных файлов одного пользователя к другому пользователю в Linux

    Синтаксическая ошибка Grep с правильным регулярным выражением

    День недели {0-7} в crontab имеет 8 вариантов, но у нас есть только 7 дней в неделю

    Как объединить опции '-i file' и '-O filename' из wget?

    Есть ли решение perl или awk для этой проблемы?

    GNU parallel и basefile вне pwd?

    Создайте RPM в Windows с помощью Cygwin, но установите на Linux

    Каков правильный подход к уменьшению размера rootfs.cpio?

    Как grep слово из файла и сохранить его в другой существующий файл?

    Как загрузить видеопоток rtmp на Linux?

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