sshfs vs nfs

I found sshfs to be extremely convenient to set up and use (almost no setup when ssh is already running).
What are the disadvantages when compared to nfs?
In terms of speed, performance, reliability …

Compression overhead, poorer low latency toleration and if connection cuts every now and then sshfs get cranky.

Typical tradeoff when using a secure (sshfs) via an unsecure (nfs) protocol.

If only used in a LAN without any possibility to access the shares from the “outside world”, nfs will perform better, however nfs is no real option if the shares should be available from outside the LAN.

(Same story for smb, of course, never make shares accessible to the WAN.)

Actually the NFS ‘insecurity’ is a bit of a misconception, v4 has full encryption support so if properly configured is quite secure even over ‘unsecure’ networks.

On Tue, 19 May 2009 07:26:01 +0000, Chrysantine wrote:

> Compression overhead,

As well as the encryption overhead.

I tend to use sshfs for short connections (for example to rsync data from
a server I don’t have access to set up NFS exports on) or over the public
internet (mostly for the same reason - no access to set up NFS exports or
server config), NFS for persistent connections that are used constantly.

Jim

On Tue, 2009-05-19 at 04:36 +0000, syampillai wrote:
> I found sshfs to be extremely convenient to set up and use (almost no
> setup when ssh is already running).
> What are the disadvantages when compared to nfs?
> In terms of speed, performance, reliability …

Peformance penalty will be huge.

Just fyi.

Does sshfs support locking? How is client side caching done (hint, it
isn’t, only directory contents)? Sshfs is just a neato tool. It’s not
a network file system. It’s not going to be all that reliable either.

NFS is EASY to setup. Sshfs is arguably insecure in many/most setups.

On Tue, 19 May 2009 17:27:45 +0000, cjcox wrote:

> Sshfs is arguably insecure in many/most setups.

How so?

sshfs only exposes the remote filesystem (in the default configuration)
to the user who invoked it (that’s a FUSE feature, I believe), so what
about it is insecure?

Jim

On Tue, 2009-05-19 at 18:08 +0000, Jim Henderson wrote:
> On Tue, 19 May 2009 17:27:45 +0000, cjcox wrote:
>
> > Sshfs is arguably insecure in many/most setups.
>
> How so?
>
> sshfs only exposes the remote filesystem (in the default configuration)
> to the user who invoked it (that’s a FUSE feature, I believe), so what
> about it is insecure?

Obviously then you’re NOT getting an NFS resplacement then are you?
I’m talking about turning on the insecure options to allow it to behave
more generically like a network file system rather than a “one user”
client access.

On Tue, 19 May 2009 19:08:53 +0000, cjcox wrote:

> On Tue, 2009-05-19 at 18:08 +0000, Jim Henderson wrote:
>> On Tue, 19 May 2009 17:27:45 +0000, cjcox wrote:
>>
>> > Sshfs is arguably insecure in many/most setups.
>>
>> How so?
>>
>> sshfs only exposes the remote filesystem (in the default configuration)
>> to the user who invoked it (that’s a FUSE feature, I believe), so what
>> about it is insecure?
>
> Obviously then you’re NOT getting an NFS resplacement then are you?

No, but as I said, I’m not using it that way anyways.

> I’m
> talking about turning on the insecure options to allow it to behave more
> generically like a network file system rather than a “one user” client
> access.

I don’t think “most people” use it that way. I think it’s more likely
“most people” use it as intended.

Like most tools, if you use it the way it’s designed to be used, you
won’t have a problem with it. :slight_smile:

Jim

On Tue, 2009-05-19 at 19:31 +0000, Jim Henderson wrote:

> I don’t think “most people” use it that way. I think it’s more likely
> “most people” use it as intended.
>
> Like most tools, if you use it the way it’s designed to be used, you
> won’t have a problem with it. :slight_smile:

My point is THAT is NOT an NFS replacement. It’s more like somebody
running WinSCP under Windows (it’s better, yes… understood). But
it’s wrong to compare this to NFS… NFS is different, and this
isn’t a replacement. But for somebody that doesn’t need NFS but
just wants a friendlier access via ssh, yes… I suppose it is fine.

On Wed, 20 May 2009 14:34:58 +0000, cjcox wrote:

> My point is THAT is NOT an NFS replacement. It’s more like somebody
> running WinSCP under Windows (it’s better, yes… understood). But it’s
> wrong to compare this to NFS… NFS is different, and this isn’t a
> replacement. But for somebody that doesn’t need NFS but just wants a
> friendlier access via ssh, yes… I suppose it is fine.

If your point is that sshfs is not an NFS replacement, that’s fine, but
to say it’s less secure is inaccurate. That’s my point.

Jim

On Wed, 2009-05-20 at 16:44 +0000, Jim Henderson wrote:
> On Wed, 20 May 2009 14:34:58 +0000, cjcox wrote:
>
> > My point is THAT is NOT an NFS replacement. It’s more like somebody
> > running WinSCP under Windows (it’s better, yes… understood). But it’s
> > wrong to compare this to NFS… NFS is different, and this isn’t a
> > replacement. But for somebody that doesn’t need NFS but just wants a
> > friendlier access via ssh, yes… I suppose it is fine.
>
> If your point is that sshfs is not an NFS replacement, that’s fine, but
> to say it’s less secure is inaccurate. That’s my point.

Wow… do you know what beligerant means?
OP (remember the OP?) said sshfs VS NFS … not sshfs as a limited
network file system replacement. I was merely pointing out that there
is a HUGE difference and that trying to make sshfs more NFS-like would
mean introducing some security risks… I’m done responding to you,
I think your ears are closed.

On Wed, 20 May 2009 22:34:16 +0000, cjcox wrote:

> Wow… do you know what beligerant means? OP (remember the OP?) said
> sshfs VS NFS … not sshfs as a limited network file system replacement.
> I was merely pointing out that there is a HUGE difference and that
> trying to make sshfs more NFS-like would mean introducing some security
> risks… I’m done responding to you, I think your ears are closed.

Sheesh, no need to make it personal, dude.

And yes, I do know what “belligerent” (sic) means.

Using sshfs as a “limited network file system replacement” can be done,
and it’s really not any less secure than NFS is for that purpose either.

If it is, please share how it is. Otherwise don’t say that it creates a
security problem.

Jim

On Wed, 20 May 2009 22:34:16 +0000, cjcox wrote:

> OP (remember the OP?)

OP wrote:

> I found sshfs to be extremely convenient to set up and use (almost no
> setup when ssh is already running).
> What are the disadvantages when compared to nfs? In terms of speed,
> performance, reliability …

Now that sounds to me like the OP is asking for a comparison for a usage
that is essentially a single-user usage to access a remote system, not to
remotely mount, say, /usr or /var for diskless workstations.

Now if there are security considerations, don’t just say (as you did),
“Sshfs is arguably insecure in many/most setups.” What about it is
insecure, and how is it insecure in comparison to NFS?

If you’re going to raise security concerns about using sshfs, great - I
use it myself so if I am opening myself up to potential security issues
that I should be aware of, I’d like to hear what they are.

If you have nothing more specific than “Sshfs is arguably insecure in
many/most setups”, though, then you’re making an argument with no
supporting facts and raising a false security argument. What’s more, it
isn’t “arguably insecure” unless some evidence to support that statement
is put forth.

I have yet to see you put any such evidence forward. I’m asking for it
because I’m interested. I’m interested because this is news to me.

So how about providing some facts to support your assertion?

Jim

Jim Henderson wrote:
> On Wed, 20 May 2009 22:34:16 +0000, cjcox wrote:
>
>> OP (remember the OP?)
>
> OP wrote:
>
>> I found sshfs to be extremely convenient to set up and use (almost no
>> setup when ssh is already running).
>> What are the disadvantages when compared to nfs? In terms of speed,
>> performance, reliability …
>
> Now that sounds to me like the OP is asking for a comparison for a usage
> that is essentially a single-user usage to access a remote system, not to
> remotely mount, say, /usr or /var for diskless workstations.

I deleted my long response (too much “The Jim and Chris Show”).

My point is that sshfs is NOT NFS. Sshfs is NOT a remote file system
protocol. But I will agree that there are specific scenarios where
sshfs will suit many people’s needs.

Is it secure? Yes, if it is NOT being used as a muti-user NFS replacement.
I didn’t mean to create confusion (which apparently I have).

On Mon, 25 May 2009 14:51:48 +0000, cjcox wrote:

> My point is that sshfs is NOT NFS. Sshfs is NOT a remote file system
> protocol. But I will agree that there are specific scenarios where
> sshfs will suit many people’s needs.
>
> Is it secure? Yes, if it is NOT being used as a muti-user NFS
> replacement. I didn’t mean to create confusion (which apparently I
> have).

No problem, but I still don’t see how it is any less secure than using
NFS for multi-user access…If the issue is that using -o allow_other
lets other users use it, how is that different than providing multi-user
access via NFS?

Jim

On Mon, 2009-05-25 at 18:14 +0000, Jim Henderson wrote:
> On Mon, 25 May 2009 14:51:48 +0000, cjcox wrote:
>
> > My point is that sshfs is NOT NFS. Sshfs is NOT a remote file system
> > protocol. But I will agree that there are specific scenarios where
> > sshfs will suit many people’s needs.
> >
> > Is it secure? Yes, if it is NOT being used as a muti-user NFS
> > replacement. I didn’t mean to create confusion (which apparently I
> > have).
>
> No problem, but I still don’t see how it is any less secure than using
> NFS for multi-user access…If the issue is that using -o allow_other
> lets other users use it, how is that different than providing multi-user
> access via NFS?

That’s actually a different question. NFS has its own set of security
issues… which might be a reason for NOT choosing NFS. Using
allow_other has more to do with how ssh security is being compromised.

Sshfs because it doesn’t know about other people possibly playing around
inside of the same set of files doesn’t have an locking or stat support
and these kinds of things can create unexpected gotchas and open a
plethora of security holes. Agreed?

If hundreds of people were using sshfs over the same set of files, I
would imagine seeing some problems eventually.

On Tue, 26 May 2009 15:47:40 +0000, cjcox wrote:

> That’s actually a different question. NFS has its own set of security
> issues… which might be a reason for NOT choosing NFS. Using
> allow_other has more to do with how ssh security is being compromised.

Can you elaborate on this a bit? How is it that using allow_other
compromises ssh security?

> Sshfs because it doesn’t know about other people possibly playing around
> inside of the same set of files doesn’t have an locking or stat support
> and these kinds of things can create unexpected gotchas and open a
> plethora of security holes. Agreed?

I wouldn’t call it security holes, but certainly file corruption is
possible. I’m just not seeing the security issues here because I’m not
seeing anything specific being described. “Security holes” doesn’t
really tell me what the problems are.

> If hundreds of people were using sshfs over the same set of files, I
> would imagine seeing some problems eventually.

File corruption problems I could see, but security problems? I’m still
not seeing it.

Jim

On Tue, 2009-05-26 at 17:35 +0000, Jim Henderson wrote:
> On Tue, 26 May 2009 15:47:40 +0000, cjcox wrote:
>
> > That’s actually a different question. NFS has its own set of security
> > issues… which might be a reason for NOT choosing NFS. Using
> > allow_other has more to do with how ssh security is being compromised.
>
> Can you elaborate on this a bit? How is it that using allow_other
> compromises ssh security?

Just think about it that for a bit.

>
> > Sshfs because it doesn’t know about other people possibly playing around
> > inside of the same set of files doesn’t have an locking or stat support
> > and these kinds of things can create unexpected gotchas and open a
> > plethora of security holes. Agreed?
>
> I wouldn’t call it security holes, but certainly file corruption is
> possible. I’m just not seeing the security issues here because I’m not
> seeing anything specific being described. “Security holes” doesn’t
> really tell me what the problems are.

Do you NEED for me to establish a race condition scenario? While there
are certainly cache consistency issues with NFS, at least there are
some ways to do coordination. Since there is none with just sshfs,
there is lots of opportunity to confuse state. That’s an open
door.

I mean, I suppose, I could write an example up if needed. Might be
more fun and a better learning experience if you did it though.

>
> > If hundreds of people were using sshfs over the same set of files, I
> > would imagine seeing some problems eventually.
>
> File corruption problems I could see, but security problems? I’m still
> not seeing it.

Sigh… maybe I WILL have to create a scenario for you…

On Tue, 26 May 2009 18:46:34 +0000, cjcox wrote:

>> File corruption problems I could see, but security problems? I’m still
>> not seeing it.
>
> Sigh… maybe I WILL have to create a scenario for you…

I’m not the one stating it’s a security issue. You’re the one saying it
introduces a security issue - I’m just asking that you support that
assertion with some examples, that’s all. Anyone can say “this creates
a security issue”, but in the interest of keeping users of sshfs
informed, anyone making a claim like that should spell it out.

Jim