Tuesday, August 13, 2013

Rsync Without SSH Terminal Access

Picture this: Siciliy, 1952.

I tend to only post about the victories in my work, but I realized yesterday that it is also valuable to note the things that don't have a happy ending—the solution fails.

A couple of engineers need to have some sort of remote syncing set up so that they can pull data down from a NAS without having to rely on NFS mounts. They're using Macs, which they've said is not the "biznazz" when it comes to NFS mounts. They struggle with maintaining their mounts after a reboot for example.

The first question was how to sync. They wanted a graphical tool so that they could browse, and the sync was largely going to be one-way (pulling down). I found recommendations online for a couple of graphical tools like Grsync and arRsync, but they either hadn't been updated in a while (I'm talking 2010) or weren't the right tool for the job (like still relied on mounts underneath). In the end I went with vanilla rsync. Setup was fairly trivial except that it didn't work. My Manager helped me troubleshoot and in the end he remembered a little nugget that I was unaware of: passwordless SSH still requires that the user have a password set on the server itself.

That fixed, I thought I had everything all sorted until I realized something: rsync access means the users can also ssh to the box. Whoops. I thought that assigning them a shell like /usr/bin/false (Solaris box) would be sufficient, but that also stop rsync from working, so no go. I found a lot of articles that suggested the same fix http://silentorbit.com/notes/2009/07/restricted-backups-using-rsync/, http://learninginlinux.wordpress.com/2009/05/07/rsync-fixed-server-side-options/, and http://www.eng.cam.ac.uk/help/jpmg/ssh/authorized_keys_howto.html among them) which was to add a line to the authorized_keys file with the specific allowed rsync command. The only downside to that solution was that it restricted the users to running a specific rsync command. In other words, whatever syntax I used to get the command to add to the authorized_keys file was the exact command they'd have to use. It also meant no flexibility in terms of what remote directories they were syncing.

I didn't think this was going to work for them but I figured I'd hand it off and see what they came back with. It's sometimes a challenge to get clear requirements from folks, and I have often found that you get a better sense of what they're trying to do after trying a solution and reviewing why it doesn't work. The same was true this time around. It turns out that they actually have a script that does some very specific copying and writing to the remote location, so while manually pulling down the data would have worked, the script failed due to the security limitations I had put in place. The script specifically wanted to create new files on the share (which was interesting since they had originally told me they were only doing pulls!) using ssh commands, which I had gone out of my way to disallow. Nor was I about to install SFTP (their other suggestion) on our NAS.

We were sitting there looking at each other blankly as we had reached an impasse. I suggested, meekly, that maybe they should just run their scripts off of the servers that had been assigned to them (and to which they had been given ssh access) using NFS mounts on the server instead of trying to connect to the storage box directly. In other words, if Server A has a mount at /mnt/NAS that points to the root of the share they need, and they have full ssh access to Server A, why not have their script connect to Server A and rsync from /mnt/NAS instead? The engineer replied, "Well...that's simple. I must have considered that at some point and dismissed it for some reason." And he sat and tried to think of when this had happened, but couldn't. I asked him to go try it and maybe the reason not to use it would repeat itself there. He did, and there were no issues, so in the end the task was shelved as it was determined that they had the resources they needed for the task already at hand.

No comments:

Post a Comment