0

The setup I'm facing is this one:

In server A I'd like to mount a directory (let's call it SHARED) from server B. There is no route and no way to add any from A to B or from B to A. The inverse, to mount a directory from A in B is also necessary.

There is a third server C. C can ping A and B, but cannot ssh to any of them. But A and B can ssh to C. C cannot NFS (or Samba) export directories.

This answer comes close to it, but it's lacking the second branch of it the common share of a directory.

It mounting a directory of A in B (or vice-versa) is not possible, is there a way to mount a directory in C that is shared both for A and B, like if C was exported as a NFS share, but using sshfs in reverse mode?

Luis
  • 752

1 Answers1

0

sshfs

A and B can ssh to C.

is there a way to mount a directory in C that is shared both for A and B, like if C was exported as a NFS share, but using sshfs in reverse mode?

I don't know what you mean by "reverse mode", but since you can ssh from A to C, you should be able to run sshfs on A to mount a directory existing on C (unless the SSH server on C does not support SFTP). It's quite straightforward:

# on A
sshfs user@C:/specific/dir/of/C /some/mountpoint

The same for B. This way A will see /specific/dir/of/C as /some/mountpoint on A; and B will see /specific/dir/of/C as /some/mountpoint on B.

Disadvantages:

  • Whatever A (or B) does to its /some/mountpoint, on C it will be done by user. sshfs on A (or B) uses FUSE and there is a way to allow users other than the invoker to use it on A (or B), still on C they all will act as user.

  • Additional problems may arise if user specified by A is different than user specified by B and the two users cannot find a "common" directory on C that fits them in terms of ownership and permissions.

  • Copying a file from A to B (or from B to A) requires uploading it from A (B) to C and then downloading from C to B (A). You cannot do this by acting on A xor B alone.

  • Also such copying requires you to download not too fast (or not too soon), so when you reach the end of a file, it's the real end, not because you caught up to the uploading process that runs in the same time and is going to keep appending to the file existing on C. In practice you would most likely want one end to upload fully before the other end downloads (or uses) the file. While copying a directory, the downloader would most likely want to wait for the uploader to upload the whole directory, otherwise it could miss some files.

Chaining tunnels

From A you can reach a TCP port of B by chaining two SSH tunnels. In this another answer I do this by working from a "middle node", because in that case there is SSH access from the middle to each end. You need to do this by working from both ends towards the "middle node" (which is your C) because these are the directions you can ssh in. Proceed like this:

# on A
ssh -N -L 3333:localhost:4444 user@C

# on B
ssh -N -R 4444:localhost:5555 user@C

When these work, any process on A that connects to localhost:3333 will be tunneled to localhost:4444 on C, ultimately to localhost:5555 on B.

3333 and 4444 are arbitrary ports, adjust the numbers to your needs (mind privileged ports). 5555 is the port on B used by the service you want to reach.

Notes:

  • The situation is symmetrical, so to reach a service of A from B, just swap A and B in the above example.
  • Some services require more than one port.
  • You can use more than one -L and/or -R option with a single ssh invocation. This means you can establish many chained tunnels (some in one direction, some in the opposite direction) using just one ssh on A and one ssh on B.
  • ~/.ssh/config is your friend. On A and on B define the respective parts of the tunnels in the config file and then ssh -N user@C on each end will be enough. See man 5 ssh_config.
  • autossh is also your friend.
  • SSH cannot tunnel UDP. Do not trust contraptions like in this other answer, they are flawed. In general ssh -w can be used but it's hard even when you don't need to chain connections.
Kamil Maciorowski
  • 81,893