20 ms·

Why aren’t we using SSH for everything?

308 points by joshmanders 10y ago

twothamendment 10y ago
No comments here because everyone is chatting about it at chat.shazow.net?
- shazow 10y ago
  Pretty much. :)
adrusi 10y ago
(2015) previous discussion: https://news.ycombinator.com/item?id=8828543 https://news.ycombinator.com/item?id=8828543 https://news.ycombinator.com/item?id=11516582 https://news.ycombinator.com/item?id=11516582 It's been posted twice in the last day, I wonder where it reemerged.
- joshmanders 10y ago
  I saw it on Lobste.rs and did a quick search for the url but it returned nothing. Medium articles suck with that hash they put on. Thought it was worthy of submitting here.
  - loader 10y ago
    I thought it was a good read, oh and small world eh?
    - joshmanders 10y ago
      > small world eh? Haha indeed it is!
- shazow 10y ago
  I've been pushing a bunch of changes on Github, maybe that's how somebody noticed it?
onion2k 10y ago
"It doesn't work because you generated your key with RSA instead of moduli-2048" is not a conversation I want to have with my mother. Until the tools to deal with SSH keys are a lot more user friendly, it won't be used much by the wider public.
- theandrewbailey 10y ago
  Agreed. How easy is it to remember a password vs. keep a sensitive file (in an obscure place) for years?
  - daveloyall 10y ago
    Is the file a word doc in c:\Documents and Settings\PC OWNER\desktop? :)
fiatjaf 10y ago
Because inventing new protocols is cooler.
- abstractbeliefs 10y ago
  Sadly, we don't even invent new protocols any more, at least not open ones. What we do is invent new, closed platforms like Slack (and HipChat and Campfire before it).
  - digi_owl 10y ago
    And even the open ones get saturated in proprietary extensions in no time...
  - erlehmann_ 10y ago
    Besides the obvious hype and hipster “this time its different” appeal, is there any technical reason one would would prefer Slack over, say, XMPP? I looked into it only until I realized one has to pay to access chat history.
    - vacri 10y ago
      Slack gives you a unified chat stream and a simple, buttery-smooth onboarding process for the tech-naifs. Jabber does neither of these. I'm not fond of Slack in particular, as it's ridiculously expensive and the main chat window is too widely spaced, even with mods. I use jabber with a friend, and frequently messages go to his other laptop, which he doesn't see until he logs onto it. Same in reverse. Similarly, history isn't unified. You can get around these problems by having your own centralised jabber chat client (like bitlbee), but that's a technician's answer, not an answer for the general public.
- throwanem 10y ago
  And >90% of the cases detailed here are covered by an IRC server with TLS and certificate authentication, and you can even use it on a mobile device with the kind of humane, task-focused UI that a general-purpose SSH client can't provide.
verandaguy 10y ago
As tempting as it is to use SSH everywhere (for exactly the reasons outlined here), other protocols exist because they usually have some form of marginal gains over the alternatives, and marginal gains matter at scale. Encrpytion isn't always something that's needed (arguably; though I'm all for enabling it everywhere it can be enabled), and in places where it's not critical, it adds performance overhead both client- and server-side. SSH also has to be shoehorned into distributed chat applications, for example, else the interface deters inexperienced users and, again, almost inevitably, overhead is incurred. Using PGP for authentication and encryption in this case is a saner choice because it supports decryption by groups of recipients, and implementing a protocol over UDP (or even TCP) is plenty. EDIT: Just to be clear, though, there are some pretty cool nonstandard uses of SSH out there. Medium OP's chat server is a great example.
- LinuxBender 10y ago
  There are also some significant vulnerabilities [1] in SSH by design / by default that must be disabled if used everywhere. [1] https://news.ycombinator.com/item?id=11052745 https://news.ycombinator.com/item?id=11052745
  - arielb1 10y ago
    It is very easy to write a virus that is not detected by any anti-virus. I don't see how dropping an SSH key on some machine is worse than dropping a remote shell on it. It's not like SSH keys are stealthy or something - any sysadmin worth his salt will occasionally look at his authorized_keys list.
    - mscman 10y ago
      > any sysadmin worth his salt will have automated the population of his authorized_keys file and alert on any unauthorized changes. FTFY
      - mhurron 10y ago
        That appears to be surprisingly uncommon. By that I mean maintaining the authorized keys file at all.
sdkmvx 10y ago
> When you join ssh-chat, not only do I know who you claim to be, but I can also permanently and securely attach an identity to your connection without any user intervention on your part. A great part of IRC is that there's no registration. There's no identity.
- KirinDave 10y ago
  That's... not true at all? Nickserv and Chanserv are essential parts of modern IRC and in practice people need a consistent identity to interact with most channels.
  - TheGorramBatman 10y ago
    You don't need chanserv and you don't need nickserv. Efnet isn't dead -- it's just coughing up blood. (yes, it has ChanFix).
  - aluhut 10y ago
    Most? Essential? Not really. I can hop into most of the channels with a different nick every time. Nobody cares. I can even use the same one without registering it as long as nobody else does that. I can open a chan without being registered and enforce rules in there. The only time I need to register something is when I want to keep the channel alive and still be OP when I come back, when I want to keep my nick or when the chan owner requires me to register. Which is all not "most channels".
    - progval 10y ago
      Some channels ban non-registered users to protect themselves against spam.
- daveloyall 10y ago
  You must be from EFnet. Hello! :)
- jessaustin 10y ago
  There doesn't have to be registration or a consistent identity with ssh, when it's used as described in TFA. Just pass a different identity file with "-i". Of course, most uses of ssh would use a preestablished account on a host and that wouldn't vary, but there's nothing in the protocol requiring that.
karmicthreat 10y ago
Until a recent version you couldn't even have a .d directory to hold a bunch of config files to simplify contacting your servers.
- throwanem 10y ago
  Oh neat, is that a thing now? I ask because I hacked up something a couple years back to let me manage files in ~/.ssh/config.d, plus a Makefile that produced ~/.ssh/config from them and a set of shims for OpenSSH commands which would run make before running ssh, scp, etc., to make sure the live config stayed up to date with changes in .d files. But I haven't used that pile of shell scripts or looked at it in a while, so it's probably started to smell a bit, and it would therefore be nice if this were a thing OpenSSH itself can now do.
  - karmicthreat 10y ago
    I think everyone that uses ssh heavily ends up making some form of that script. Now I'm waiting for Apple to adopt a newer version of openssh
  - icebraining 10y ago
    Oh neat, is that a thing now? Yeah, since this Monday: http://www.openssh.com/txt/release-7.3 http://www.openssh.com/txt/release-7.3
- shabble 10y ago
  I started writing a FUSE fs specifically for this (and other fun dynamic .ssh/ things), but never got round to finishing it off. The wildcard and (very recent) .d support has mostly solved the need now, unless I can remember what exactly it was I couldn't get it to do before.
kazinator 10y ago
SSH chat does not ensure that "I know who you claim to be". Only that "I know you're someone who has access to the same SSH key as that someone with whom I was talking yesterday". In terms of authentication, that is about on par with an IRC "nickbot".
- jessaustin 10y ago
  That's TOFU-POP, and it's perfectly reasonable for many situations. For example, HN.
  - throwanem 10y ago
    For others who've never before run into that particular acronym, it glosses per [1] to "Trust On First Use/Persistence of Pseudonym". [1] https://lists.gnupg.org/pipermail/gnupg-devel/2014-March/028350.html https://lists.gnupg.org/pipermail/gnupg-devel/2014-March/028...
- arielb1 10y ago
  There's nothing preventing you from transporting an SSH public key over some other secured channel. Then it's "I know that you are someone that has access to the SSH key transported over that secure channel".
ericfrederich 10y ago
... probably because it requires a central server which the industry is moving against? Things are moving to distributed.
- RubberShoes 10y ago
  I beg to differ http://www.techrepublic.com/article/amazon-cfo-said-these-3-factors-are-the-reason-for-aws-revenue-explosion/ http://www.techrepublic.com/article/amazon-cfo-said-these-3-...
aagat 10y ago
If anyone is interested seeing another interesting service, our organization is currently developing user onboarding over SSH (WIP). All sources are public [1] and easy to follow/read. It's written in nodejs and has nice blessed/blessed-contrib based UI. [1] https://github.com/hashbang/signup-ssh https://github.com/hashbang/signup-ssh
- daveloyall 10y ago
  The hashbang people are doing a LOT of interesting things. What's nice is that they aren't waiting to get the whole internet onboard with their ideas, they are building the services now. The best part is that (theoretically), you could install their software on a machine of your own and it would then be capable of providing services to their users.
saynsedit 10y ago
While SSH seems like the ideal console application delivery platform, it suffers in a major way: no local execution. This matters when latency matters. Processing all keystrokes remotely sucks over high-latency links like airplanes, cell phones, satellites, etc. This can also be a pro. JavaScript is a mess in terms of design, increased client complexity, and security. It depends on what your requirements are.
- snuxoll 10y ago
  This is actually one area where I like our IBM i system, the 5250 console may be extremely lacking in many features compared to say a VT100, but the block-based console eliminates the remote server from needing to handle redrawing or dealing with input until the user explicitly requests an action. It's pretty amazing to see a thousand users connected to the box and none of them have any latency with inputting data (getting a new screen back from the server make take a couple milliseconds) because it's all done locally until they press a function key or some other action button that pushes the data off to the server.
  - wrs 10y ago
    The same description would apply to HTML forms in the browser. In fact there are HTTP gateways that translate IBM forms to HTML on the fly.
- dbalan 10y ago
  Mosh helps in this case, they buffer the keystrokes and liberates user frustration by giving a visual response. [1] https://mosh.mit.edu https://mosh.mit.edu
  - icebraining 10y ago
    Yeah, but it's not SSH anymore (except for the authentication), it's a custom protocol based on UDP.
- dingaling 10y ago
  Using compression with -C argument helps keystroke buffering on high-latency connections and also protects against several crypto attacks. It also makes sense on LAN connections, instead of sending each character at a time...
rradish 10y ago
Excellent explanation of how ssh works along the way, to boot.
rradish 10y ago
Excellent explanation of how ssh works, to boot.
shazow 10y ago
Hey everyone, thanks for dropping by the main ssh-chat server (chat.shazow.net). That one is running a fairly old version of the software (/uptime -> 13579h33m20.784837542s). I just deployed the latest Github release on an east-coast server here, please come help test it: ssh chat2.shazow.net Binary releases are available here if you're interested in running your own: https://github.com/shazow/ssh-chat/releases/ https://github.com/shazow/ssh-chat/releases/
- xrattlesnake 10y ago
  getting a connection refused error ssh: connect to host chat2.shazow.net port 22: Connection refused
  - shazow 10y ago
    There's a bug that is crashing it, alas. https://github.com/shazow/ssh-chat/issues/166 https://github.com/shazow/ssh-chat/issues/166 Pretty sure the bug is in the autocomplete function, if anyone wants to tackle it. I might disable it for now.
    - deleted 10y ago
      [deleted]
    - smellf 10y ago
      Jerks are also piping /dev/random into it, looks like that may be crashing it.
      - verroq 10y ago
        I guess we can't use ssh for everything.
        Cpoll 10y ago
        That's not ssh's fault; you can pipe /dev/random into just about anything and get the same result. Rate-limiting isn't the job of the protocol, in this case - it's the job of the chat server application.
erlehmann_ 10y ago
Regarding the question, I use SSHFS to mount directories on remote machines: https://en.wikipedia.org/wiki/SSHFS https://en.wikipedia.org/wiki/SSHFS
- leephillips 10y ago
  sshfs is so simple; I don't know why people seem to default to using nfs.
  - beagle3 10y ago
    performance. sshfs is dog slow compared to NFS on a local network. Also, coherence: sshfs manages to hide a lot of the ugly details, but you'll meet coherence problems on sshfs much more often than on nfs. They both do aggressive caching, but nfs gets help from the server side and is thus usually better.
    - leephillips 10y ago
      Both good reasons. My personal use case happens to make these issues unimportant: mounting remote file stores that are only accessed by me. But I guess for mulitply-accessed files on the local network, nfs headaches may be worth the trouble.
    - vacri 10y ago
      > performance. sshfs is dog slow I'd started using ssfs for something and found this slowness issue. I asked my mentor about what could be done to improve it, and he said "If you're using sshfs, you've already lost". 'scp' is very slow as well. Anything bigger than a small text file gets rsync'd. Small text files get scp'd, because remembering rsync flags is a minor annoyance :)
gluczywo 10y ago
SSH lacks a key distribution/certification model for server authentication. The article describes server authentication (in the section with misleading title "SSH connections are encrypted") but does not mention the fact that fingerprint should be sent over another secure channel and manually verified.
- rocqua 10y ago
  assuming the server you are connecting to has DNSSEC, SSHFP is the taylor made solution for this problem.
- geggam 10y ago
  https://www.digitalocean.com/community/tutorials/how-to-create-an-ssh-ca-to-validate-hosts-and-clients-with-ubuntu https://www.digitalocean.com/community/tutorials/how-to-crea...
- e12e 10y ago
  In addition to the fact that openssh has supported certificate authentication of both servers and users for years -- the easiest way to bootstrap "traditional" ssh keys is probably just to list the public ssh host keys on a web page secured by https/tls. It'll be just as insecure as the rest of the x509 CA-based cluster-fuck -- but at least it's easier to automate and less error prone than manually checking fingerprints. So, not saying you're wrong, but that while advice regarding "fingerprints" is technically correct, just adding "the correct" keys to known hosts is probably the more practical -- and in practice more secure -- solution. That is of course assuming that like the rest of the world setting up an actually secure solution using ssh-keygen seems like too much work (I'm myself guilty of this, for my personal servers it's easier to just stick with manual keys - it's also hopelessly insecure and inconvenient in the case of a breach or other reason to rotate keys).
KirinDave 10y ago
We're not using it because... well... it's weird (for lack of a better word)? Sure, it's a multiplexing protocol that can support a few neat use cases like port forwarding and X11 tunneling, but that's really not what we want in most cases. It carries a lot of baggage in its clients and implementations that in principle shouldn't cause problems but in practice makes it suboptimal. One of the most important aspects of why we don't use it: it's scary to work with. SSH's implementation of its protocol is much closer to the actual client implementation than the divide traditionally maintained between SSL and its clients. People are rightly afraid to get close to cryptographic code without sufficient training, and so there is the equivalent of a "If You Are Responsible: Keep Away" sign for most developers who might be inclined to improve the situation. Still, the community found the impetus to augment the protocol and UI to help deal with latency issues that plague SSH via Mosh. It helps escape the legacy idea that RTTs will be consistent and therefore are ignorable in a shell implementation. Ultimately, SSL is a better understood tunneling protocol and full of a lot less... maybe it's just the perspective we have in a world where SSL is ubiquitous but SSH is weird. Its rules are weird, its certificates are weird, its tooling is weird. This is a common contention in Hacker News I'm often on the minority size of, but I submit that while syntactic interfaces (shell, programming) has clearly demonstrated its value and deserves to be better developed, the same can not be said for serial text entry interfaces. Something based around a streaming query protocol like SSL+HTTP/2 that makes some fundamentally different decisions than the legacy UNIX shell and supporting tooling would be substantially better, and be able to use existing web browser techniques and software. Which is all abstract, but imagine for a moment something we've seen before: an Electron Shell based terminal. But what we haven't seen is someone really dive in and attempt to redefine the world around shells. So bear with me for a second... Imagine an Electron Shell based terminal experience that works locally and remotely. A line buffer separate from the display accumulates and maintains the current prompt (because instead of PS1 being pseudo-executable in our shell it actually can attach scripting functions and web-browser style timers). Executables logically return open dictionary objects (which can contain streams) instead of the current fixed set of indexed streams. We can use 0, 1 and 2 as legacy keys into these objects to maintain compatibility. But you could imagine a "rich-1" key that actually outputs rich markup, "error-1" that outputs rich markup for error, etc. And of course, media itself could either be file system references. These rich objects are just textual objects with references to valid HTTP/2 requests do what they do. This actually resembles SSH's protocol on the outside, but using tools that are reusable elsewhere and a cryptographic stack and transit protocol that has more funding and attention and traction.
devicenull 10y ago
> Or better yet, ZeroMQ-style sockets with proper security and encryption? ZeroMQ supports CURVE encryption + authentication as of 4.0 http://hintjens.com/blog:49 http://hintjens.com/blog:49
jvehent 10y ago
> Why aren’t we using SSH for everything? Because when you have 100,000 users and you need to rotate your host key following a leak, the team in charge of user retention has a heart attack.
- deckar01 10y ago
  Informing users when your keys were leaked is more important than user retention. Hiding your weaknesses does not build trust.
  - jvehent 10y ago
    You're missing the point: SSH does not provide a host key rotation/revocation mechanism. TLS does.
    - deckar01 10y ago
      You said that you are afraid of loosing users after a leak, which implies if you don't have to, you won't tell your users about the incident.
      - eximius 10y ago
        No, its that the fix is client side and painful. They can tell their users to fix it and they would rather leave than do it.
        deckar01 10y ago
        I thought users would be prompted to accept a new fingerprint. Am I missing something?
        billyhoffman 10y ago
        If by "prompted" you mean: @ WARNING: REMOTE HOST IDENTIFICATION HAS CHANGED! @ IT IS POSSIBLE THAT SOMONE IS DOING SOMETHING NASTY! Someone could be eavesdropping on you right now! Then, yes, users will be prompted in the scariest possible language. Compare this with HTTPS/browsers, which care not a lick if a certificate/fingerprint is different, provided that the certificate is valid and the chain is trusted.
deckar01 10y ago
I added SSH authentication to the roadmap for the API in one of my projects. I love the UX of the first connection from a new users acting as registration. When I looked for information on how git SSH servers are implemented I did not find enough information to get started. Can anyone recommended reading for someone getting started with an API over SSH?
- mhotchen 10y ago
  I looked at it a while ago using OpenSSH's AuthorizedKeysCommand feature and found Phabricator's implementation for vcs over SSH to be the most understandable thing I could find. https://github.com/phacility/phabricator/blob/master/resources/sshd/sshd_config.phabricator.example https://github.com/phacility/phabricator/blob/master/resourc... https://github.com/phacility/phabricator/blob/master/resources/sshd/phabricator-ssh-hook.sh https://github.com/phacility/phabricator/blob/master/resourc... https://github.com/phacility/phabricator/blob/master/scripts/ssh/ssh-auth.php https://github.com/phacility/phabricator/blob/master/scripts...
jagheterfredrik 10y ago
I made a toy SSH API thingie a couple of months back; https://github.com/jagheterfredrik/sheet https://github.com/jagheterfredrik/sheet
hatsunearu 10y ago
It's great if you can leverage the SSH keying system, but using SSH "raw" for anything high-bandwidth is a disaster (try using sshfs on a high latency network, you will get two digit kilobytes when you know the network connection can sustain a megabyte)
placeybordeaux 10y ago
If you look around there are cases of using ssh for various things, but at the end of the day HTTP is the protocol of the masses, you aren't going to beat it's adoption. plenty of nethack servers that you can ssh into here: https://nethackwiki.com/wiki/Public_server https://nethackwiki.com/wiki/Public_server Another rougelike: http://crawl.develz.org/wordpress/howto http://crawl.develz.org/wordpress/howto
zyxley 10y ago
SSH passing username by default is actually one of the things I hate about it.
- shabble 10y ago
  Why? not much of an info-leak if you know where you're connecting, and it has to use something, or enforce a foo@host string. You could work around it with something like: Host * User WhosAsking in your ~/.ssh/config (at the end of the file, so other entries can override it)
jheriko 10y ago
round trip times. it makes somethings impossible with that much interchange required to send anything - and it will never go away because the speed of light is a hard limit.
pt 10y ago
Do TLS client certificates make HTTPS equivalent to SSH?
- ibotty 10y ago
  No. Disregarding technicalities of which there are many, the most important difference is that with ssh you either get the host key through a different secure channel or "trust on first use" (TOFU). With HTTPS you trust certificate authorities (CA).
  - pt 10y ago
    I was referring to the browser side certificate that can be generated using the <keygen> tag, and then used for the subsequent HTTPS sessions. Would this be equivalent to ssh-keygen for SSH?
    - ibotty 10y ago
      That's deprecated though and afaik, that's only the client-side authentication, not the server-side. That still relies on CAs, with all the disadvantages.
based2 10y ago
https://www.ietf.org/mail-archive/web/tls/current/msg12133.html https://www.ietf.org/mail-archive/web/tls/current/msg12133.h...
e12e 10y ago
Why aren't we using ipv6 with ipsec for everything? Then we could just stick with rsh, telnet and http... I honestly think that the time has come to turn back the clock, and move forward with that approach. We've time and time again proved that "mostly encrypted" is almost impossible to get right, and almost never what we really want. We've also shown that we really do care about authenticating the servers we communicate with. With the recent advances in cpu power, ram (and custom hardware) -- there's not much reason not just encrypt and authenticate all the things any more. In the 90s, doing full ipsec and ipv6 everywhere was expensive: new switches and network hardware was needed, and the overhead of encryption was way too high. But now the time should be right. Still not all that hopeful that we'll actually get there, though.
mankash666 10y ago
For one thing many corporate firewalls filter port 22 even got outbound traffic

308 points by joshmanders 10y ago

twothamendment 10y ago

No comments here because everyone is chatting about it at chat.shazow.net?

shazow 10y ago
Pretty much. :)

adrusi 10y ago

(2015) previous discussion: https://news.ycombinator.com/item?id=8828543 https://news.ycombinator.com/item?id=8828543 https://news.ycombinator.com/item?id=11516582 https://news.ycombinator.com/item?id=11516582 It's been posted twice in the last day, I wonder where it reemerged.

joshmanders 10y ago
I saw it on Lobste.rs and did a quick search for the url but it returned nothing. Medium articles suck with that hash they put on. Thought it was worthy of submitting here.
- loader 10y ago
  I thought it was a good read, oh and small world eh?
  - joshmanders 10y ago
    > small world eh? Haha indeed it is!
shazow 10y ago
I've been pushing a bunch of changes on Github, maybe that's how somebody noticed it?

onion2k 10y ago

"It doesn't work because you generated your key with RSA instead of moduli-2048" is not a conversation I want to have with my mother. Until the tools to deal with SSH keys are a lot more user friendly, it won't be used much by the wider public.

theandrewbailey 10y ago
Agreed. How easy is it to remember a password vs. keep a sensitive file (in an obscure place) for years?
- daveloyall 10y ago
  Is the file a word doc in c:\Documents and Settings\PC OWNER\desktop? :)

fiatjaf 10y ago

Because inventing new protocols is cooler.

abstractbeliefs 10y ago
Sadly, we don't even invent new protocols any more, at least not open ones. What we do is invent new, closed platforms like Slack (and HipChat and Campfire before it).
- digi_owl 10y ago
  And even the open ones get saturated in proprietary extensions in no time...
- erlehmann_ 10y ago
  Besides the obvious hype and hipster “this time its different” appeal, is there any technical reason one would would prefer Slack over, say, XMPP? I looked into it only until I realized one has to pay to access chat history.
  - vacri 10y ago
    Slack gives you a unified chat stream and a simple, buttery-smooth onboarding process for the tech-naifs. Jabber does neither of these. I'm not fond of Slack in particular, as it's ridiculously expensive and the main chat window is too widely spaced, even with mods. I use jabber with a friend, and frequently messages go to his other laptop, which he doesn't see until he logs onto it. Same in reverse. Similarly, history isn't unified. You can get around these problems by having your own centralised jabber chat client (like bitlbee), but that's a technician's answer, not an answer for the general public.
throwanem 10y ago
And >90% of the cases detailed here are covered by an IRC server with TLS and certificate authentication, and you can even use it on a mobile device with the kind of humane, task-focused UI that a general-purpose SSH client can't provide.

verandaguy 10y ago

As tempting as it is to use SSH everywhere (for exactly the reasons outlined here), other protocols exist because they usually have some form of marginal gains over the alternatives, and marginal gains matter at scale. Encrpytion isn't always something that's needed (arguably; though I'm all for enabling it everywhere it can be enabled), and in places where it's not critical, it adds performance overhead both client- and server-side. SSH also has to be shoehorned into distributed chat applications, for example, else the interface deters inexperienced users and, again, almost inevitably, overhead is incurred. Using PGP for authentication and encryption in this case is a saner choice because it supports decryption by groups of recipients, and implementing a protocol over UDP (or even TCP) is plenty. EDIT: Just to be clear, though, there are some pretty cool nonstandard uses of SSH out there. Medium OP's chat server is a great example.

LinuxBender 10y ago
There are also some significant vulnerabilities [1] in SSH by design / by default that must be disabled if used everywhere. [1] https://news.ycombinator.com/item?id=11052745 https://news.ycombinator.com/item?id=11052745
- arielb1 10y ago
  It is very easy to write a virus that is not detected by any anti-virus. I don't see how dropping an SSH key on some machine is worse than dropping a remote shell on it. It's not like SSH keys are stealthy or something - any sysadmin worth his salt will occasionally look at his authorized_keys list.
  - mscman 10y ago
    > any sysadmin worth his salt will have automated the population of his authorized_keys file and alert on any unauthorized changes. FTFY
    - mhurron 10y ago
      That appears to be surprisingly uncommon. By that I mean maintaining the authorized keys file at all.

sdkmvx 10y ago

> When you join ssh-chat, not only do I know who you claim to be, but I can also permanently and securely attach an identity to your connection without any user intervention on your part. A great part of IRC is that there's no registration. There's no identity.

KirinDave 10y ago
That's... not true at all? Nickserv and Chanserv are essential parts of modern IRC and in practice people need a consistent identity to interact with most channels.
- TheGorramBatman 10y ago
  You don't need chanserv and you don't need nickserv. Efnet isn't dead -- it's just coughing up blood. (yes, it has ChanFix).
- aluhut 10y ago
  Most? Essential? Not really. I can hop into most of the channels with a different nick every time. Nobody cares. I can even use the same one without registering it as long as nobody else does that. I can open a chan without being registered and enforce rules in there. The only time I need to register something is when I want to keep the channel alive and still be OP when I come back, when I want to keep my nick or when the chan owner requires me to register. Which is all not "most channels".
  - progval 10y ago
    Some channels ban non-registered users to protect themselves against spam.
daveloyall 10y ago
You must be from EFnet. Hello! :)
jessaustin 10y ago
There doesn't have to be registration or a consistent identity with ssh, when it's used as described in TFA. Just pass a different identity file with "-i". Of course, most uses of ssh would use a preestablished account on a host and that wouldn't vary, but there's nothing in the protocol requiring that.

karmicthreat 10y ago

Until a recent version you couldn't even have a .d directory to hold a bunch of config files to simplify contacting your servers.

throwanem 10y ago
Oh neat, is that a thing now? I ask because I hacked up something a couple years back to let me manage files in ~/.ssh/config.d, plus a Makefile that produced ~/.ssh/config from them and a set of shims for OpenSSH commands which would run make before running ssh, scp, etc., to make sure the live config stayed up to date with changes in .d files. But I haven't used that pile of shell scripts or looked at it in a while, so it's probably started to smell a bit, and it would therefore be nice if this were a thing OpenSSH itself can now do.
- karmicthreat 10y ago
  I think everyone that uses ssh heavily ends up making some form of that script. Now I'm waiting for Apple to adopt a newer version of openssh
- icebraining 10y ago
  Oh neat, is that a thing now? Yeah, since this Monday: http://www.openssh.com/txt/release-7.3 http://www.openssh.com/txt/release-7.3
shabble 10y ago
I started writing a FUSE fs specifically for this (and other fun dynamic .ssh/ things), but never got round to finishing it off. The wildcard and (very recent) .d support has mostly solved the need now, unless I can remember what exactly it was I couldn't get it to do before.

kazinator 10y ago

SSH chat does not ensure that "I know who you claim to be". Only that "I know you're someone who has access to the same SSH key as that someone with whom I was talking yesterday". In terms of authentication, that is about on par with an IRC "nickbot".

jessaustin 10y ago
That's TOFU-POP, and it's perfectly reasonable for many situations. For example, HN.
- throwanem 10y ago
  For others who've never before run into that particular acronym, it glosses per [1] to "Trust On First Use/Persistence of Pseudonym". [1] https://lists.gnupg.org/pipermail/gnupg-devel/2014-March/028350.html https://lists.gnupg.org/pipermail/gnupg-devel/2014-March/028...
arielb1 10y ago
There's nothing preventing you from transporting an SSH public key over some other secured channel. Then it's "I know that you are someone that has access to the SSH key transported over that secure channel".

ericfrederich 10y ago

... probably because it requires a central server which the industry is moving against? Things are moving to distributed.

RubberShoes 10y ago
I beg to differ http://www.techrepublic.com/article/amazon-cfo-said-these-3-factors-are-the-reason-for-aws-revenue-explosion/ http://www.techrepublic.com/article/amazon-cfo-said-these-3-...

aagat 10y ago

If anyone is interested seeing another interesting service, our organization is currently developing user onboarding over SSH (WIP). All sources are public [1] and easy to follow/read. It's written in nodejs and has nice blessed/blessed-contrib based UI. [1] https://github.com/hashbang/signup-ssh https://github.com/hashbang/signup-ssh

daveloyall 10y ago
The hashbang people are doing a LOT of interesting things. What's nice is that they aren't waiting to get the whole internet onboard with their ideas, they are building the services now. The best part is that (theoretically), you could install their software on a machine of your own and it would then be capable of providing services to their users.

saynsedit 10y ago

While SSH seems like the ideal console application delivery platform, it suffers in a major way: no local execution. This matters when latency matters. Processing all keystrokes remotely sucks over high-latency links like airplanes, cell phones, satellites, etc. This can also be a pro. JavaScript is a mess in terms of design, increased client complexity, and security. It depends on what your requirements are.

snuxoll 10y ago
This is actually one area where I like our IBM i system, the 5250 console may be extremely lacking in many features compared to say a VT100, but the block-based console eliminates the remote server from needing to handle redrawing or dealing with input until the user explicitly requests an action. It's pretty amazing to see a thousand users connected to the box and none of them have any latency with inputting data (getting a new screen back from the server make take a couple milliseconds) because it's all done locally until they press a function key or some other action button that pushes the data off to the server.
- wrs 10y ago
  The same description would apply to HTML forms in the browser. In fact there are HTTP gateways that translate IBM forms to HTML on the fly.
dbalan 10y ago
Mosh helps in this case, they buffer the keystrokes and liberates user frustration by giving a visual response. [1] https://mosh.mit.edu https://mosh.mit.edu
- icebraining 10y ago
  Yeah, but it's not SSH anymore (except for the authentication), it's a custom protocol based on UDP.
dingaling 10y ago
Using compression with -C argument helps keystroke buffering on high-latency connections and also protects against several crypto attacks. It also makes sense on LAN connections, instead of sending each character at a time...

rradish 10y ago

Excellent explanation of how ssh works along the way, to boot.

rradish 10y ago

Excellent explanation of how ssh works, to boot.

shazow 10y ago

Hey everyone, thanks for dropping by the main ssh-chat server (chat.shazow.net). That one is running a fairly old version of the software (/uptime -> 13579h33m20.784837542s). I just deployed the latest Github release on an east-coast server here, please come help test it: ssh chat2.shazow.net Binary releases are available here if you're interested in running your own: https://github.com/shazow/ssh-chat/releases/ https://github.com/shazow/ssh-chat/releases/

xrattlesnake 10y ago
getting a connection refused error ssh: connect to host chat2.shazow.net port 22: Connection refused
- shazow 10y ago
  There's a bug that is crashing it, alas. https://github.com/shazow/ssh-chat/issues/166 https://github.com/shazow/ssh-chat/issues/166 Pretty sure the bug is in the autocomplete function, if anyone wants to tackle it. I might disable it for now.
  - deleted 10y ago
    [deleted]
  - smellf 10y ago
    Jerks are also piping /dev/random into it, looks like that may be crashing it.
    - verroq 10y ago
      I guess we can't use ssh for everything.
      - Cpoll 10y ago
        That's not ssh's fault; you can pipe /dev/random into just about anything and get the same result. Rate-limiting isn't the job of the protocol, in this case - it's the job of the chat server application.

erlehmann_ 10y ago

Regarding the question, I use SSHFS to mount directories on remote machines: https://en.wikipedia.org/wiki/SSHFS https://en.wikipedia.org/wiki/SSHFS

leephillips 10y ago
sshfs is so simple; I don't know why people seem to default to using nfs.
- beagle3 10y ago
  performance. sshfs is dog slow compared to NFS on a local network. Also, coherence: sshfs manages to hide a lot of the ugly details, but you'll meet coherence problems on sshfs much more often than on nfs. They both do aggressive caching, but nfs gets help from the server side and is thus usually better.
  - leephillips 10y ago
    Both good reasons. My personal use case happens to make these issues unimportant: mounting remote file stores that are only accessed by me. But I guess for mulitply-accessed files on the local network, nfs headaches may be worth the trouble.
  - vacri 10y ago
    > performance. sshfs is dog slow I'd started using ssfs for something and found this slowness issue. I asked my mentor about what could be done to improve it, and he said "If you're using sshfs, you've already lost". 'scp' is very slow as well. Anything bigger than a small text file gets rsync'd. Small text files get scp'd, because remembering rsync flags is a minor annoyance :)

gluczywo 10y ago

SSH lacks a key distribution/certification model for server authentication. The article describes server authentication (in the section with misleading title "SSH connections are encrypted") but does not mention the fact that fingerprint should be sent over another secure channel and manually verified.

rocqua 10y ago
assuming the server you are connecting to has DNSSEC, SSHFP is the taylor made solution for this problem.
geggam 10y ago
https://www.digitalocean.com/community/tutorials/how-to-create-an-ssh-ca-to-validate-hosts-and-clients-with-ubuntu https://www.digitalocean.com/community/tutorials/how-to-crea...
e12e 10y ago
In addition to the fact that openssh has supported certificate authentication of both servers and users for years -- the easiest way to bootstrap "traditional" ssh keys is probably just to list the public ssh host keys on a web page secured by https/tls. It'll be just as insecure as the rest of the x509 CA-based cluster-fuck -- but at least it's easier to automate and less error prone than manually checking fingerprints. So, not saying you're wrong, but that while advice regarding "fingerprints" is technically correct, just adding "the correct" keys to known hosts is probably the more practical -- and in practice more secure -- solution. That is of course assuming that like the rest of the world setting up an actually secure solution using ssh-keygen seems like too much work (I'm myself guilty of this, for my personal servers it's easier to just stick with manual keys - it's also hopelessly insecure and inconvenient in the case of a breach or other reason to rotate keys).

KirinDave 10y ago

We're not using it because... well... it's weird (for lack of a better word)? Sure, it's a multiplexing protocol that can support a few neat use cases like port forwarding and X11 tunneling, but that's really not what we want in most cases. It carries a lot of baggage in its clients and implementations that in principle shouldn't cause problems but in practice makes it suboptimal. One of the most important aspects of why we don't use it: it's scary to work with. SSH's implementation of its protocol is much closer to the actual client implementation than the divide traditionally maintained between SSL and its clients. People are rightly afraid to get close to cryptographic code without sufficient training, and so there is the equivalent of a "If You Are Responsible: Keep Away" sign for most developers who might be inclined to improve the situation. Still, the community found the impetus to augment the protocol and UI to help deal with latency issues that plague SSH via Mosh. It helps escape the legacy idea that RTTs will be consistent and therefore are ignorable in a shell implementation. Ultimately, SSL is a better understood tunneling protocol and full of a lot less... maybe it's just the perspective we have in a world where SSL is ubiquitous but SSH is weird. Its rules are weird, its certificates are weird, its tooling is weird. This is a common contention in Hacker News I'm often on the minority size of, but I submit that while syntactic interfaces (shell, programming) has clearly demonstrated its value and deserves to be better developed, the same can not be said for serial text entry interfaces. Something based around a streaming query protocol like SSL+HTTP/2 that makes some fundamentally different decisions than the legacy UNIX shell and supporting tooling would be substantially better, and be able to use existing web browser techniques and software. Which is all abstract, but imagine for a moment something we've seen before: an Electron Shell based terminal. But what we haven't seen is someone really dive in and attempt to redefine the world around shells. So bear with me for a second... Imagine an Electron Shell based terminal experience that works locally and remotely. A line buffer separate from the display accumulates and maintains the current prompt (because instead of PS1 being pseudo-executable in our shell it actually can attach scripting functions and web-browser style timers). Executables logically return open dictionary objects (which can contain streams) instead of the current fixed set of indexed streams. We can use 0, 1 and 2 as legacy keys into these objects to maintain compatibility. But you could imagine a "rich-1" key that actually outputs rich markup, "error-1" that outputs rich markup for error, etc. And of course, media itself could either be file system references. These rich objects are just textual objects with references to valid HTTP/2 requests do what they do. This actually resembles SSH's protocol on the outside, but using tools that are reusable elsewhere and a cryptographic stack and transit protocol that has more funding and attention and traction.

devicenull 10y ago

> Or better yet, ZeroMQ-style sockets with proper security and encryption? ZeroMQ supports CURVE encryption + authentication as of 4.0 http://hintjens.com/blog:49 http://hintjens.com/blog:49

jvehent 10y ago

> Why aren’t we using SSH for everything? Because when you have 100,000 users and you need to rotate your host key following a leak, the team in charge of user retention has a heart attack.

deckar01 10y ago
Informing users when your keys were leaked is more important than user retention. Hiding your weaknesses does not build trust.
- jvehent 10y ago
  You're missing the point: SSH does not provide a host key rotation/revocation mechanism. TLS does.
  - deckar01 10y ago
    You said that you are afraid of loosing users after a leak, which implies if you don't have to, you won't tell your users about the incident.
    - eximius 10y ago
      No, its that the fix is client side and painful. They can tell their users to fix it and they would rather leave than do it.
      - deckar01 10y ago
        I thought users would be prompted to accept a new fingerprint. Am I missing something?
        billyhoffman 10y ago
        If by "prompted" you mean: @ WARNING: REMOTE HOST IDENTIFICATION HAS CHANGED! @ IT IS POSSIBLE THAT SOMONE IS DOING SOMETHING NASTY! Someone could be eavesdropping on you right now! Then, yes, users will be prompted in the scariest possible language. Compare this with HTTPS/browsers, which care not a lick if a certificate/fingerprint is different, provided that the certificate is valid and the chain is trusted.

deckar01 10y ago

I added SSH authentication to the roadmap for the API in one of my projects. I love the UX of the first connection from a new users acting as registration. When I looked for information on how git SSH servers are implemented I did not find enough information to get started. Can anyone recommended reading for someone getting started with an API over SSH?

mhotchen 10y ago
I looked at it a while ago using OpenSSH's AuthorizedKeysCommand feature and found Phabricator's implementation for vcs over SSH to be the most understandable thing I could find. https://github.com/phacility/phabricator/blob/master/resources/sshd/sshd_config.phabricator.example https://github.com/phacility/phabricator/blob/master/resourc... https://github.com/phacility/phabricator/blob/master/resources/sshd/phabricator-ssh-hook.sh https://github.com/phacility/phabricator/blob/master/resourc... https://github.com/phacility/phabricator/blob/master/scripts/ssh/ssh-auth.php https://github.com/phacility/phabricator/blob/master/scripts...

jagheterfredrik 10y ago

I made a toy SSH API thingie a couple of months back; https://github.com/jagheterfredrik/sheet https://github.com/jagheterfredrik/sheet

hatsunearu 10y ago

It's great if you can leverage the SSH keying system, but using SSH "raw" for anything high-bandwidth is a disaster (try using sshfs on a high latency network, you will get two digit kilobytes when you know the network connection can sustain a megabyte)

placeybordeaux 10y ago

If you look around there are cases of using ssh for various things, but at the end of the day HTTP is the protocol of the masses, you aren't going to beat it's adoption. plenty of nethack servers that you can ssh into here: https://nethackwiki.com/wiki/Public_server https://nethackwiki.com/wiki/Public_server Another rougelike: http://crawl.develz.org/wordpress/howto http://crawl.develz.org/wordpress/howto

zyxley 10y ago

SSH passing username by default is actually one of the things I hate about it.

shabble 10y ago
Why? not much of an info-leak if you know where you're connecting, and it has to use something, or enforce a foo@host string. You could work around it with something like: Host * User WhosAsking in your ~/.ssh/config (at the end of the file, so other entries can override it)

jheriko 10y ago

round trip times. it makes somethings impossible with that much interchange required to send anything - and it will never go away because the speed of light is a hard limit.

pt 10y ago

Do TLS client certificates make HTTPS equivalent to SSH?

ibotty 10y ago
No. Disregarding technicalities of which there are many, the most important difference is that with ssh you either get the host key through a different secure channel or "trust on first use" (TOFU). With HTTPS you trust certificate authorities (CA).
- pt 10y ago
  I was referring to the browser side certificate that can be generated using the <keygen> tag, and then used for the subsequent HTTPS sessions. Would this be equivalent to ssh-keygen for SSH?
  - ibotty 10y ago
    That's deprecated though and afaik, that's only the client-side authentication, not the server-side. That still relies on CAs, with all the disadvantages.

based2 10y ago

https://www.ietf.org/mail-archive/web/tls/current/msg12133.html https://www.ietf.org/mail-archive/web/tls/current/msg12133.h...

e12e 10y ago

Why aren't we using ipv6 with ipsec for everything? Then we could just stick with rsh, telnet and http... I honestly think that the time has come to turn back the clock, and move forward with that approach. We've time and time again proved that "mostly encrypted" is almost impossible to get right, and almost never what we really want. We've also shown that we really do care about authenticating the servers we communicate with. With the recent advances in cpu power, ram (and custom hardware) -- there's not much reason not just encrypt and authenticate all the things any more. In the 90s, doing full ipsec and ipv6 everywhere was expensive: new switches and network hardware was needed, and the overhead of encryption was way too high. But now the time should be right. Still not all that hopeful that we'll actually get there, though.

mankash666 10y ago

For one thing many corporate firewalls filter port 22 even got outbound traffic