David Alessio(deleted)
|
SSH mux'd connections don't work
|
David Alessio(deleted)
03/20/2015 7:13 PM
post113579
|
SSH mux'd connections don't work
Hello,
On a QNX machine, logged in as root ($HOME is /root), suppose I have the following file:
/root/.ssh/config
with the following contents:
Host *
ControlPath ~/.ssh/master-%l-%r@%h:%p
ControlMaster auto
I should be able to establish an initial connection to a remote host such that subsequent connections are mux'd through
the existing connection (and don't need to go through the CPU-intensive authentication dance).
After recompiling and debugging openssh, it seems there are two issues:
1) OpenSSH temporally creates (in mux.c) a socket file with a random string that's later hard-linked to a persistent
fname and the original then unlinked (deleted). This fails with the error message akin to:
ln: xxx and yyy are on different file systems -
Can't create hard link. Use ln -s or make a copy.
I'm guessing, that the socket file is managed by pipe whereas the ln (in C: link()) is attempting to create a hard link
between pipe's pseudo FS and the underlying QNX4/6/NFS FS which fails for obvious reasons.
2) Having hacked OpenSSH/mux.c to "fix" the above issue, it seems that there's some inherent pathname length limit to
the socket filename of 32. This is strange since sizeof(address.sun_path) is 104 where address is:
struct sockaddr_un address;
So, my question is two fold:
1) why is it that "funky" things happen when socket file pathnames exceed 32 byte?
and
2) what's the best way to "fix" pipe (is it pipe?) so that it handles hard links? This is IMHO important because
several open source packages assume they can create hard links to socket files (and use this method to atomically create
the socket file).
Cheers,
-david
|
|
|