Craig White wrote, On 07/24/2008 04:49 PM:
On Thu, 2008-07-24 at 20:45 +0000, Mike wrote:
Mike <mike.cloaked <at> gmail.com> writes:
http://www.mjmwired.net/linux/2008/06/16/selinux-preventing-ssh-passwordless-login/
The above is on a single line - I had to break the line entering the url
Following the advice in that link I did
touch /.autorelabel;reboot
This reverted the system so that ssh in failed as it had in the first place
so I had to fix the context for /opt/ using restorecon again....
This put me back in the position where I can ssh in but only giving the
password - passwordless login is still not possible.
I tried restorecon -v /opt/Local/home/mike/.ssh/authorized_keys2 but
this made no difference - and I still cannot login without the password.
The sealert message suggests doing restorecon -v './authorized_keys2'
and I had tried but this does not fix the problem.
Hence there seems to be a bug in the SELinux policy on this issue?
----
I would doubt that.../opt is not a usual place for users $home
directories and thus the policy for files in that tree would not be
suitable for the method you are using.
Craig
I can agree with that, but how do you convince SEL that you desire
/rootlockeddown/<user>/authorized_keys to be a valid place for sshd to read?
note /rootlockeddown/ is not where home directories are, it is where the
admin approved keys are after the admin sets in sshd_config:
AuthorizedKeysFile /rootlockeddown/%u/authorized_keys
BTW I am not asking from just an academic perspective... I too will require a
way to do this eventually.
--
Todd Denniston
Crane Division, Naval Surface Warfare Center (NSWC Crane)
Harnessing the Power of Technology for the Warfighter
--
fedora-list mailing list
fedora-list@xxxxxxxxxx
To unsubscribe: https://www.redhat.com/mailman/listinfo/fedora-list
