9 ms·

Why aren’t we using SSH for everything?

270 points by dkua 12y ago

ezequiel-garzon 12y ago
What surprises me is the lack of total CLI control, potentially through SSH and ideally using keys, of your hosting provider's control panel. Whether it's CLI or some form of TUI, it's bound to be faster and more convenient for many developers.
- blfr 12y ago
  Cloud providers nowadays usually have some sort of CLI clients. OpenStack comes with a full suite[1]. Google rolled out their own for Google Cloud[2]. And if there's nothing official, there are often tools built by users available for interacting with the API. Authentication is based on some sort of shared secret rather than keys though, yes. [1] http://docs.openstack.org/user-guide/content/ch_cli.html http://docs.openstack.org/user-guide/content/ch_cli.html [2] https://cloud.google.com/sdk/gcloud/ https://cloud.google.com/sdk/gcloud/
feld 12y ago
I wonder if his chat server has been hit by a botnet yet trying to ssh in and then sending tons of shell commands
- 4mnt 12y ago
  That would be very interesting to watch (albeit a bit annoying for the people trying to chat)
- shazow 12y ago
  Lots of people spamming/flooding/DoS'ing "for fun", but no clueless bots stumbling in accidentally yet. Btw previous HN thread about ssh-chat here: https://news.ycombinator.com/item?id=8743374 https://news.ycombinator.com/item?id=8743374
shazow 12y ago
Sorry the title has been revised to "Why aren’t we using SSH for everything?" in case mods see this.
forfengeligfaen 12y ago
If you believe Jacob Appelbaum, we probably should not be using SSH for anything http://media.ccc.de/browse/congress/2014/31c3_-_6258_-_en_-_saal_1_-_201412282030_-_reconstructing_narratives_-_jacob_-_laura_poitras.html#video http://media.ccc.de/browse/congress/2014/31c3_-_6258_-_en_-_...
- shazow 12y ago
  Yea I was fairly confused about that announcement as I couldn't find anything damning in the released docs about SSH. Do you have a reference to a specific document/slide?
  - doctorshady 12y ago
    Spiegel briefly touched on it too; The NSA also has a program with which it claims it can sometimes decrypt the Secure Shell protocol (SSH). This is typically used by systems administrators to log into employees' computers remotely, largely for use in the infrastructure of businesses, core Internet routers and other similarly important systems. The NSA combines the data collected in this manner with other information to leverage access to important systems of interest. (source: http://www.spiegel.de/international/germany/inside-the-nsa-s-war-on-internet-security-a-1010361.html http://www.spiegel.de/international/germany/inside-the-nsa-s... ) Still incredibly vague. If they're archiving all traffic in hopes of decrypting it some day though, it's safe to say we should treat anything on the internet as the shiny side of one way glass.
  - boracay 12y ago
    My guess is that, at least, some router ssh implementation is insecure, possibly not by accident. From the slides: Page 19: "SSH [...] Potentially recover user names and passwords" Page 36: "SSH - often have router configurations and user credentials [...]" http://www.spiegel.de/media/media-35515.pdf http://www.spiegel.de/media/media-35515.pdf
    - shazow 12y ago
      Right, I saw that also. Is it referring to routers that happen to run SSH with default root/admin passwords or something? I couldn't find anything more concrete.
falcolas 12y ago
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?
- XorNot 12y ago
  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.
  - falcolas 12y ago
    Good answer. If I had to guess, the reason would be threefold. One, it requires tuning on both ends of the connection to make the high speed transfers work well (and it looks like it will interfere with multiplexing as well, the reason the fixed window exists in the first place). Two, the "none" cypher which it enables completely undermines the security of the secure shell. The cypher renegotiation after authentication would make it trivial to MITM the connection. You could probably disable the cypher after every transfer by restarting the sshd daemon, but that's being a bit optimistic. Finally, there is no visible license on the patchfile, or on the homepage. The project's sourceforge page lists it as being BSD licensed, but there is no indication from the author that this is the case. http://www.psc.edu/index.php/hpn-ssh http://www.psc.edu/index.php/hpn-ssh
  - acdha 12y ago
    > 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.
higherpurpose 12y ago
I read somewhere that SSH can be MITM'ed by a global adversary on the first visit (before it establishes the secure connection). Is that true?
- forgottenpass 12y ago
  It can be MITM-ed on any connection. Whether you approve the host fingerprint is, and has always been, entirely up to you.
  - singlow 12y ago
    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.
    - XorNot 12y ago
      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 provide a way for me to make that information easily available globally to other clients which might be aware of this system.
      - ytjohn 12y ago
        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 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.
- 12y ago
forgottenpass 12y ago
Why aren’t we using SSH for everything? Because "Use X for everything" is a terrible design decision? SSH uses flexible transport with some desirable features and may be underutilized in practice. This question is starting to feel like people who want to staple every pie in the sky idea to the bitcoin blockchain because it too has a set of desirable properties.
- shazow 12y ago
  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.
  - blfr 12y ago
    Someone has to be running NetBSD on their microwave owen. I remember a toaster story. http://www.embeddedarm.com/software/arm-netbsd-toaster.php http://www.embeddedarm.com/software/arm-netbsd-toaster.php
  - marcosdumay 12y ago
    > we could be using SSH if we had better library support It's the firewall rules, not library availability.
    - Shish2k 12y ago
      Tunnel SSH over HTTP, best (worst) of both worlds :) (I have tried this; it is both useful and terrible)
      - bashinator 12y ago
        Or you could just run `sshd` on port 443.
        dec0dedab0de 12y ago
josephg 12y ago
Because SSH requires several seconds to initiate a session, even on a local LAN. Does anyone know why this is the case? Its always baffled me.
- shazow 12y ago
  It shouldn't take much longer than an HTTPS connection, could be something with your server configuration or latency?
- scott_karana 12y ago
  TLS also takes some time to initiate a session, but that hasn't turned anyone off SPDY, since it supports concurrency from then onwards. :-)
- agwa 12y ago
  Initiating an SSH connection takes 300ms on my LAN. If it's taking you several seconds then you probably have a reverse DNS problem. (By default, the SSH server looks up the reverse DNS of the client when it connects.)
- encoded 12y ago
  It could also be your shell on the remote host taking it's time. Some distros have gotten a bit bloated.
- geoffc 12y ago
  Slow SSH session is usually a DNS issue.
- monksy 12y ago
  Thats probably because the server is trying to lookup the client on DNS: http://www.turnkeylinux.org/blog/slow-ssh http://www.turnkeylinux.org/blog/slow-ssh
- _JamesA_ 12y ago
  You may be experiencing the GSSAPIAuthentication delay. The -v flag will help identify where the connection is being delayed. ssh -v [user@]hostname [command] Try connecting with the option disabled. ssh -o GSSAPIAuthentication=no [user@]hostname [command] You can globally disable GSSAPIAuthentication in ssh config: echo 'GSSAPIAuthentication=no' >> ~/.ssh/config
sharpneli 12y ago
SSH can really be used for almost everything. It's a different thing if it actually _should_ be used for everything. My favourite one: http://en.wikipedia.org/wiki/SSHFS http://en.wikipedia.org/wiki/SSHFS Whenever I'm developing for my mobile phone I actually have the contents mounted on my desktop via sshfs as an actual filesystem. What that means? Don't bother with FTP servers. ssh access to your server is all you need.
ivan_ah 12y ago
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)
- SilasX 12y ago
  Have you tried the autossh utility? That's what I use to keep up long-term tunnels.
  - otterley 12y ago
    The window size issue has to do with bandwidth, not session duration. See, e.g., http://www.psc.edu/index.php/hpn-ssh http://www.psc.edu/index.php/hpn-ssh
- alexgartrell 12y ago
  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
spydum 12y ago
Interesting idea, but isn't ssh very sluggish when it comes to throughput and latency? Doesn't it cost quite a bit more in CPU? I'd hate to make ssh the protocol replacement for http for a busy site.
- monksy 12y ago
  It depends on the clipher you're using and the implementation/hardware.
  - otterley 12y ago
    It depends more on the TCP window size; OpenSSH uses a small one by default and it cannot be changed. See also http://www.psc.edu/index.php/hpn-ssh http://www.psc.edu/index.php/hpn-ssh
sysk 12y ago
It's not clear to me how SSH differs from SSL/TLS conceptually. It seems to me both achieve similar goals (encrypted tunnel, client/server authentication). Perhaps we should take the best bits of both protocols and create a new one? But then, I am reminded of http://xkcd.com/927/ http://xkcd.com/927/.
- peterwwillis 12y ago
  SSH is designed to serve a single service on a single host. It distributes its host key on the first connection and caches it indefinitely, assuming it will never change. SSH is designed with a limited set of protocol features, and everything else is kind of hacked on top of proprietary client/server pairs. SSH is designed as a loose encrypted session (kind of like a pipe) for an application on a host. TLS is designed to serve multiple services on multiple hosts. It depends on your browser trusting an intermediary host which validates the host key, so (in theory) the initial connection can't be MITM'd, and so the key can change at any time or there can be multiple keys (which is needed for hosting multiple services on multiple hosts). TLS is designed to integrate tightly into an application. When you compare the two protocols, TLS is clearly superior to SSH. But in terms of the features they support (tunneling, authentication, etc), it's up to the server to add missing features outside of the protocol to provide for what the client wants to do. For example, the SSH protocol basically provides an encrypted connection through which you can do whatever you want, similar to TLS. To do IP tunneling with SSH the application server activates extra functionality to connect the encrypted session to a driver which opens an IP tunnel. Or to authenticate your ssh session against a kerberos server, the ssh server does the actual kerberos authentication; the protocol just informs the client of what 'basic' methods they can use, and the client tries to use one that works with the server's methods. Incidentally, TLS the protocol supports client certificate authentication, which provides similar functionality to SSH's public keys. The HTTP protocol also does certificate pinning.
  - onnoonno 12y ago
    Maybe it would be nice then if TLS would somehow cache host keys, too? Like my browser caching the relationship: www.bank.com is 1.2.3.4 with pub key XYZ Or is this already implemented and I am too stupid to find it?
silbak04 12y ago
Somewhat relevant: I think Mosh solves a few problems that SSH lacks. This article: https://news.ycombinator.com/item?id=8252093 https://news.ycombinator.com/item?id=8252093 made it on Hacker News a bit ago. The video is wort the watch imo.
otterley 12y ago
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 information can be found here: http://www.psc.edu/index.php/hpn-ssh http://www.psc.edu/index.php/hpn-ssh
- jzila 12y ago
  Are there any plans to patch this into OpenSSH? It looks like they have a great solution for the problem you highlighted.
  - dmm 12y ago
    Those patches are old. My understanding is that the parts that are reasonable have been implemented and the parts that aren't (plaintext modes) have been ignored. If you need to transfer large files around a lot use what the supercomputing centers use: GridFTP.
    - lotsofmangos 12y ago
      I'd never even heard of GridFtp before. It looks pretty good. I've taken to not installing ftp on servers at all and just using ssh, but this might make me think again.
- bodyfour 12y ago
  > scp and sftp were added after the fact scp was there from the beginning, or thereabouts. It certainly was present the first time I played with it which was within a few months of the first release. ssh was specifically designed as a replacement for BSD remote tools (rsh/rlogin/rcp) even falling back to those protocols if ssh wasn't available (although the FallBackToRsh option was removed from OpenSSH a decade or so ago I think). That's also why "slogin" is installed as a symlink to "ssh", to keep it similar to rsh/rlogin. It only made sense for there to be a "scp" to work like the existing "rcp". You are right that sftp only came later.
malkia 12y ago
Because schools and filtering software
malkia 12y ago
Because schools and filtering software
ashish01 12y ago
Would be great to do this for mosh - mosh-chat It improves over SSH by handling intermittent network connections.
- Shish2k 12y ago
  mosh isn't a data stream tool like ssh though, it's actually more like VNC -- the reason it performs better is that it sends snapshots of the terminal over UDP, allowing random packets to be dropped
throwaway593 12y ago
> Why aren’t we using SSH for everything? Because it doesn't support virtual hosts. And I can't afford 30 IPs for my server. Otherwise, it's a great protocol.
- TylerE 12y ago
  Couldn't you use the same IP and different ports? There's nothing magic about port 22 - and in fact on production servers you should almost certainly change 22 to something else.
kgilpin 12y ago
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.
- dllthomas 12y ago
  Of course, you need to trust the remote systems...
- dsl 12y ago
  SSH agent forwarding is extremely risky. Anyone with appropriate permissions (legitimate or illegitimately gained) on a machine you have connected to can use your credentials to open a new connection to any machine you have access to.
  - Sevrene 12y ago
    This is a very valid issue. I have been using ssh-ident* for this reason. You can add keys to ~/.ssh/identities and it'll start up an agent for each identity when you use it. This means if the machine you connect to is indeed stealing your keys, at least they only have one key, not all the keys you're currently using. There are some caveats; such as having to specify what domains/IPs should use which identity, and also having to alias ssh to get it to work nicely. So it's not perfect, but it does solve the problem you talked about. * https://github.com/ccontavalli/ssh-ident https://github.com/ccontavalli/ssh-ident
  - btown 12y ago
    > on a machine you have connected to Don't you have to be actively connected to the machine for this to work? i.e. the server I haven't connected to for a few months has no way of opening connections on my behalf at this point, right?
bondolo 12y ago
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).
- dllthomas 12y ago
  I'd love to see a project to make this suck less.
- dredmorbius 12y ago
  But SSH keys really don't matter. In PGP/GPG, key persistence matters because you're using them to decrypt messages. Long after content was created you may need the key to decrypt it. For SSH, the key is only strictly necessary during the session. Key distribution* (of your public key to systems you need access to) is a bit of a pain, but between having your private key(s) where you need them, and authorized keys on various servers, there's not all that much to worry about. Host keys, perhaps, if you want to be rigorous about security.
peterwwillis 12y ago
What the...? Does the author just not know anything about SSH, or web browsers? Why would we use SSH for everything? On top of the fact that they're entirely different protocols and tools designed for entirely different purposes, browsers already support virtually everything SSH does. File transfers, authentication, client certs, multiplexing, key pinning, etc. There is no need to use SSH, and if you did, it would be slower, less secure, and generally more annoying than using the existing tools built into browsers. I find it aggravating when users read the manual to some software and think they have discovered fire.
- nickpresta 12y ago
  What does this even mean? Your browser supports those things because it implements protocols, like HTTP, TLS, and others. Your browser, or other tools, could support SSH, which I think is the point of the article.
  - peterwwillis 12y ago
    This means the author doesn't know what they're talking about, and is asking a dumb question. The article's title is "Why aren't we using SSH for everything?", not "Why don't browsers support SSH?". Both make no sense. It's like asking why FTP clients don't support Voice-over-IP.
101914 12y ago
MOre interesting question: Why aren't we using SSH-style authentication for everything? And although they can be used with SSH, I do not mean certificates.
- iancarroll 12y ago
  I don't see why client side certificate authentication is excluded? You can easily self sign and create your own CA. There aren't really any downsides. Putty with cryptoapi support exists.
codingthebeach 12y ago
It was difficult for me to get past the self-referential (and reverential) tone of the writing, which felt more like an advertisement for the author's cleverness than a real discussion of the pros and cons of SSH, but it could be I woke up on the wrong side of the bed this morning.
emmanueloga_ 12y ago
If you rephrase this question like this, the answer is evident: "Why aren't we using a protocol designed to add encryption to pseudo-devices emulating a real text terminal device [1] for everything?" 1: http://en.wikipedia.org/wiki/Pseudo_terminal http://en.wikipedia.org/wiki/Pseudo_terminal
ramigb 12y ago
There is something about Finnish products that make them very strong, Nokia, SSH, Rovio.

270 points by dkua 12y ago

What surprises me is the lack of total CLI control, potentially through SSH and ideally using keys, of your hosting provider's control panel. Whether it's CLI or some form of TUI, it's bound to be faster and more convenient for many developers.

blfr 12y ago
Cloud providers nowadays usually have some sort of CLI clients. OpenStack comes with a full suite[1]. Google rolled out their own for Google Cloud[2]. And if there's nothing official, there are often tools built by users available for interacting with the API. Authentication is based on some sort of shared secret rather than keys though, yes. [1] http://docs.openstack.org/user-guide/content/ch_cli.html http://docs.openstack.org/user-guide/content/ch_cli.html [2] https://cloud.google.com/sdk/gcloud/ https://cloud.google.com/sdk/gcloud/

feld 12y ago

I wonder if his chat server has been hit by a botnet yet trying to ssh in and then sending tons of shell commands

4mnt 12y ago
That would be very interesting to watch (albeit a bit annoying for the people trying to chat)
shazow 12y ago
Lots of people spamming/flooding/DoS'ing "for fun", but no clueless bots stumbling in accidentally yet. Btw previous HN thread about ssh-chat here: https://news.ycombinator.com/item?id=8743374 https://news.ycombinator.com/item?id=8743374

shazow 12y ago

Sorry the title has been revised to "Why aren’t we using SSH for everything?" in case mods see this.

forfengeligfaen 12y ago

If you believe Jacob Appelbaum, we probably should not be using SSH for anything http://media.ccc.de/browse/congress/2014/31c3_-_6258_-_en_-_saal_1_-_201412282030_-_reconstructing_narratives_-_jacob_-_laura_poitras.html#video http://media.ccc.de/browse/congress/2014/31c3_-_6258_-_en_-_...

shazow 12y ago
Yea I was fairly confused about that announcement as I couldn't find anything damning in the released docs about SSH. Do you have a reference to a specific document/slide?
- doctorshady 12y ago
  Spiegel briefly touched on it too; The NSA also has a program with which it claims it can sometimes decrypt the Secure Shell protocol (SSH). This is typically used by systems administrators to log into employees' computers remotely, largely for use in the infrastructure of businesses, core Internet routers and other similarly important systems. The NSA combines the data collected in this manner with other information to leverage access to important systems of interest. (source: http://www.spiegel.de/international/germany/inside-the-nsa-s-war-on-internet-security-a-1010361.html http://www.spiegel.de/international/germany/inside-the-nsa-s... ) Still incredibly vague. If they're archiving all traffic in hopes of decrypting it some day though, it's safe to say we should treat anything on the internet as the shiny side of one way glass.
- boracay 12y ago
  My guess is that, at least, some router ssh implementation is insecure, possibly not by accident. From the slides: Page 19: "SSH [...] Potentially recover user names and passwords" Page 36: "SSH - often have router configurations and user credentials [...]" http://www.spiegel.de/media/media-35515.pdf http://www.spiegel.de/media/media-35515.pdf
  - shazow 12y ago
    Right, I saw that also. Is it referring to routers that happen to run SSH with default root/admin passwords or something? I couldn't find anything more concrete.

falcolas 12y ago

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?

XorNot 12y ago
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.
- falcolas 12y ago
  Good answer. If I had to guess, the reason would be threefold. One, it requires tuning on both ends of the connection to make the high speed transfers work well (and it looks like it will interfere with multiplexing as well, the reason the fixed window exists in the first place). Two, the "none" cypher which it enables completely undermines the security of the secure shell. The cypher renegotiation after authentication would make it trivial to MITM the connection. You could probably disable the cypher after every transfer by restarting the sshd daemon, but that's being a bit optimistic. Finally, there is no visible license on the patchfile, or on the homepage. The project's sourceforge page lists it as being BSD licensed, but there is no indication from the author that this is the case. http://www.psc.edu/index.php/hpn-ssh http://www.psc.edu/index.php/hpn-ssh
- acdha 12y ago
  > 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.

higherpurpose 12y ago

I read somewhere that SSH can be MITM'ed by a global adversary on the first visit (before it establishes the secure connection). Is that true?

forgottenpass 12y ago
It can be MITM-ed on any connection. Whether you approve the host fingerprint is, and has always been, entirely up to you.
- singlow 12y ago
  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.
  - XorNot 12y ago
    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 provide a way for me to make that information easily available globally to other clients which might be aware of this system.
    - ytjohn 12y ago
      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 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.
12y ago

forgottenpass 12y ago

Why aren’t we using SSH for everything? Because "Use X for everything" is a terrible design decision? SSH uses flexible transport with some desirable features and may be underutilized in practice. This question is starting to feel like people who want to staple every pie in the sky idea to the bitcoin blockchain because it too has a set of desirable properties.

shazow 12y ago
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.
- blfr 12y ago
  Someone has to be running NetBSD on their microwave owen. I remember a toaster story. http://www.embeddedarm.com/software/arm-netbsd-toaster.php http://www.embeddedarm.com/software/arm-netbsd-toaster.php
- marcosdumay 12y ago
  > we could be using SSH if we had better library support It's the firewall rules, not library availability.
  - Shish2k 12y ago
    Tunnel SSH over HTTP, best (worst) of both worlds :) (I have tried this; it is both useful and terrible)
    - bashinator 12y ago
      Or you could just run `sshd` on port 443.
      - dec0dedab0de 12y ago

josephg 12y ago

Because SSH requires several seconds to initiate a session, even on a local LAN. Does anyone know why this is the case? Its always baffled me.

shazow 12y ago
It shouldn't take much longer than an HTTPS connection, could be something with your server configuration or latency?
scott_karana 12y ago
TLS also takes some time to initiate a session, but that hasn't turned anyone off SPDY, since it supports concurrency from then onwards. :-)
agwa 12y ago
Initiating an SSH connection takes 300ms on my LAN. If it's taking you several seconds then you probably have a reverse DNS problem. (By default, the SSH server looks up the reverse DNS of the client when it connects.)
encoded 12y ago
It could also be your shell on the remote host taking it's time. Some distros have gotten a bit bloated.
geoffc 12y ago
Slow SSH session is usually a DNS issue.
monksy 12y ago
Thats probably because the server is trying to lookup the client on DNS: http://www.turnkeylinux.org/blog/slow-ssh http://www.turnkeylinux.org/blog/slow-ssh
_JamesA_ 12y ago
You may be experiencing the GSSAPIAuthentication delay. The -v flag will help identify where the connection is being delayed. ssh -v [user@]hostname [command] Try connecting with the option disabled. ssh -o GSSAPIAuthentication=no [user@]hostname [command] You can globally disable GSSAPIAuthentication in ssh config: echo 'GSSAPIAuthentication=no' >> ~/.ssh/config

sharpneli 12y ago

SSH can really be used for almost everything. It's a different thing if it actually _should_ be used for everything. My favourite one: http://en.wikipedia.org/wiki/SSHFS http://en.wikipedia.org/wiki/SSHFS Whenever I'm developing for my mobile phone I actually have the contents mounted on my desktop via sshfs as an actual filesystem. What that means? Don't bother with FTP servers. ssh access to your server is all you need.

ivan_ah 12y ago

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)

SilasX 12y ago
Have you tried the autossh utility? That's what I use to keep up long-term tunnels.
- otterley 12y ago
  The window size issue has to do with bandwidth, not session duration. See, e.g., http://www.psc.edu/index.php/hpn-ssh http://www.psc.edu/index.php/hpn-ssh
alexgartrell 12y ago
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

spydum 12y ago

Interesting idea, but isn't ssh very sluggish when it comes to throughput and latency? Doesn't it cost quite a bit more in CPU? I'd hate to make ssh the protocol replacement for http for a busy site.

monksy 12y ago
It depends on the clipher you're using and the implementation/hardware.
- otterley 12y ago
  It depends more on the TCP window size; OpenSSH uses a small one by default and it cannot be changed. See also http://www.psc.edu/index.php/hpn-ssh http://www.psc.edu/index.php/hpn-ssh

sysk 12y ago

It's not clear to me how SSH differs from SSL/TLS conceptually. It seems to me both achieve similar goals (encrypted tunnel, client/server authentication). Perhaps we should take the best bits of both protocols and create a new one? But then, I am reminded of http://xkcd.com/927/ http://xkcd.com/927/.

peterwwillis 12y ago
SSH is designed to serve a single service on a single host. It distributes its host key on the first connection and caches it indefinitely, assuming it will never change. SSH is designed with a limited set of protocol features, and everything else is kind of hacked on top of proprietary client/server pairs. SSH is designed as a loose encrypted session (kind of like a pipe) for an application on a host. TLS is designed to serve multiple services on multiple hosts. It depends on your browser trusting an intermediary host which validates the host key, so (in theory) the initial connection can't be MITM'd, and so the key can change at any time or there can be multiple keys (which is needed for hosting multiple services on multiple hosts). TLS is designed to integrate tightly into an application. When you compare the two protocols, TLS is clearly superior to SSH. But in terms of the features they support (tunneling, authentication, etc), it's up to the server to add missing features outside of the protocol to provide for what the client wants to do. For example, the SSH protocol basically provides an encrypted connection through which you can do whatever you want, similar to TLS. To do IP tunneling with SSH the application server activates extra functionality to connect the encrypted session to a driver which opens an IP tunnel. Or to authenticate your ssh session against a kerberos server, the ssh server does the actual kerberos authentication; the protocol just informs the client of what 'basic' methods they can use, and the client tries to use one that works with the server's methods. Incidentally, TLS the protocol supports client certificate authentication, which provides similar functionality to SSH's public keys. The HTTP protocol also does certificate pinning.
- onnoonno 12y ago
  Maybe it would be nice then if TLS would somehow cache host keys, too? Like my browser caching the relationship: www.bank.com is 1.2.3.4 with pub key XYZ Or is this already implemented and I am too stupid to find it?

silbak04 12y ago

Somewhat relevant: I think Mosh solves a few problems that SSH lacks. This article: https://news.ycombinator.com/item?id=8252093 https://news.ycombinator.com/item?id=8252093 made it on Hacker News a bit ago. The video is wort the watch imo.

otterley 12y ago

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 information can be found here: http://www.psc.edu/index.php/hpn-ssh http://www.psc.edu/index.php/hpn-ssh

jzila 12y ago
Are there any plans to patch this into OpenSSH? It looks like they have a great solution for the problem you highlighted.
- dmm 12y ago
  Those patches are old. My understanding is that the parts that are reasonable have been implemented and the parts that aren't (plaintext modes) have been ignored. If you need to transfer large files around a lot use what the supercomputing centers use: GridFTP.
  - lotsofmangos 12y ago
    I'd never even heard of GridFtp before. It looks pretty good. I've taken to not installing ftp on servers at all and just using ssh, but this might make me think again.
bodyfour 12y ago
> scp and sftp were added after the fact scp was there from the beginning, or thereabouts. It certainly was present the first time I played with it which was within a few months of the first release. ssh was specifically designed as a replacement for BSD remote tools (rsh/rlogin/rcp) even falling back to those protocols if ssh wasn't available (although the FallBackToRsh option was removed from OpenSSH a decade or so ago I think). That's also why "slogin" is installed as a symlink to "ssh", to keep it similar to rsh/rlogin. It only made sense for there to be a "scp" to work like the existing "rcp". You are right that sftp only came later.

malkia 12y ago

Because schools and filtering software

malkia 12y ago

Because schools and filtering software

ashish01 12y ago

Would be great to do this for mosh - mosh-chat It improves over SSH by handling intermittent network connections.

Shish2k 12y ago
mosh isn't a data stream tool like ssh though, it's actually more like VNC -- the reason it performs better is that it sends snapshots of the terminal over UDP, allowing random packets to be dropped

throwaway593 12y ago

> Why aren’t we using SSH for everything? Because it doesn't support virtual hosts. And I can't afford 30 IPs for my server. Otherwise, it's a great protocol.

TylerE 12y ago
Couldn't you use the same IP and different ports? There's nothing magic about port 22 - and in fact on production servers you should almost certainly change 22 to something else.

kgilpin 12y ago

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.

dllthomas 12y ago
Of course, you need to trust the remote systems...
dsl 12y ago
SSH agent forwarding is extremely risky. Anyone with appropriate permissions (legitimate or illegitimately gained) on a machine you have connected to can use your credentials to open a new connection to any machine you have access to.
- Sevrene 12y ago
  This is a very valid issue. I have been using ssh-ident* for this reason. You can add keys to ~/.ssh/identities and it'll start up an agent for each identity when you use it. This means if the machine you connect to is indeed stealing your keys, at least they only have one key, not all the keys you're currently using. There are some caveats; such as having to specify what domains/IPs should use which identity, and also having to alias ssh to get it to work nicely. So it's not perfect, but it does solve the problem you talked about. * https://github.com/ccontavalli/ssh-ident https://github.com/ccontavalli/ssh-ident
- btown 12y ago
  > on a machine you have connected to Don't you have to be actively connected to the machine for this to work? i.e. the server I haven't connected to for a few months has no way of opening connections on my behalf at this point, right?

bondolo 12y ago

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).

dllthomas 12y ago
I'd love to see a project to make this suck less.
dredmorbius 12y ago
But SSH keys really don't matter. In PGP/GPG, key persistence matters because you're using them to decrypt messages. Long after content was created you may need the key to decrypt it. For SSH, the key is only strictly necessary during the session. Key distribution* (of your public key to systems you need access to) is a bit of a pain, but between having your private key(s) where you need them, and authorized keys on various servers, there's not all that much to worry about. Host keys, perhaps, if you want to be rigorous about security.

peterwwillis 12y ago

What the...? Does the author just not know anything about SSH, or web browsers? Why would we use SSH for everything? On top of the fact that they're entirely different protocols and tools designed for entirely different purposes, browsers already support virtually everything SSH does. File transfers, authentication, client certs, multiplexing, key pinning, etc. There is no need to use SSH, and if you did, it would be slower, less secure, and generally more annoying than using the existing tools built into browsers. I find it aggravating when users read the manual to some software and think they have discovered fire.

nickpresta 12y ago
What does this even mean? Your browser supports those things because it implements protocols, like HTTP, TLS, and others. Your browser, or other tools, could support SSH, which I think is the point of the article.
- peterwwillis 12y ago
  This means the author doesn't know what they're talking about, and is asking a dumb question. The article's title is "Why aren't we using SSH for everything?", not "Why don't browsers support SSH?". Both make no sense. It's like asking why FTP clients don't support Voice-over-IP.

101914 12y ago

MOre interesting question: Why aren't we using SSH-style authentication for everything? And although they can be used with SSH, I do not mean certificates.

iancarroll 12y ago
I don't see why client side certificate authentication is excluded? You can easily self sign and create your own CA. There aren't really any downsides. Putty with cryptoapi support exists.

codingthebeach 12y ago

It was difficult for me to get past the self-referential (and reverential) tone of the writing, which felt more like an advertisement for the author's cleverness than a real discussion of the pros and cons of SSH, but it could be I woke up on the wrong side of the bed this morning.

emmanueloga_ 12y ago

If you rephrase this question like this, the answer is evident: "Why aren't we using a protocol designed to add encryption to pseudo-devices emulating a real text terminal device [1] for everything?" 1: http://en.wikipedia.org/wiki/Pseudo_terminal http://en.wikipedia.org/wiki/Pseudo_terminal

ramigb 12y ago

There is something about Finnish products that make them very strong, Nokia, SSH, Rovio.