Все говорит, что Applocker, как предполагается, работает: Почему не делает этого?
~/.ssh/authorized_keys файл в расчете на пользователя. Установка программы Unix никогда не пишет в корневые каталоги пользователей. Таким образом, по умолчанию файл не будет существовать (который имеет тот же эффект как пустой файл).
При генерации ключа на клиенте, который также выполняет OpenSSH, использовать ssh-copy-id [как описано] для передачи открытого ключа серверу, использующему в течение того одного времени пароль для вхождения в сервер.
Если Вы генерируете ключ некоторым другим методом, копируете id_rsa.pub файл от того, где Вы генерировали ключ к ~/.ssh/authorized_keys на сервере (создают каталог ~/.ssh при необходимости). Удостоверьтесь что все три из Вашего корневого каталога, ~/.ssh и ~/.ssh/authorized_keys перезаписываемы только пользователю (никакая группа или другие полномочия записи). Если Вы хотите авторизовать больше чем один ключ, просто связать их в ~/.ssh/authorized_keys (так ~/.ssh/authorized_keys имеет один открытый ключ на строку).
При использовании чего-то другого, чем OpenSSH для генерации ключа, Вы, возможно, должны были бы преобразовать открытый ключ в формат OpenSSH. Например, в PuTTY, используйте ‘Открытый ключ для вставки в authorized_keys файл’.
Если ваш блок пути был определен неправильно, это объяснит вам ситуацию.
Например, если вы использовали переменную среды% userprofile%. Есть только подмножество переменных среды, доступных через GPO / AppLocker, и это не одна из них.
Я добился успеха со следующим правилом пути:
%osdrive%\users\*
Это старый поток, но я наткнулся на него при реализации AppLocker'а в нашей собственной сети.
AppLocker требует использования службы идентификации приложения (Application Identity), которая установлена в Manual при установке по умолчанию Win7/Server 2008 R2. Вы должны установить службу идентификации приложений в значение Автоматический запуск, иначе правила не будут применены. Это можно сделать с помощью объекта групповой политики, где определены правила AppLocker
.