66

До того, как я приступил к своей текущей работе (в малом бизнесе), в моем офисе не было брандмауэра в сети, и буквально ничего не создавалось. Теперь, когда я зарегистрировался как отдельный системный администратор / ИТ-отдел, я делал все возможное, чтобы это изменить. После объяснения моему боссу, насколько мы уязвимы, он позволил мне настроить несколько серверов резервного копирования, один из которых находится у него дома.

Сейчас я пытаюсь настроить все так, чтобы я мог автоматизировать ежедневное резервное копирование. Я планирую использовать rsync через ssh для этого. В целях безопасности, а также для простоты автоматизации я планировал отключить вход по ssh паролю и использовать только проверку ключа rsa. Ну, если у меня установлен пароль RSA, тогда мне все равно придется вводить пароль, и это проблема.

Разве наличие пароля RSA не делает вещи значительно менее безопасными? Я единственный человек в компании, который имеет какое-либо представление о подобных вещах, поэтому я не слишком беспокоюсь о том, что кто-то вызовет терминал на моей машине (который всегда заблокирован, когда я AFK, в любом случае ) и ssh-в один из серверов резервного копирования и нанесение любого ущерба. Я все еще очень, очень плохо знаком с миром системного администрирования, и я впервые делаю что-то подобное, и я не хочу оставлять никаких пробелов в настройке безопасности.

Рассматриваемые здесь компьютеры работают под управлением Ubuntu 10.10, SME Server и OSX 10.6, если это как-то меняет ситуацию.

3 ответа3

82

Как вы знаете, преимущество, которое дает вам фраза-пароль, состоит в том, что если кто-то может прочитать ваш закрытый ключ, он «не сможет» его использовать.

Если кто-то может получить доступ к этому закрытому ключу, вы должны принять как должное, что у него есть доступ (ed)/ скомпрометирован, независимо от того, какие машины настроены с открытым ключом. Такие вещи, как .bash_history или .ssh/ config, только облегчают это, даже если ваш .ssh/ known_hosts запутан.

Отсутствие пароля на вашем ключе не конец света, вот 3 идеи, которые помогут вам защитить себя, несмотря на это. (Biggie является вторым, прочитайте это, если ничего больше)


  1. Не используйте один и тот же ключ на всех машинах и пользователях. Создайте для каждого пользователя на каждой машине (которая должна делать подобные вещи) свою собственную пару ключей. Это позволит вам держать мелкозернистый контроль над тем, что может ssh, где.

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

    Смотрите man ssh и ищите команду = и из =

    Синтаксис выглядит примерно так:

    from="1.2.3.4",command="/path/to/executable argument" ssh-rsa key name

    то есть, всплывающее окно «rsync» там, и только ключ «rsync» может быть вызван вашим ключом, и только с IP-адреса 1.2.3.4. Несколько IP - адреса могут быть , Имена хостов также поддерживаются.

  3. Еще одна вещь, которая приходит на ум, это директива AllowUser в вашем sshd_config

    AllowUsers

    За этим ключевым словом может следовать список шаблонов имен пользователей, разделенных пробелами. Если указано, вход в систему разрешен только для имен пользователей, которые соответствуют одному из шаблонов. '*' а также '?'можно использовать в качестве шаблонов в шаблонах. Допустимы только имена пользователей; числовой идентификатор пользователя не распознается. По умолчанию вход разрешен для всех пользователей. Если шаблон принимает форму USER @ HOST, тогда USER и HOST проверяются отдельно, ограничивая вход в систему определенным пользователям с определенных хостов.

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

4

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

-4

Лично я использую DSA, а не RSA, главным образом потому, что это то, что я всегда использовал, и я знаю, что это «просто работает», но теория, я думаю, та же самая. Вы можете заменить dsa на rsa ниже.

По источнику:

$ ssh-keygen -t dsa

Затем скопируйте содержимое файла .ssh/id_dsa.pub в .ssh/authorized_keys в учетной записи пользователя в месте назначения.

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

Всё ещё ищете ответ? Посмотрите другие вопросы с метками .