3 ms·

I might be misunderstanding the question but ... just use rsh?

throwaway894345 4y ago
I think for the same reasons I wouldn't "just use ssh" over tailscale--I don't want to have to manage an sshd that doesn't require key or password auth but listens over tailscale (and nothing else!). Basically, what I want is for tailscaled to be my rshd (appropriately configured for connections over tailscale network only, etc) or in other words to avoid double-encryption (it's not the end of the world, but ideally we don't need to doubly-encrypt).
- structural 4y ago
  Double (or more) encryption ends up happening a lot in larger networks not for technical reasons but for policy ones. This is unsurprising, because it is used for different purposes in different layers of the stack. It is not at all a black and white state of "encrypted" vs. "not encrypted". For example, in one organiztion I've worked with, Wireguard (generally, including Tailscale) is approved for restricting connections only to authorized network devices/users and that data maintains integrity in transit, but is not approved for protecting the confidentiality of sensitive information. Connections which access specific resources are required to be encrypted at the application level using a mechanism which has been approved for that information type (given a specific threat model). So you could transmit very small amounts of data over TCP/IP, over a Tailscale network, using a set of pre-shared, one-time pads. And you might actually want to do this! It's really not ridiculous, but you do need to assess whether you really do have a threat model that needs it.
raggi 4y ago
Around the time I joined Tailscale, actually just before, I had a look at rsh with an eye in this direction. The problem is that rsh is very stale and unmaintained - even those versions that have had releases in recent years (e.g. GNU Inetutils) are very old inside - even if they've kept up with patches, they have not kept up with features e.g. modern user session construction. It also turns out that ssh the client, much more so than ssh the protocol, is really a key integration point and API that users end up needing. It has a broad feature set that turns up in use cases all over, many of which rsh does not handle.

I think for the same reasons I wouldn't "just use ssh" over tailscale--I don't want to have to manage an sshd that doesn't require key or password auth but listens over tailscale (and nothing else!). Basically, what I want is for tailscaled to be my rshd (appropriately configured for connections over tailscale network only, etc) or in other words to avoid double-encryption (it's not the end of the world, but ideally we don't need to doubly-encrypt).

structural 4y ago
Double (or more) encryption ends up happening a lot in larger networks not for technical reasons but for policy ones. This is unsurprising, because it is used for different purposes in different layers of the stack. It is not at all a black and white state of "encrypted" vs. "not encrypted". For example, in one organiztion I've worked with, Wireguard (generally, including Tailscale) is approved for restricting connections only to authorized network devices/users and that data maintains integrity in transit, but is not approved for protecting the confidentiality of sensitive information. Connections which access specific resources are required to be encrypted at the application level using a mechanism which has been approved for that information type (given a specific threat model). So you could transmit very small amounts of data over TCP/IP, over a Tailscale network, using a set of pre-shared, one-time pads. And you might actually want to do this! It's really not ridiculous, but you do need to assess whether you really do have a threat model that needs it.

raggi 4y ago

Around the time I joined Tailscale, actually just before, I had a look at rsh with an eye in this direction. The problem is that rsh is very stale and unmaintained - even those versions that have had releases in recent years (e.g. GNU Inetutils) are very old inside - even if they've kept up with patches, they have not kept up with features e.g. modern user session construction. It also turns out that ssh the client, much more so than ssh the protocol, is really a key integration point and API that users end up needing. It has a broad feature set that turns up in use cases all over, many of which rsh does not handle.