Разрешить SCP в RHEL CentOS 7 selinux

Вероятно, этому есть много причин. Я могу рассказать вам, что помогло мне, когда у меня была такая же (или очень похожая )проблема. Мой пароль -less команда scp не удалась:

-bash-4.2$ scp postgres@192.168.0.12:/var/backups/pgdumpfile.fc.
Permission denied (publickey,gssapi-keyex,gssapi-with-mic).
-bash-4.2$

Я запустил "setenforce 0" на исходной машине, и мой scp заработал, я запустил "setenforce 1", и снова произошел сбой.

Моя проблема оказалась в «Контексте файла SeLinux» моего файла «/.ssh/authorized _keys» на удаленной машине (192.168.0.12 ):

-bash-4.2$ pwd /var/lib/pgsql -bash-4.2$ cd.ssh -bash-4.2$ ls -Z authorized_keys -rw-------. postgres postgres unconfined_u:object_r:postgresql_db_t:s0 authorized_keys -bash-4.2$

Вещь с тремя двоеточиями — это «контекст файла Selinux», и Selinux очень разборчив в этом (так же, как Selinux во всем остальном ). Я полагаю, он состоит из четырех частей,и документация SeLinux, объясняющая, что/почему/как каждая часть WRTO, так же ясна и проста -для -понимания, как (я уверен, что )"man audit2why" был для вас (, если вы посмотрели у него ).

Так или иначе, моя проблема была связана с материалом между 2-м и 3-м " :", частью "postgresql _db _t". SeLinux это просто не понравилось. На другой машине, с которой я мог пароль -менее успешно использовать scp с благословением Selinux, та же самая часть «контекста файла Selinux» была «ssh _home _t ", который казался гораздо более перспективным.

Итак, как изменить "Контекст файла Selinux"?? Поиск в Google «контекст файла изменения selinux» привел меня к командам «semanage» и «restorecon». Так вот, "semanage" был кроличьей -норой, в которую мне, к счастью, не пришлось лезть. "restorecon" сделал свое дело для меня.

Оказывается, (и это очень мало -разрекламированной информации о SeLinux ), определены надлежащие утвержденные освященные по умолчанию «контексты файлов Selinux» для всех видов общих файлов в Unix/Linux. каким-то образом (на Centos в любом случае )в дереве каталогов "/etc/selinux/targeted/contexts/files/"! Вот что для меня сделал restorecon:

[root@srcbox ~]# /sbin/restorecon -v /var/lib/pgsql/.ssh/authorized_keys /sbin/restorecon reset /var/lib/pgsql/.ssh/authorized_keys context unconfined_u:object_r:postgresql_db_t:s0->unconfined_u:object_r:ssh_home_t:s0 [root@psrcbox ~]# . . . . -bash-4.2$ pwd /var/lib/pgsql/.ssh -bash-4.2$ ls -Z authorized_keys -rw-------. postgres postgres unconfined_u:object_r:ssh_home_t:s0 authorized_keys -bash-4.2$

Я не определял никаких новых «контекстов файлов SeLinux» через semanage. Существующих определений было достаточно, чтобы сообщить команде «restorecon», каким должно быть третье поле «Контекст файла SeLinux» моего файла «авторизованные _ключи». И тогда я мог бы оставить SeLinux в принудительном режиме на моей исходной машине и успешно запустить scp.

Теперь, вероятно, существует какой-то официальный утвержденный способ создания и обновления файла «авторизованных _ключей», который в первую очередь получает правильный «контекст файла SeLinux», но я не могу сказать вам, что это такое. Все, что я могу сказать, это создать файл с «vi» после ручного создания каталога «.ssh»,а затем вырезание -и вставка открытого ключа с машины и пользователя, на котором я запускал команду scp, скорее всего, не так.

Итак, попробуйте запустить restorecon для различных файлов в соответствующих каталогах «.ssh» и, возможно, для самого каталога. Удачи.