Почему пользователю 'мусорного ведра' нужна оболочка входа в систему?
Для упрощения установки можно настроить файл конфигурации SSH, который расположен в ~/.ssh/config. Добавьте запись в файл как:
Host server
User l33t
HostName server.example.org
Директива HostName является дополнительной, если она соответствует имени, данному в Хосте. Это - в основном псевдоним к вводу l33t@server.example.org. Вы могли сделать имя как короткий a s в строке Хоста, если Вы хотите избежать большого ввода. Можно также проигнорировать Линию пользователя, когда удаленное имя пользователя совпадает с локальным именем пользователя. С вышеупомянутой конфигурацией все, что необходимо ввести, ssh server, scp file-to-copy server:, и так далее.
OpenSSH не поддерживает пароли хранения, так как это обычно - плохая идея, но он предлагает более безопасную альтернативу, названную аутентификацией с открытым ключом. С открытыми ключами можно войти в систему несколько серверов автоматически, даже если каждый сервер имеет различный пароль. Открытые ключи используют закрытый ключ, который обычно хранится на диске с паролем. Этот пароль является использованием для загрузки закрытого ключа, который затем используется для аутентификации к удаленному серверу. Чтобы постараться не вводить в пароле для закрытого ключа все время, закрытый ключ может быть загружен в Агент С открытым ключом SSH такой как ssh-agent или Брелок для ключей GNOME. В то время как агент работает с загруженным закрытым ключом, можно пройти проверку подлинности к любому серверу автоматически без необходимого пароля. Можно также сохранить закрытый ключ к диску без пароля, но это менее безопасно и эквивалентно хранению незашифрованного пароля к диску. Смотрите на установку ssh открытый ключ.
Пользователь, у которого есть допустимая оболочка и никакой пароль, может все еще войти в систему non-password-based методами, наиболее распространенное существо ssh ключ. Допустимая оболочка необходима для выполнения заданий крона. Допустимая оболочка также необходима для su bin -c 'wibble' работать (над Linux, по крайней мере, su bin -s /bin/sh -c 'wibble' будет также работать).
В случае bin, большинство систем никогда не выполняет команду как bin в нормальном функционировании, таким образом устанавливая оболочку на /bin/false был бы в порядке.
Нет никакого риска никакого разрешения для прямого поражения цели bin входить в систему по SSH, потому что это потребовало бы создания /bin/.ssh/authorized_keys как пользователь bin или как корень. Другими словами, единственный способ войти состоит в том, чтобы быть в. Однако наличие допустимой оболочки действительно увеличивает риск неверной конфигурации. Это может также разрешить некоторые удаленные нападения с сервисами кроме SSH; например, пользователь сообщает, что взломщик мог установить пароль для daemon удаленно через Samba, затем используйте тот пароль для входа в систему по SSH.
Можно заткнуть дыру SSH путем списка имен пользователей системы в a DenyUsers директива в /etc/ssh/sshd_config (к сожалению, Вы не можете использовать числовой диапазон). Или с другой стороны можно поместить AllowGroups директива и только разрешает группы, которые содержат физических пользователей (например. users если Вы предоставляете всем Вашим физическим пользователям тот состав группы).
Существуют ошибки, зарегистрированные по этой проблеме в Debian (#274229, № 330882, № 581899), в настоящее время открываются и классифицированный как “список пожеланий”. Я склонен соглашаться, что это ошибки, и пользователи системы должны иметь /bin/false как их оболочка, если не кажется необходимым сделать иначе.
Вы не должны волноваться о тех как пользователи. Они - "пользователи" в смысле групп безопасности, не пользователи в смысле "входа в систему и использования" люди. Если Вы посмотрите в "/etc/shadow", то Вы будете видеть, что у всех этих "пользователей" нет паролей (или "x" или"!" вместо длинного соленого хеша). Это означает, что эти пользователи не могут войти в систему, несмотря ни на что.
Тем не менее я не знаю - ли это хорошая идея изменить "/bin/sh" на "/bin/false" для всех этих пользователей. Поскольку программы работают под этими группами, это не могло бы позволить им выполнять команды, что они должны. Я оставил бы их как "/bin/sh".
Нет никакой потребности в Вас волноваться об этих пользователях. Только беспокойство о пользователях Вы создаете (и с хешами в "/etc/shadow")
-
1ни о каком хеше в
/etc/shadow, но если услуга работает как пользователь, для кого-то теоретически возможно вставитьsshвойти в ключ, нет? – Mike Pennington 11.01.2012, 23:53 -
2Только если они уже были зарегистрированы в Вашу учетную запись с полномочиями пользователя root..., в этом случае, эти пользователи являются наименьшим количеством Вашего :-P – Chris 11.01.2012, 23:55
-
3забот, я не уверен, что соглашаюсь со всеми ограничениями, которые Вы просто перечислили. Если это было верно, то открывается
rpcdпорты не были бы проблемой; однако, я лично засвидетельствовал результаты удаленного использования на старой машине Соляриса, где взломщик получил доступ черезrpcиспользование на поле.rhostsбыл включен и перезаписываем этимrpcпользователь (не может больше помнить специфические особенности..., это было несколько лет назад)... Аналогично, если они могут сделать~/.ssh/authorized_keysдля пользователя, который мог войти в систему, затем это все еще походит на риск (даже без пароля в/etc/shadow) – Mike Pennington 12.01.2012, 00:01 -
4Да, но то использование не было через SSH. Программы обычно работают при их собственном пользователе (как Вы сказали). Использование в программе (например, использование переполнения буфера) могут заставить злонамеренного пользователя получить доступ к оболочке, к которой та программа имеет доступ. Однако для той программы нужен тот доступ, чтобы сделать независимо от того, что та программа предназначена, чтобы сделать (иначе, это не может получить доступ к вещам, в которых это нуждается к). Это, почему его важное, чтобы гарантировать, что полномочия установлены правильно. Использование в rpc демоне является вполне большой проблемой, которая может быть решена путем обновления программного обеспечения (или путем ограничения его). – Chris 12.01.2012, 00:12
-
5Извините, исчерпал комнату. Изменение оболочки, к которой может получить доступ программа, ДЕЙСТВИТЕЛЬНО решает ту проблему, но это делает больше проблем с тем, что программа, как на самом деле предполагается, делает. Я думал, что Вы первоначально подразумевали, что злонамеренный пользователь мог SSH в через того пользователя, который они не могут (если они не устанавливают ключ, я верю, как Вы сказали). Можно решить ту небольшую проблему, в sshd_config, поместить "AllowUsers <имя пользователя> <имя пользователя>...", чтобы только предоставить определенным пользователям доступ SSH. – Chris 12.01.2012, 00:14
Я полагаю, что это - надуманный вопрос, как, для установки открытого ключа SSH в binкорневой каталог (/bin), у взломщика должен был бы быть корневой доступ к файловой системе, что означает, что Вы завинчены так или иначе.
Если Вам нравится, Вы могли бы отключить все методы аутентификации для bin пользователь в конфигурации sshd с помощью MatchUser блок.
Тем не менее похож на пользователя мусорного ведра, не использовано в современных Debian-полученных системах и просто намек на традицию или там для соответствия некоторым стандартам.