Why aren’t we using SSH for everything? • Hacker News Board

Re: Why aren’t we using SSH for everything?

#61

Post by acdha » Sat, Jan 03, 2015, 12:23 AM UTC

XorNot wrote: post #22

falcolas wrote: post #9

Neat trick, if you're so inclined to use such tricks: $ cat .ssh/authorized_keys command="tmux new-session -A -s base" ssh-rsa [...] Automatically creates or joins a tmux session named base, and disconnects the SSH session when you disconnect from the tmux session. So, yeah, why don't we use SSH for more?

It's multiplexing support uses static sized windows, which even on modern LANs means you usually only see 3-5 mb/s transfer rates where you should be able to - even with encryption overhead - achieve almost gigabit NIC speed. Fortunately the HPN-SSH patches exist to solve this problem - but I really want to know why their's so much resistance to adding them upstream.

> which even on modern LANs means you usually only see 3-5 mb/s transfer rates where you should be able to

On a WAN, sure, but even a mid-2000s gigabit LAN could routinely hit 800+Mb with scp as long as you had tuned the underlying TCP stack (Linux was poor and OS X/*BSD worse in that era) and weren't using something slow like 3-DES.

> Fortunately the HPN-SSH patches exist to solve this problem - but I really want to know why their's so much resistance to adding them upstream.

Looking at the patches, I'd be surprised if the problem wasn't the fact that they change other things with security or reliability implications. Seeing something like “Dynamic Window and ability to use NONE encryption” suggests that it'd be better to break it up into some smaller generally-useful patches and a separate patch for people in controlled environments who need as much performance as possible.

Re: Why aren’t we using SSH for everything?

#62

Post by Shish2k » Sat, Jan 03, 2015, 12:24 AM UTC

marcosdumay wrote: post #48

shazow wrote: post #16

Earlier quoted context omitted.

You're right, we probably shouldn't use SSH to microwave our food. But a lot of things where we use HTTP today, we could be using SSH if we had better library support. Some more ideas towards the end of the post.

> we could be using SSH if we had better library support It's the firewall rules, not library availability.

Tunnel SSH over HTTP, best (worst) of both worlds :)

(I have tried this; it is both useful and terrible)

Re: Why aren’t we using SSH for everything?

#63

Post by bashinator » Sat, Jan 03, 2015, 12:35 AM UTC

Shish2k wrote: post #62

marcosdumay wrote: post #48

Earlier quoted context omitted.

> we could be using SSH if we had better library support It's the firewall rules, not library availability.

Tunnel SSH over HTTP, best (worst) of both worlds :) (I have tried this; it is both useful and terrible)

Or you could just run `sshd` on port 443.

Re: Why aren’t we using SSH for everything?

#64

Post by ytjohn » Sat, Jan 03, 2015, 12:40 AM UTC

XorNot wrote: post #21

singlow wrote: post #18

Earlier quoted context omitted.

Default configuration on all of the system's I have used (mostly Ubuntu) is that you cannot just approve it. You have to actually remove it from the known hosts table, in effect starting a new "first session". You can set it to allow override without deleting the entry though and some system may have this as the default.

Which is still irrelevant: in the default configuration the server I'm connecting to is probably not compromised, I've probably just done something to change keys or routes or names or whatever. The problem is further back: the default configuration doesn't make it easy to avoid these problems in the first place. If I'm logged in and do something which will change SSH host keys or the like, then the default needs to…

I don't even know of a client that implements this, but SSFP DNS records are the way to do this. http://www.openssh.com/txt/rfc4255.txt

A security conscious client can manually verify a host's SSHFP with a dig record. You'll also want DNSSEC in place to ensure the dns hasn't been spoofed either.

Re: Why aren’t we using SSH for everything?

#65

Post by alexgartrell » Sat, Jan 03, 2015, 12:45 AM UTC

ivansavz wrote: post #34

Isn't there a problem when you tunnel TCP over TCP with increasing window sizes (auto throttling mechanism meant to prevent packet fragmentation)? Every time I've tried to keep a long-running ssh tunnel for printing / http, the connection degrades after a while. I'm sure there are some flags that can be set, but I thought this was the major show stopper for the "everything over shh" (since ssh uses TCP protocol)

It depends how you set up the forwarding.

Casually looking at strings /usr/sbin/sshd on my devserver reveals that there is a mode to create a tun device, which sets up a more traditional VPN-ish thing (basically, your computer sees a new interface and routes certain sections of IP space to that prefix. sshd sucks in these packets and forwards them as is). This results in two layers of congestion control, which (IIRC -- I'm not a TCP guy) Congestion Control Algorithms aren't set up to handle very well.

The more traditional mechanism for tunneling though (the one most often referenced in the posts and things I've seen) is a layer 7 forwarder. Basically it creates sockets to listen for connections on either ends on a specific port, recv's data as a traditional network user, and then turns around and sends the data over the multiplexed transport to the end server. It essentially strips away the congestion control on the first hop (because you're just going to localhost anyway) and there's no TCP/IP packets in TCP/IP packets thing going on anymore, just your application stream in their header transport thing. It's less flexible, but is good enough if you want to set up a simple proxy or something and doesn't have the same pitfalls.

If you need the flexibility, something like OpenVPN might be good (though I haven't used it myself).

And you might also want to look at stunnel as an ssl tunnel alternative that lets you have more control over what certs go where without archaic and dangerous /etc/ssh/*_config meddling

Re: Why aren’t we using SSH for everything?

#66

Post by dec0dedab0de » Sat, Jan 03, 2015, 12:50 AM UTC

bashinator wrote: post #63

Shish2k wrote: post #62

Earlier quoted context omitted.

Tunnel SSH over HTTP, best (worst) of both worlds :) (I have tried this; it is both useful and terrible)

Or you could just run `sshd` on port 443.

But this would fail on many proxies, and any firewall that was aware of the protocol.

Re: Why aren’t we using SSH for everything?

#67

Post by kgilpin » Sat, Jan 03, 2015, 1:06 AM UTC

Something else worth mentioning; SSH has built-in support for single-sign-on, via SSH agent forwarding. As long as my public key is available anywhere (and that's exactly what it's designed for), then I can be authenticated by any system, anywhere. Thus, a problem which is so vexing in so many other scenarios, is very cleanly addressed by SSH.

Fundamentally, a password is a shared secret. So you send your password to a server, you are trusting that server not to lose or misplace it. In contrast, an SSH public key doesn't require nearly such careful management.

Re: Why aren’t we using SSH for everything?

#68

Post by jzila » Sat, Jan 03, 2015, 1:06 AM UTC

otterley wrote: post #52

For one thing, SSH performance for large transfers is abysmal over high-latency links. SSH uses a small TCP window size because it was optimized for quick response, not bulk transfers. (After all, it was designed to be a remote shell protocol, not a generic file transfer protocol; scp and sftp were added after the fact.) And unfortunately you can't currently specify a different buffer size even if you wanted to. More…

Are there any plans to patch this into OpenSSH? It looks like they have a great solution for the problem you highlighted.

Re: Why aren’t we using SSH for everything?

#69

Post by bondolo » Sat, Jan 03, 2015, 2:09 AM UTC

Key management is pretty primitive. It would be nice if SSH integrated better with PGP/GPG. I recently spent too much time messing with monkeysphere, keychain, gpg-agent, gpgsm etc. trying to use GPG derived keys for SSH. While I could cobble something together I didn't feel that it was a solution I could recommend to others as a general "best practice" because it involved too much installing and configuring and was still somewhat brittle (eg. providing key names to gpg-agent in my .bashrc file).

Re: Why aren’t we using SSH for everything?

#70

Post by dllthomas » Sat, Jan 03, 2015, 2:22 AM UTC

bondolo wrote: post #69

Key management is pretty primitive. It would be nice if SSH integrated better with PGP/GPG. I recently spent too much time messing with monkeysphere, keychain, gpg-agent, gpgsm etc. trying to use GPG derived keys for SSH. While I could cobble something together I didn't feel that it was a solution I could recommend to others as a general "best practice" because it involved too much installing and configuring and was…

I'd love to see a project to make this suck less.