Timeline for Use numbered file descriptors with SSH
Current License: CC BY-SA 4.0
10 events
| when toggle format | what | by | license | comment | |
|---|---|---|---|---|---|
| Oct 6 at 17:18 | comment | added | Marcus Müller | and that's the thing I've been saying in my answer and repeatedly here in the comments: nope. It does not exist, and it's not likely to exist, because the TCP and UNIX socket transports duplicate that functionality, but reflecting the actual capabilities of the transport more accurately. (you're really by no means passing an fd; you can't close it, ioctl on it, dup it, splice it, …: it's not a file descriptor that gets transported, but a stream of bytes, so if you want that, use a byte stream transport and extract the bytes at the other end :) ) | |
| Oct 6 at 16:40 | comment | added | con-f-use |
SSH could just introduce an option as it did with -t and -tt or -D, -L and -R. If such an option (or similar mechanism) exists was my original question.
|
|
| Oct 5 at 21:46 | comment | added | Marcus Müller |
especially, there's zero way for the ssh client to know what <&3 on the remote end command means; that is only implemented by the shell on the remote end, not by SSH. And any process has can have a large number of different file descriptors open; they can be of very different kinds. You cannot just preemptively "forward" them in case the target shell tries to open nr 3; that's not even something that is practically possible, as the target environment might already have a fd with that number. Really, honestly, not something that can work, sorry.
|
|
| Oct 5 at 21:38 | comment | added | Marcus Müller | Just to be clear: The one that makes surprising claims is you, not me. I'm sorry, I have a bit of experience with both the SSH protocol in general and with the SSH shell transport especially, and I can repeatedly tell you: no, that's not something you could simply implement. That requires a whole lot of additional functionality that SSH intentionally does not have, because it's specifically functionality that in the overall design is handled by something else: If you need a network or domain socket transport, implement a network or domain socket transport; SSH can tunnel this. | |
| Oct 5 at 21:12 | vote | accept | con-f-use | ||
| Oct 5 at 21:09 | comment | added | con-f-use | Again, of course it could. Maybe forward is the slightly wrong word but the deamon could create them and then it could fill them with the correct bytes, because the client could distinguish what comes from which descriptor on the client site and forward that info to the server. As I said ssh has socket forwarding functionality. File descriptor forwarding in that sense would have not been an unreasonable or outrageous feature to expect. My advice would also be, to maybe clam down a bit, friend. | |
| Oct 5 at 21:05 | comment | added | con-f-use | I will probably just scp a file, which I'll have to access manage and then clean up, and which is slightly more code, but I'll live. Thanks so much for taking the time to answer. | |
| Oct 5 at 21:05 | comment | added | Marcus Müller | no, it could not "conceivably" forward file descriptors. It doesn't forward the stdin file descriptor, it forwards the bytes sent to the stdin file descriptor of ssh. there's no way to transfer, again, the local operating system concept of file descriptors. That's what my answer explains! | |
| Oct 5 at 20:58 | comment | added | con-f-use | Of course it conceivably could forward file descriptors. It does so with stdin. SSH can also forward ports and sockets, There's nothing conceptually stopping other file descriptors to be forwarded. But that's another debate, my question of whether SSH can is answered with a "currently not". | |
| Oct 5 at 12:24 | history | answered | Marcus Müller | CC BY-SA 4.0 |