Tunneling X over SSH is simple:
$ ssh -X [hostname]
But if you have to su to another user, you may have seen this:
$ sudo su -
# xterm
X11 connection rejected because of wrong authentication.
X connection to localhost:10.0 broken (explicit kill or server shutdown).
Some commands will still work if you don’t load up the new user’s environment, (using a “su” rather than “su -”) but you will still have some problems.
The problem is caused by xauth, and the easiest thing to do is merge in the Xauthority cookies form the previous UID:
$ sudo su -
# xauth merge ~[username]/.Xauthority
# xterm
All X applications should now correctly open on you client machine.
From the SSHFS site:
This is a filesystem client based on the SSH File Transfer Protocol. Since most SSH servers already support this protocol it is very easy to set up: i.e. on the server side there’s nothing to do. On the client side mounting the filesystem is as easy as logging into the server with ssh.
Continue reading ‘SSHFS in FC5′
There are a couple of options I have found useful for SSHFS. Some of the default behaviours are kinda funky and permissions behave very strangely. In my first test implementation all users had write access to any other users file mounted via sshfs. This was not an acceptable solution, but easily fixed with the right options.
By default the user who runs sshfs is the only user who can see the mount, no one else has read or write permissions.
This can break things like GDM if you are using sshfs on home directories. You can allow root to see the contents of the mount with:
$ sshfs -o allow_root <server> <mountpoint>
But this will not fix the GDM problem, to allow all users to see the mount use the option allow_other, instead of allow_root.
But, by default, SSHFS does not allow the kernel to check permissions. To use only one of the options above would mean every user would have the same permissions as the owner of the mount point for all files that are part of the sshfs filesystem. You must also use the default_permissions options to have the kernel enforce permissions. The command:
$ sshfs -o allow_other,default_permissions
will mount the remote site and honour the permissions on files, so other users will only be able to access files if the permissions are set for other or group. All files are always owned by the ssh user regardless of who created them.
Been very busy working on a new lab build for the university. Deciding how to mount home directories is always challenging. NFS is not secure enough, I don’t like the current implementation of Kerberos support in NFSv4, with tickets being machine based. Until recently we have been using SMB with PAM_MOUNT but of course permissions were always monged, and smb shares have their own security concerns. I wanted home directory mounts which required user authentication and were secure. What I have settled for is SSHFS.
SSHFS is a FUSE based filesystem which basically uses sftp for the backend. There is no quota, flock or disk free support, and it is kinda slow, but it is a better solution than samba and it meets all of my security concerns. Getting it to work was fun, first trying pam_mount and then finally getting it to work with pam_script and a Perl::Expect script, I might post more on that later.
But once home directories were mounting successfully I discovered the Trash icon was behaving strangely. I could move data to Trash, and it would be moved to the .trash directory, but the Trash icon would still appear empty, and I could never empty the Trash folder.
It turns out the gnome-vfs package explicitly states all the filesystems it supports in the code. Fuse was not mentioned. Adding the line:
{ "fuse" , N_("FUSE Volume"), 1 },
to:
libgnomevfs/gnome-vfs-filesystem-type.c
and recompiling fixed the problem.