Почему права доступа к ssh-файлу строгие

За эти годы мне пришлось генерировать и использовать много ключей ssh. Некоторые из вещей, которые всегда должны быть выполнены: ~/.ssh должен быть 0700, а ~/.ssh / authorized_keys должен быть 0600, а затем закрытые ключи, используемые для входа на сервер, всегда должны быть 0600. Я знаю, что ssh обеспечивает соблюдение этих разрешений, но я хотел знать причину, по которой небезопасно иметь следующее (да, я звоню белым шляпам, черным шляпам и всем остальным, чтобы получить этот ответ).

  • ~/.ssh / = 0755
  • ~/.ssh / authorized_keys = 0644
  • ~/.ssh / id_rsa = 644 (или любой закрытый ключ)
Источник

3 ответа

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

Помните о принципах безопасности, предоставляйте только абсолютную минимальную информацию (если таковая имеется), необходимую внешней стороне для выполнения задачи. Разработанный набор разрешений делает это. И ssh разработан, чтобы быть надежным программным обеспечением безопасности.

Источник

Традиционно серверы Unix и Linux предназначены для многопользовательских систем. Из-за использования криптографии с открытым / закрытым ключом становится важным сохранять секретность закрытого ключа. Значения разрешений восьмеричного файла описаны @gregory в его ответе и более полно описаны на странице Википедии Unix Modes. Остальная часть моего ответа будет сосредоточена на том, что, как вам кажется, вас заинтересует, и каковы потенциальные последствия наличия слабых разрешений для вашего ~/.ssh каталог и основные файлы.

Обоснование разрешений sshd обеспечивает, когда StrictModes находится на:

  • ~/.ssh/ знак равно 0700:
    • Целиком ~/.ssh/ каталог содержит файлы, которые должны быть прочитаны пользователем, работающим ssh и написано в случае ~/.ssh/config,
    • Он также содержит файлы, которыми злоумышленник может злоупотреблять, имея возможность читать или писать. Слабые разрешения, которые вы упоминаете 0755 для этого каталога вместе с остальными (~/.ssh/id_rsa = 0644, ~/.ssh/authorized_keys = 0644) потенциально может допустить много злоупотреблений. Например:
      • Злоумышленник может украсть ~/.ssh/id_rsaили другие закрытые ключи в этом каталоге, позволяющие им входить на любой хост, на который целевой пользователь авторизован для SSH. Вот почему ~/.ssh/id_rsa = 0644 это плохо, и это самый очевидный низко висящий фрукт, который атакующий будет искать первым.
      • Злоумышленник может добавить свой открытый ключ к ~/.ssh/authorized_keys, который предоставил бы этому пользователю доступ к SSH на хост и маскировал под этого пользователя. Если целевой пользователь находится в /etc/sudoers и с включенным sudo без пароля, то это становится атакой повышения привилегий.
        Разрешения, которые вы упоминаете ~/.ssh/authorized_keys = 0644 технически не допустит этого, но вот почему sshd "s StrictModes on Настройка обеспечивает строгие разрешения для этого файла. Позволять другим пользователям писать в этот файл плохо, читать не так плохо, потому что технически открытый ключ не должен оставаться секретным.
      • Злоумышленник может изменить ~/.ssh/known_hosts переопределить открытый ключ удаленного хоста тем, которым они владеют, а затем выполнить атаку с отравлением кэша DNS, чтобы перенаправить имя хоста на принадлежащий им IP-адрес. Это в основном человек в средней атаке, перенаправляющий пользователя на его вредоносный хост, когда пользователь входит в систему на этом хосте.
      • Злоумышленник может изменить настройки в ~/.ssh/config выключить StrictHostKeyChecking чтобы облегчить вышеуказанную атаку MitM.
      • Злоумышленник может выполнить обе вышеуказанные атаки MitM, а затем установить ForwardAgent yes и взломать файл сокета SSH целевого пользователя. Когда целевой пользователь входит на хост MitM злоумышленника, злоумышленник изменяет права доступа к файлу сокета агента SSH, а затем использует агент SSH удаленного пользователя (содержащий его закрытые ключи) для входа на другие хосты, для которых целевой пользователь авторизован для SSH. в.
    • Если версия SSH старая, злоумышленник может прочитать открытый текст старого стиля ~/.ssh/known_hosts, чтобы получить информацию о том, к каким хостам целевой пользователь имеет доступ.
    • Следовательно, биты разрешения 0700 обеспечить следующее:
    • 7 Чтение, запись и выполнение битов, установленных для пользователя, позволяют:
      • Пользователь может создавать, переименовывать или удалять файлы в каталоге и изменять атрибуты каталога.
        Таким образом, пользователь может создавать и записывать в свой конфигурационный файл SSH, управлять своими ~/.ssh/authorized_keys файл и т.д...
      • Бит чтения позволяет пользователю перечислять файлы в каталоге.
        Очевидно, что пользователю, владеющему каталогом, это необходимо для управления файлами внутри.
      • Бит выполнения позволяет пользователю войти в каталог и получить доступ к файлам и каталогам внутри.
        Опять же, это очевидно и необходимо для пользователя, чтобы управлять своими ~/.ssh/ каталог.
    • 0: Нет разрешений для пользователей каталога group а также other пользователи гарантируют, что ни один из вышеупомянутых переходов не разрешен, по крайней мере, на уровне каталога.
  • ~/.ssh/authorized_keys знак равно 0600:
    • Как уже упоминалось выше, важно, чтобы этот файл принадлежал истинному владельцу, и чтобы никакой другой пользователь не мог писать в этот файл.
    • Злоумышленник может изменить этот файл, чтобы изменить параметры (да, в этом файле есть нечто большее, чем просто список открытых ключей), используемый для этого ключа, когда пользователь подключается к целевой системе.
    • Злоумышленник может изменить этот файл, чтобы изменить command возможность запуска команды от имени пользователя при входе в систему. Это можно рассматривать как локальное повышение привилегий или локальное выполнение команды для маскировки под этого пользователя.
  • ~/.ssh/id_rsa знак равно 0600 (или любой закрытый ключ)
    • Также упомянуто выше, важно, чтобы любые файлы с закрытым ключом принадлежали истинному владельцу, и чтобы никакой другой пользователь не мог читать или записывать их.
    • Злоумышленник может вызвать DoS и помешать целевому пользователю войти в систему на серверах, если они могут перезаписать файлы закрытого ключа.
    • Как упоминалось выше, злоумышленник может прочитать файлы с закрытым ключом для использования в качестве метода аутентификации для других хостов, к которым у целевого пользователя есть доступ.
Источник

Права доступа к файлам Linux могут быть выражены в виде трехзначного числа. Каждая из цифр представляет: Owner, Group, Others,

Digit |  Permissions
------------------------------
0     |  None
1     |  Execute
2     |  Write
3     |  Write and Execute
4     |  Read
5     |  Read and Execute
6     |  Read and Write
7     |  Read, Write and Execute

С 755, вы бы дали всем права на чтение и выполнение. С 644, вы бы дали разрешение на чтение для всех.

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

Источник
Другие вопросы по тегам