[HN Gopher] OpenSSH versus SSH
___________________________________________________________________
OpenSSH versus SSH
Author : ingve
Score : 106 points
Date : 2023-04-16 07:19 UTC (1 days ago)
(HTM) web link (utcc.utoronto.ca)
(TXT) w3m dump (utcc.utoronto.ca)
| nijave wrote:
| Dropbear seems pretty common on busybox devices (or at least
| consumer routers) https://matt.ucc.asn.au/dropbear/dropbear.html
| [deleted]
| nailer wrote:
| OpenSSH's relationship to SSH Labs is similar to what Linux is to
| Unix: one is considered the default implementation (where you
| like it or not) and the other an irrelevant standard (likewise).
| zokier wrote:
| Or Chromes relationship to Web :)
| OliverJones wrote:
| OpenSSH is indeed widely used. But the only game in town they're
| not. There are commercial SSH implementations that aren't based
| on OpenSSH, reasonably widely used too. For decades I've used a
| Windows product called SecureCRT based on their own ssh and sshd
| stacks at Van Dyke. I'm sure there are others too. (I hated
| putty's UI.)
|
| There's an obvious infosec observation here. Different stacks,
| different hacks. Maybe individual infosec people should adopt a
| randomly chosen stack from among the less popular. Then the
| dreaded zero-day that hits the most popular stack won't cut off
| their access entirely.
| mardifoufs wrote:
| I'm curious to know what are the advantages of using those
| other implementations instead of OpenSSH. Was it mostly because
| Windows didn't have openssh? Or do they provide more features
| (or less! which could be good for security)? I have only ever
| used OpenSSH so I'm totally ignorant about everything else!
| tonyarkles wrote:
| I totally forgot that the very original version of SSH came out
| in 1995 and turned into a commercial product.
| https://www.ssh.com/home-page
| chasil wrote:
| We run it on our VAX.
|
| The article also says:
|
| "I don't think anyone else is working on new protocol
| features; instead, OpenSSH comes up with them and then people
| with other SSH implementations either follow along or not."
|
| One obvious exception is curve25519-sha256@libssh.org which
| is the preferred kex.
| CaliforniaKarl wrote:
| Is there a citation for this:
|
| > In one recently relevant example, one reason Github didn't take
| advantage of OpenSSH's protocol extension for offering multiple
| host keys (to enable upgrades or transitions) is that they don't
| use OpenSSH but instead a different implementation.
|
| ? I thought GitHub didn't use the host-key-migration capability
| because the host key change was implemented on a semi-emergency
| basis. I mean, in this case I don't think you'd want to start a
| host-key migration without announcing it, and GitHub wanted off
| of the exposed RSA host key very quickly.
| hultner wrote:
| This makes me think about something I thought of a while back, is
| there any library/app which lets me expose a TUI/cli-app over ssh
| without actually caring about securing OpenSSH for this use case?
| russellendicott wrote:
| Not exactly what you're looking for but to solve a similar
| problem I've been working on a TUI-over-the-wire protocol.
|
| http://uggly.bytester.net
| dizhn wrote:
| https://github.com/charmbracelet/wish
|
| If you're actually willing to write the app.
| e12e wrote:
| The go ssh packages are a popular choice:
|
| https://github.com/shazow/ssh-chat
|
| https://github.com/zachlatta/sshtron
|
| https://github.com/quackduck/devzat
|
| https://github.com/donuts-are-good/shhhbb/
|
| There's also a assembly library:
|
| https://2ton.com.au/sshtalk/
|
| And for rust there's trush, and for python paramiko as
| mentioned.
|
| > expose a TUI/cli-app over ssh without actually caring about
| securing OpenSSH
|
| If you already have an app, see maybe:
|
| https://drewdevault.com/2019/09/02/Interactive-SSH-programs....
| AceJohnny2 wrote:
| Do you mean something like Paramiko, an SSH library for Python?
|
| https://www.paramiko.org
| VLM wrote:
| Something like Apache Guacamole as a https web to SSH
| "something" gateway?
|
| Go to http-something in your web browser which is a Guacamole
| install and log in to Guacamole as "guest" / "guest" then in
| guac the only connection option is some SSH login that'll
| appear in your web browser
|
| As a warning people have tried to supply "nethack as-a-service"
| or whatever and people are really creative about gaining shell
| access somehow anyway, via buffer overflows or who knows what.
| You can do it, just be careful.
| codethief wrote:
| Tailscale comes to mind, see
| https://tailscale.com/kb/1100/services/
| gopalv wrote:
| Are you thinking of something like the Blinkenlights Star Wars
| telnet demo from a while ago?
|
| The "securing" part aside, ssh still gives you a whole terminal
| experience very similar to the telnet one & the ability to draw
| into it (like if you were using Emacs on the shell host).
|
| You can set something like that up by forcing a command on ssh
| instead of a shell (like what github does for git).
| hultner wrote:
| Yeah I was thinking of something like that. But I still feel
| a bit uneasy with configuring OpenSSH securely, I've escaped
| such setups before, gaining full shell access through
| exploits. Maybe I'm overly paranoid.
| yjftsjthsd-h wrote:
| Like ForceCommand, or turning off authentication?
| tingletech wrote:
| someone posted an ssh bbs the other week
| https://news.ycombinator.com/item?id=35412416
| Eduard wrote:
| Maybe "poor man's SSH via websocketd" could be a building
| block?
|
| https://github.com/rowanthorpe/ws-repl
| jmclnx wrote:
| I read this and if I understand it, someone wants to add some
| kind of automatic key exchange kind of like what happens with
| 'https:' ?
|
| Please do not do this :)
|
| One comment I agree with from a linked article:
|
| https://mjg59.dreamwidth.org/65874.html
|
| >It takes all the problems associated with HTTPS and makes it
| SSH's problem also. This relates also to the reasons why OpenSSH
| refuses to accept patches that implement SSL/TLS pki and instead
| implemented their own CA model.
| mjg59 wrote:
| No, I'd like sites to be able to present a CA to trust rather
| than a static key to trust and then be able to rotate their
| keys without triggering identity change notices.
| Karellen wrote:
| What about a way to sign the new key with the old key?
|
| If the host presents a new key, plus a signature from the old
| key which you already trusted, then your system switches to
| trusting the new key?
|
| I can see that there are problems in that if you don't
| attempt to log in between when the new key is issued and the
| old key expires, then you won't be able to trust the switch
| and will have to re-authenticate via external means. That
| might be a problem, but it might be easier for some groups of
| people to manage than figuring out a whole new CA model?
| mjg59 wrote:
| That's fine for orderly transitions, but if you're worried
| that your private host keys have been compromised then (a)
| you can't trust any new transitions and (b) if the new
| private keys are already on the systems then have they also
| been compromised?
| jacobr1 wrote:
| It would be better at an intermediate cert level. Those are
| generally more aligned to an organization's boundaries.
| mjg59 wrote:
| The format doesn't support intermediates.
| soulofmischief wrote:
| SSH certificates already enable this. I use them in prod.
| jmclnx wrote:
| This stuff is a bit over my head.
|
| Under this scenario, if the site rotates their key, will I
| need to decide on my system to trust it or not ? Maybe change
| something on my system ?
|
| Or does the remote site use my ssh public key transparently
| to know it is me, and allow me in ? So I do nothing at my end
| ? I guess that would be OK by me. But as I noted above, I am
| guessing.
| asmor wrote:
| Your key is not involved here at all.
|
| You can _also_ sign host keys and then trust the CA instead
| of the host key with TOFU, but as mentioned in the article,
| there 's no way to do this without having the user fiddle
| with their SSH config and I'm unsure how good the tooling
| for distributing revocations is.
|
| Vault has a setup guide, along with the little dance a user
| would have to do: https://developer.hashicorp.com/vault/doc
| s/secrets/ssh/signe...
| crote wrote:
| If I understand it correctly, there would be zero change
| for the user.
|
| Right now, a server has a single host key. This is
| generated once and will remain static for the server's
| entire lifetime. The client has the public part of that in
| their authorized_keys. When a session is created, the
| server uses the private part to sign some stuff, and the
| client validates it using the already-known public key. In
| other words, we have the host key K, client stores K_public
| in known_hosts. On session creation, server does
| `session_signature = K_private.sign(data)` and sends (data,
| session_signature) to client. Client does
| `K_public.validate(session_signature, data)` and continues
| if it all matches.
|
| This usually works just fine, but you can only have a
| _single_ key for a server - which is a bit of an issue if
| that "server" is actually an entire cluster consisting of
| thousands of machines. Every singly machine needs to have a
| copy of the single private key. as delegating this to a
| secure enclave is unfeasible if you get hundreds of
| thousands of connections per second. Not to mention that
| key rotation is a bit of a nightmare.
|
| With this proposal, we add a _parent_ key, let 's call it
| L. L_private is stored in some kind of very secure hardware
| enclave. Every hour/day/whatever, the server generates a
| new host key K, and asks the enclave to sign the new public
| key. The server now has K_private, and `host_signature =
| L_private.sign(K_public)` as generated by the enclave. The
| client stores L_public in their known_hosts. On session
| creation, server does `session_signature =
| K_private.sign(data)` and sends (data, session_signature,
| K_public, host_signature) to the client. The client finally
| does `L_public.validate(host_signature, K_public) &&
| K_public.validate(session_signature, data)`.
|
| All of this happens on the server side, and the only thing
| needed is a relatively minor protocol upgrade. The
| interesting part is that a _very_ similar mechanism already
| exists for the _client 's_ key, making it way easier to
| manage hundreds of keys across thousands of servers without
| going crazy by having to update authorized_keys among the
| entire server fleet multiple times per week.
| mjg59 wrote:
| Under this scenario you wouldn't need to do anything if the
| site rotates their key - the new key would be presented
| with a certificate signed with the same CA key. But no
| clients support doing this kind of semi-automated
| enrollment at the moment. You can manually add the trusted
| certificate to known_hosts, though.
| jmclnx wrote:
| Great, thanks
| unethical_ban wrote:
| The way I understand SSH interaction, is that every single
| time I login to a site or server for the first time, it is
| like interacting with self-signed HTTPS cert. There is no
| PKI, no central trust that did any kind of validation that
| the site is who they say they are.
|
| Considering that SSH is generally used by a small number of
| people per server vs. a general access mechanism (for the
| general internet), the need for PKI hasn't seemed as
| pressing. But why it isn't more prominent, I don't know.
| er4hn wrote:
| Interestingly enough this is getting another layer on top of it.
| Google is working on something called "HIBA"
| (https://github.com/google/hiba) which is an extension to OpenSSH
| SSH Certificates.
|
| So now you have layers of:
|
| - SSH RFC
|
| - OpenSSH extensions to SSH
|
| - Google extensions to OpenSSH
| cbsmith wrote:
| Another way I'm feeling old... I remember back when OpenSSH was
| just a plucky upstart implementation of SSH.
| StayTrue wrote:
| I did the original import of the unencumbered SSH sources into
| the OpenBSD CVS repository (imported to the wrong path and Theo
| blew up lol). Haven't thought about it in ages and the distance
| of the memory is making me feel old too.
| trelane wrote:
| Yep. I wanted to say it was F-Secure SSH, but the timeline on
| Wikipedia doesn't quite match. The development of SSH and the
| history of Data Fellows/F-Secure kinda line up, though.
|
| https://en.wikipedia.org/wiki/Secure_Shell
| https://en.wikipedia.org/wiki/F-Secure
| trelane wrote:
| Update: yep, it was DataFellows that I remember!
| https://www.openssh.com/history.html
|
| > Later licenses restricted the use of ssh in a commercial
| environment, instead requiring companies to buy an expensive
| version from a company called Datafellows.
| cbsmith wrote:
| Yup, the good ol' days of DataFellows, when I had to
| convince people to use SSH instead of Telnet... ;-)
| js2 wrote:
| This protocol/standard vs implementation is not uncommon. BIND
| was synonymous with DNS for a long time, to the point that I'd
| argue that some of the things specified in the DNS RFCs should
| have been considered BIND-specific implementation details. For
| example, RFC 1035 specifies the syntax of zone files used by
| BIND. I'd argue that even AXFR (zone transfers) as a replication
| mechanism should have been a BIND implementation detail.
| fanf2 wrote:
| The syntax of zone files originally came from JEEVES, not BIND.
| It's implemented by most other DNS software, and is not at all
| specific to BIND. Same for AXFR and other parts of the DNS
| protocol.
| tptacek wrote:
| This was Daniel Bernstein's argument, back when he was doing
| djbdns, and I believe it got him kicked off the IETF DNS list
| (he was, in this one instance, correct; I'm still confused
| about why zone files are a part of the DNS standard).
| throwawayapples wrote:
| only this one instance? what about port randomization or
| Curve25519?
| tptacek wrote:
| Like everyone else, he's right sometimes and wrong others.
| aflag wrote:
| The two examples above are cases where he was correct
| actually.
| tptacek wrote:
| Like everyone else, he's right sometimes and wrong
| others.
| AceJohnny2 wrote:
| djb is a great lesson in how "being an asshole" can be
| counterproductive.
| cvalka wrote:
| DJB is a gift to humanity.
| riceart wrote:
| As if djb not being an asshole would have saved the IETF
| from their incompetent buffoonery. Yeah let's just blame it
| all on one guy for not being a sycophant rather than lay
| the responsibility on the actual buffoons.
| akira2501 wrote:
| > counterproductive
|
| If the goal of a committee member is merely to be included
| in the committee. Otherwise, if the committee is merely
| operating as a rubber stamp for every one of it's members
| proposals, then there may not be much productive value in
| remaining there. Apparently that feeling was mutual.
| 0xdeadbeefbabe wrote:
| Seems most counterproductive if you lose.
| kiwijamo wrote:
| I think it's good that there's a standard for zone files.
| I've migrated from one dns server to another and being able
| to just carry over the same zone files has been useful. I
| also for some time had a master using one dns software and
| slaves using different software (as part of a mirgariton
| keeping a known good server using the old software and moving
| others to the new software and testing to ensure both were
| producing the same responses). Had zone transfers not been
| standardised I would not have been able to do this. I agree
| that perhaps the easy path of just adoptong the BIND
| implementation should not have happened but I would argue
| having a standard is better than just leaving it to hoping
| the implementation detail remains compatible between
| different software.
| mlyle wrote:
| > I'd argue that even AXFR (zone transfers) as a replication
| mechanism should have been a BIND implementation detail.
|
| AXFR has been valuable for interop, though, and allows you to
| have diverse implementations of authoritative servers.
___________________________________________________________________
(page generated 2023-04-17 23:00 UTC)