[HN Gopher] Show HN: Caddy-SSH
___________________________________________________________________
Show HN: Caddy-SSH
Author : m_sahaf
Score : 220 points
Date : 2022-03-28 14:19 UTC (8 hours ago)
(HTM) web link (www.caffeinatedwonders.com)
(TXT) w3m dump (www.caffeinatedwonders.com)
| donatj wrote:
| I'm not sure I fully understand, what's the advantage of getting
| Caddy involved here versus a fully standalone app?
|
| Given the name I'd at first figured it was an official Caddy
| project, but that does not seem to be the case.
| m_sahaf wrote:
| Names are hard. I did consider changing the name but couldn't
| find another one. Feel free to pitch names on GitHub.
|
| Caddy provides the module system and the config management
| backed by powerful REST API for config query and patching. If
| it wasn't for Caddy, I would've had to build all of that from
| scratch. That's too much to own.
| GordonS wrote:
| Pluggable auth providers for SSH sounds awesome, though I can't
| think of a particular use for it right now!
| gunapologist99 wrote:
| Ironically, these already exist for OpenSSH and have been
| developed for Linux and UNIX for decades. It's funny how people
| keep reinventing things. You can use them in your
| /etc/ssh/sshd_config with "UsePam yes", but, to your point!,
| generally the built-in auth is a better option for a smaller
| surface area, unless you specifically know you need PAM.
|
| They are literally called Pluggable Authentication Modules
| (PAM) and it's a core part of any Linux distribution. (I'm not
| aware of any modern UNIX or Linux that do not offer PAM, but
| perhaps some embedded distros.)
|
| They can be configured for many types of server software, not
| just OpenSSH. (For example, mail servers like Dovecot and
| Postfix support PAM, database servers like Postgresql and
| MySQL, etc.)
|
| https://tldp.org/HOWTO/User-Authentication-HOWTO/x115.html
| gnufx wrote:
| How do you do GSSAPI with PAM? (Does OpenBSD support PAM
| now?)
| GordonS wrote:
| I'm aware of PAM, though I always assumed there was a
| relatively high barrier to entry, and C would be required?
| francislavoie wrote:
| > It's funny how people keep reinventing things.
|
| That's not exactly fair. The entire point of this exercise is
| to move away from C code, by implementing it in a memory safe
| language (Go).
|
| Since PAM uses shared-libraries to operate, that's
| fundamentally incompatible here since Go is statically
| compiled (unless you use some CGO like in
| https://github.com/msteinert/pam) so implementing auth via
| Caddy's module system is the way to go for this project.
| candiddevmike wrote:
| Memory safety won't save you from logic bugs, which is
| extremely prevalent in authentication exploits.
| francislavoie wrote:
| No arguments there, but it's still much safer to start
| with a memory-safe language as a base.
| [deleted]
| mholt wrote:
| What is involved in using PAM on Windows and Mac?
| bogantech wrote:
| Nothing on a mac since MacOS already uses PAM
| mikepurvis wrote:
| I feel like most practical situations which require this end up
| just routing through the OS user management and using PAM, but
| providing git-ssh access is an obvious case where that's not
| desirable or even necessarily possible.
|
| I'm a bit curious what this ends up meaning for projects like
| GitLab and Gitea. Gitea's docs [1] indicate that it can either
| use the system sshd or one that it "provides", but it's not
| clear whether the provided one is Go-implemented or just a
| statically-compiled instance that it runs as a subprocess.
|
| [1]: https://docs.gitea.io/en-us/faq/#ssh-common-errors
| elischleifer wrote:
| Biggest obstacle to proper SSH usage tends to be the creation and
| management of people's private keys. The number of times people
| have to google for instructions for doing this right is insane.
| Let's get someone working on that.
| [deleted]
| dapirian wrote:
| true story
| the_angry_angel wrote:
| Teleport I feel solves this well, from an organisation
| perspective
| elischleifer wrote:
| Cool - was not aware of that service. Will have to check it
| out.
| AtlasBarfed wrote:
| At my org, if I use teleport, I have to MFA in via a UI, and
| they offer zero other alternatives.
|
| The teleport daemon falls over due to memory stress and other
| issues that sshd doesn't fall over during, and when do you
| often need CLI access to a node? When it's under stress....
|
| Goodbye automation.
|
| It's a good idea, but it's made ssh and the problems I solve
| with ssh worse for me.
| g_p wrote:
| This looks very interesting. Is there any support (or plans) for
| SSH certificates? They help to manage some of the revocation and
| access control challenges, as well as the issues around trust-on-
| first-use and similar. (And also the fragility of syncing around
| authorized-keys files, or relying on LDAP for login, in
| infrastructure type environments).
|
| See also - https://news.ycombinator.com/item?id=30788544
| eliaspro wrote:
| I had to think of exactly this post as well and I started to
| wonder, whether Caddy-SSH couldn't even handle this using
| Caddy's built-in ACME support?
| m_sahaf wrote:
| The plans are there! I focused on implementing the absolute
| necessary parts of every layer before taking round-2 for the
| more in-depth implementation. I actually have both the linked
| thread and the article saved aside to study when I'm ready to
| implement certificate-based authentication. Knowing Gitea
| already has it implemented, I had plans to study their
| implementation to know what I'm venturing into. If anybody else
| is interested in picking it up, please feel free to tackle it!
| I'd love to see that PR.
|
| I've created tracking issue:
| https://github.com/mohammed90/caddy-ssh/issues/10
| yjftsjthsd-h wrote:
| > The ISRG estimates ~80% of the vulnerabilities exploited in the
| wild are memory safety bugs.
|
| Okay, but 1. How many vulnerabilities has openssh shipped, and 2.
| How many of those were memory issues? I would usually be
| tentatively on board, but you're competing with the OpenBSD
| folks, who have a shockingly good track record regardless of
| using C. No offense, but you could write in a formally verified
| Ada subset and I'd _still_ hesitate to replace my SSH daemon.
|
| (FWIW, I say all of this hoping to be wrong; an alternative
| implementation, if equally secure, would be great to have.)
| [deleted]
| voxic11 wrote:
| Not sure about the statistics but one of the most memorable
| vulnerabilities in recent history, Heartbleed, was exactly
| this, a OpenSSH memory safety issue.
| lawl wrote:
| No. Heartbleed was OpenSSL, not OpenSSH.
| photon-torpedo wrote:
| Heartbleed was OpenSSL, not OpenSSH.
| spockz wrote:
| That was in OpenSSL not OpenSSH, two entirely different
| beasts.
| [deleted]
| lucideer wrote:
| Sibling commenters have already pointed out you're confusing
| OpenSSH with OpenSSL.
|
| For additional context, since the gp mentioned that:
|
| > _the OpenBSD folks, who have a shockingly good track
| record_
|
| Not only is OpenSSH a BSD project, but so is LibreSSL (the
| OpenSSL fork that was a response to Heartbleed). Before
| LibreSSL, BSD folk were also working on assl - similarly an
| OpenSSL alternative motivated by the BSD guys having concerns
| about OpenSSL's codebase. So they very much have a solid
| track record of being pro-actively on top of this type of
| stuff.
| tialaramex wrote:
| However, on that note it's worth taking a moment to look at
| recent OpenSSL bugs and compare LibreSSL and see that
| unsurprisingly (to me anyway) the OpenBSD people did not
| magically _fix_ the bugs in hairy C code. Once Libressl had
| taken out the unnecessary stamp collecting from OpenSSL
| (crypto algorithms you will never need, feature switches
| left over from experiments a decade ago, etc.) it did not
| in fact evolve the rest of the codebase as much as you
| might imagine.
|
| If you've found a bug in pre-fork OpenSSL _core_ material
| (not the stamp collecting), chances are that it still works
| in all the forks, none of them have the beyond wizard level
| competence to rewrite somebody 's micro-optimised ECDHE
| implementation in a way that non-wizards can review, so
| even if they replaced it they'd just be swapping possibly-
| incorrect wizard magic for different possibly-incorrect
| wizard magic and what's the point of that?
| PinguTS wrote:
| * CVE-2019-16905:
| https://www.cvedetails.com/cve/CVE-2019-16905/
|
| * CVE-2016-10012:
| https://www.cvedetails.com/cve/CVE-2016-10012/
|
| * CVE-2016-0777: https://www.cvedetails.com/cve/CVE-2016-0777/
|
| A list of all CVE is available here:
| https://www.cvedetails.com/vulnerability-list/vendor_id-97/p...
| traceroute66 wrote:
| The 2019 bug refers to a bug in an explicitly experimental
| area of SSH code (post-quantum crypto XMSS)
|
| most of the other server-side bugs on the list relate to non-
| standard configs (of varying obscurity)
|
| the fact that - in an era of increasingly hostile cyber
| threats - years had gone by without any serious threats says
| it all really.
|
| for most people, they should just run normal SSH, enable
| public-key only authentication and get on with their lives.
|
| I see no reason why anyone should jump ship to some shiny new
| untested ssh server. Especially as , when others have pointed
| out, the people behind OpenSSH are the same people behind
| OpenBSd and LibreSSL.
| staticassertion wrote:
| There are obviously more than just those tho.
|
| Not that I really disagree with the conclusion. There's not
| a ton of pre-auth attack surface.
| rileyphone wrote:
| For reference, the first is with an experimental feature,
| second is a local privilege escalation, and the third allowed
| a malicious server to read the clients keys. For comparison,
| here's some CVEs from software written in Go:
|
| Caddy CVE: https://www.cvedetails.com/cve/CVE-2018-21246/
| Kubernetes CVEs: https://www.cvedetails.com/vulnerability-
| list/vendor_id-1586...
|
| No silver bullets! Though some have less lead in them.
| OpenSSH, along with other software developed by OpenBSD, has
| earned the highest level of trust in something written in C.
| C can be dangerous, but there is a chasm between such careful
| works and the typical offenders like OpenSSL (OpenBSD's
| alternative is LibreSSL, confusingly).
| tptacek wrote:
| Ceteris paribus, I would feel safer with OpenSSH than with a
| new SSH server probably for several years after the release of
| that new server, simply because OpenSSH is so scrutinized and
| because there's more things that go wrong with SSH than memory
| safety bugs. It's been well over a decade since the last
| exploitable OpenSSH bug. But it would also be a very good thing
| to have a memory-safe trusted SSH server. This isn't an easy
| call.
| mholt wrote:
| I think it will just take some time. I'm glad we have a solid
| start on a new alternative, and hopefully people will use it,
| scrutinize it, and improve it. It's a little unsettling to
| realize that when the next vuln in OpenSSL is discovered, it
| will likely effect 99% of servers on the Internet. (Or
| something like that.) I'd feel a little better if that
| percentage is brought down by something that isn't
| susceptible to those kinds of vulns in the first place.
| notatoad wrote:
| i think the point is that not everybody can be quite as awesome
| as the OpenBSD folks, and memory-safe languages can allow
| mortals to write secure software.
|
| if this helps us get away from the scenario where literally
| everybody uses the same SSH server implementation, i think it's
| a great thing.
| tyingq wrote:
| This could also be a replacement for things other than openssh,
| like dropbear. Though golang binary size might be a barrier for
| that.
| formerly_proven wrote:
| I'm assuming this being Go and the mention of being extensible
| through Caddy modules (in-process API) that this is a
| monolithic, non-privilege-separated server, which likely makes
| it quite a bit worse than OpenSSH sshd in terms of defense in
| depth.
| jerf wrote:
| Another aspect is that security software has additional
| requirements that most other software doesn't, and that can be
| a problem. My impression is that the crypto community generally
| regards the Go crypto stack as fairly algorithmically solid,
| but it hasn't necessarily been hammered on to the n'th degree
| for things like timing attacks. I'm comfortable using it in my
| usecases, but I'd be a bit nervous about deploying it to my
| high-security stuff. Things like reaching out to the network
| for crypto keys is also a convenient feature in some ways but
| something I'd want to see much, _much_ hardened compared to
| what I might ask of a non-security program doing something
| similar.
|
| That said, I don't say this to discourage the project. I wish
| it all the best and hope that they continue to work out the
| issues involved. I'm speaking more here to dampen the set of
| programmers and/or ops I know who will read something like this
| and immediately begin converting their entire fleet, because
| this looks new and hot and uses $TECH I like and must therefore
| be better than the old and busted using $BADTECH I don't like.
| Hey, I'm on the cutting edge of hating C and thinking almost
| anything written in it should be banned from the network, but
| OpenSSH does have a pretty good track record and that shouldn't
| be chucked overboard for new untested hotness.
|
| Best wishes to Caddy-SSH. I would encourage a bit of trying it
| out, just, you know, don't go crazy. I don't think they'd want
| you to either!
| hestefisk wrote:
| Good point. Software monoculture is bad though (OpenSSL) and
| choice is good.
|
| That said, I wonder how many crypto libraries are shared
| between Caddy-SSH and OpenSSH?
|
| Finally, I really hope this is a separate daemon. SSH served by
| a web server invokes a certain systemd feeling.
| francislavoie wrote:
| > I wonder how many crypto libraries are shared between
| Caddy-SSH and OpenSSH
|
| None, because Caddy-SSH is written in Go, and uses Go stdlib
| crypto libs which are their own thing. See
| https://pkg.go.dev/golang.org/x/crypto
|
| > Finally, I really hope this is a separate daemon. SSH
| served by a web server invokes a certain systemd feeling
|
| That's entirely up to you. Caddy v2 is designed as an "app
| platform"; the HTTP app is just one such app that Caddy
| happens to ship with, but anything else can be plugged in,
| like an SSH app in this case. You don't have to run both HTTP
| and SSH in the same process, you could run two instances of
| Caddy each with their own purpose, if you feel like.
| https://caddyserver.com/docs/architecture
| sneak wrote:
| Note that outsourcing your key list to a live GitHub URL gives
| Microsoft unfettered access to your box, should they (or anyone
| who can compel them, such as the US armed forces) ever want or
| need it.
|
| If you wouldn't use Microsoft SSO for local login, you should not
| thus configure your sshd that way.
| zufallsheld wrote:
| How does outsourcing your key list give ms access to my box?
| Presumably you mean because they also have the private key?
| yjftsjthsd-h wrote:
| Because they can serve any list of public keys they want;
| they can return a blank list and lock you out, or append
| another key at will.
| sneak wrote:
| No, the keys on GitHub are only the public portion.
|
| If your sshd consults Microsoft servers to check a key,
| Microsoft can serve it any file they wish (or are forced to),
| such as a list of Equation Group pubkeys.
| jon-wood wrote:
| What's the benefit of this being built on top of Caddy, which
| unless I'm mistaken has historically been an HTTP(S) server?
| Maybe there's someone intrinsically great about how Caddy works
| for this, but on first glance it feels like the scope creep in
| servers like Apache, or Curl's support for querying every data
| source under the sun. It can be handy having a single tool that
| does everything, but at the same time that gives an ever larger
| attack surface where suddenly your machine has been compromised
| via instructions from an MQTT server because Curl was installed.
| francislavoie wrote:
| Caddy v2 is actually designed as an "app platform". The HTTP
| app is just one such type of app, and is what Caddy ships with
| by default. But it can be extended to do _anything_.
|
| See https://caddyserver.com/docs/architecture
|
| You don't have to run both the HTTP app and the SSH app in the
| same process, you could have two separate Caddy processes
| configured to each do their own thing, if you're at all
| concerned.
| pantulis wrote:
| Isn't this like a super-server in the spirit of inetd?
| francislavoie wrote:
| I guess, except Caddy doesn't spawn any processes, it just
| "starts apps" which are configured in-process, pure Go.
|
| Another example Caddy app is
| https://github.com/mholt/caddy-l4 which lets you do
| arbitrary TCP/UDP handling/proxying.
|
| There's a list of available apps here
| https://caddyserver.com/docs/json/apps/ (the SSH app is not
| there yet, should be soon)
| jrockway wrote:
| I think it's fine for a conceptual understanding. The Go
| runtime looks a lot like an OS, mapping G (goroutines) to
| Ms (worker threads), removing goroutines from the workers
| when they block in syscalls, waking up goroutines when a
| lock they want is available or a syscall finishes, etc.
|
| In the end it really depends on what you think of inetd
| as. If you think of it as "I install this one server and
| now I have finger and gopher!" then that seems similar to
| Caddy's applications. If you think of it as "whenever a
| TCP connection arrives, the fork() syscall is used to
| create a process to handle that session, file descriptors
| 0 and 1 are connected to the TCP socket, and then exec()
| according to the global config is run to handle the
| protocol", then ... no it's not the same as inetd.
| m_sahaf wrote:
| Hi everyone! Author here
|
| This has been my stress-reliever for the past ~2 years. I'm
| sticking around, so feel free to ask any questions.
|
| Github Repo: https://github.com/mohammed90/caddy-ssh
| nodesocket wrote:
| Am I understanding that the public keys used for authorization
| (authorized_keys) can come from a centralized source? Being
| able to add and remove authorized keys from say Redis or Consul
| centrally would be extremely useful from a management
| perspective.
|
| Obviously, security of that Redis or Consul would have to be
| tight and prevent public access.
| m_sahaf wrote:
| That's right! Currently such (static) keys are loaded at
| provision-time, when the server is first booting up, but
| there's nothing preventing it from being lazy-loaded at
| authentication-time. Of course loading them at
| authentication-time incurs latency as tax. Nothing prevents
| two separate modules from existing: one eager-loads the keys,
| and another lazy-loads them.
| DHowett wrote:
| Hey! This is awesome. I'm the engineering manager for the
| Windows console subsystem team. I'd be happy to help out with
| your ConPTY issues!
|
| Feel free to file a discussion issue over on GitHub at
| microsoft/terminal, or email me at duhowett@(corporate domain
| name).
|
| I suspect what you need is CreatePseudoConsoleAsUser... which
| we should have offered as a public API.
| password4321 wrote:
| Can you point the right person to this internally for the
| real OpenSSH shipped with Windows? I'm actually curious how
| licensing works out for 3rd party servers like Caddy-SSH.
|
| Licensing / Multi-user access / CAL |
| https://github.com/PowerShell/Win32-OpenSSH/issues/926 (Oct
| 2017)
| explorigin wrote:
| Cool! (not a security professional) One of the reasons in my
| understanding that projects don't deviate from older languages
| was because they give you some control around compilation that
| would be necessary to thwart timing-based attacks. Does this
| consider timing-based attacks or is that at a lower-level
| library?
| gunapologist99 wrote:
| Excellent point; it does appear that the author did consider
| timing attacks in at least one location:
|
| https://github.com/mohammed90/caddy-
| ssh/blob/master/internal...
| m_sahaf wrote:
| To be fair, this bit is borrowed/forked from
| github.com/gliderlabs/ssh.
| enneff wrote:
| I have reviewed some of the crypto code in the Go standard
| library that this is built with, and there is use of constant
| time primitives in there so it is at least possible and some
| attention has been spent on it.
| m_sahaf wrote:
| Not very too level. I had to take that into consideration at
| some parts. For example, the static username_password
| provider calls a hasher defined in Caddy which uses
| `subtle.ConstantTimeCompare` function used. At other places,
| I don't return early (when possible) on auth failures to
| avoid timing attacks. That said, I'd love to know if there
| are places where I fell short.
| XzAeRosho wrote:
| Congratulations! Looks like a really cool project.
|
| So, if I get this right, this should be a drop-in replacement
| for current SSH servers? I get that an adapter has to be built
| to support sshd config files, but is that the ultimate goal
| here? Is security the main selling point of this project?
| m_sahaf wrote:
| Thank you! Indeed, you're right. The ultimate goal is to be
| drop-in replacement. There is a PR hanging waiting to be
| taken up. I might look at it once I finish furnishing the
| foundation, but others are welcome to take it up!
| foxtrottbravo wrote:
| First and foremost, congratulations on bringing the project to
| this stage - I think it's an impressive piece of work.
|
| I am in no way qualified to trample on your parade but two things
| came to my mind that pinch a personal nerve of mine and I would
| really like to have alleviated by you or the folks who know that
| stuff:
|
| - if your Goal was "secure by default", why did you allow
| passwords in the first place? Following Caddys recipe would be
| more like SSH-Keys only, wouldn't it? Is there a reason other
| than compatibility?
|
| - In that same avenue? Why allow such a thing as downloading
| authorized keys from a third party? Domain takeovers or account
| compromises on say Github are a thing - so again while it may be
| a nice usability aspect isn't that contrary to the secure by
| default pradigm?
|
| Again thank you for your work and congratulations on the project
| - those above are just honest questions that came to mind which I
| would really like to be educated on
| [deleted]
| m_sahaf wrote:
| > - if your Goal was "secure by default", why did you allow
| passwords in the first place? Following Caddys recipe would be
| more like SSH-Keys only, wouldn't it? Is there a reason other
| than compatibility?
|
| Compatibility was the consideration. The presence of the
| password based authentication does not mean it is enabled by
| default. In fact, if you don't enable any of the authentication
| flows and don't explicitly set `no_client_auth` to `true`, the
| server will not accept any request at all! You have to
| explicitly set `no_client_auth` to `true` for the server to
| allow unauthenticated users to login. The default is: none of
| the authentication methods are configured, and `no_client_auth`
| is false (meaning do not allow clients without authentication).
|
| > - In that same avenue? Why allow such a thing as downloading
| authorized keys from a third party? Domain takeovers or account
| compromises on say Github are a thing - so again while it may
| be a nice usability aspect isn't that contrary to the secure by
| default pradigm?
|
| That was just an example, but the implementation doesn't only
| support github. It supports any HTTP/S URL you provide. The
| point was that the source of the keys may even be an internal
| HTTPS service within your network that applies its own logic
| for keys issuance and generation.
| getcrunk wrote:
| Passwords are not insecure. Certs have tradeoffs.
| dewey wrote:
| I don't read it as "passwords are insecure" but as having
| defaults that force people into using it in ways that are
| harder to mess up.
|
| Re-using an insecure password is easy, using a key wrong is
| harder.
| moondev wrote:
| re-using an insecure key is just as easy
| https://github.com/mikalv/anything2ed25519
| LinuxBender wrote:
| I understand what you are saying but in my experience the
| opposite can be equally true. Unless every system in your
| org is managing the authorized_keys for every account with
| automation and hourly validation one can end up with rogue
| keys, forgotten keys, unmanaged keys. SSH has no concept of
| identity in this regard. If I temporarily have sudo on a
| system I can append any random public key into the
| authorized_keys of any account. It gets even worse if that
| system allows passwordless sudo. Now there is an audit
| trail that showed you made a reckless change when it was
| really me. This risk gets exponentially worse if the system
| I append a random key into is a command and control or
| configuration management system. One doesn't even really
| need sudo for this to be a problem given how much power non
| root accounts have over applications, deployments, builds
| and secret management.
| staticassertion wrote:
| Is authorized keys important here? If I send the server
| my password, it has my password. If I send a server my
| public key, that's a lot less severe. If an attacker is
| on the server I expect that the difference is obvious?
| remram wrote:
| I've received the _private_ component attached via email
| before. People find a way to mess up.
| tptacek wrote:
| No they don't. Passwords are worse than certificates or
| keypairs, categorically.
| willcipriano wrote:
| > No they don't
|
| SSH into one of your boxes from my machine real quick.
| reggegg wrote:
| What's the use case for using your personal unix account
| on someone else's computer?
| willcipriano wrote:
| I've done it from work computers where the USB ports are
| disabled but I want to hit my personal dev machine at
| home to get at my notes and calendar.
|
| I've established impromptu SSH tunnels from other
| people's machines to my local network so that I could
| watch my media on their TV.
|
| If you dropped me naked on the other side of the planet I
| could get a copy of my identity documentation and access
| my email, bank accounts, etc from any internet connected
| machine I find.
| tptacek wrote:
| You get that passwords over first-time SSH from untrusted
| computers or untrusted networks aren't safe at all,
| right? That posting those passwords is literally a sport
| at hacker conferences, and has been for over 2 decades?
|
| This whole thread is a little alarming.
| getcrunk wrote:
| Iirc ssh passwords aren't sent in the clear. Is that
| really the case?
|
| Edit: I looked it up to confirm. First time password is
| encrypted analogous to tls
| tptacek wrote:
| No, it's not analogous to TLS. TLS has trust anchors: the
| key exchange in a TLS handshake is secure, even on first
| contact with a server. The key exchange in a first-
| contact SSH handshake is trivially MITM'd. An attacker
| with control of your network (or, obviously, your
| machine) can simply steal your password.
| willcipriano wrote:
| You get that waking outside isn't safe at all right?
| Mugging is as old as civilization and don't get me
| started on cars.
|
| Life is about trade offs, if someone really wants to
| spend the time to get access to my home dev box then I
| may have to spend a couple days on the phone with the
| bank and restoring from my offline backups. Big whoop.
|
| Your home is likely insecure from my standards. Do you
| have a firearm at the ready? Do you know how to use it?
| Does your family have codewords to communicate without
| letting others on to your plan? How hard is it to kick in
| your doors? Not just the front door, but the bedrooms. Do
| you have a dog to wake you in the night? How stocked are
| you, can you last a month with no resupply? Do you even
| have a panic room?
|
| I protect what matters beacuse you can't protect
| everything.
| tptacek wrote:
| How are we still talking about this? SSH doesn't work the
| way you appear to think it does. Passwords don't solve
| the first-use problem; in fact, the first-use problem
| makes passwords much less safe than keys.
| willcipriano wrote:
| Yes and your cheap hollow core door doesn't solve the
| ending the life of everyone you care about problem. Why
| are you more concerned about passwords than that?
|
| I know the risks well, I don't find them to be worth the
| hassle of avoiding them.
| tedunangst wrote:
| My mail server crashed while I was on vacation without my
| laptop.
| lilyball wrote:
| How do you log into a server for the first time without a
| password? How do you log into a server from a brand new
| machine without access to your previous machine or sharing
| certs?
| wadim wrote:
| Depends on how the server was setup. Ubuntu has offered
| importing public keys from github for quite a while in
| its installer. If you're using terraform/ansible/some
| other IaC tool, adding a key is probably just 1-2 lines
| of code. Some OS, like Guix or NixOS, also allow you to
| define them in a config file. Worst case you can just do
| something like `curl -L github.com/username.keys >>
| .ssh/authorized_keys`.
| tptacek wrote:
| This is also part of the reason big fleet operators like
| SSH CAs, since they work for host keys and solve the key
| continuity problem.
| tptacek wrote:
| Keep following your own logic. If you don't have a
| preexisting key relationship and you can't trust the
| network, are passwords safe? [Y/N]
| mynameisvlad wrote:
| > and you can't trust the network
|
| Why is this a requirement? Not having a configured
| machine does not imply an untrusted network. Maybe all my
| computers recently and unexpectedly got wiped and I'm
| trying to rebuild my home network.
| tptacek wrote:
| Repeat exercise, but with untrusted computer. [Y/N]
|
| If you trust literally every component involved in the
| exchange, is rsh safe? [Y/N]
| randomsilence wrote:
| If you cannot trust the network, where is the advantage
| of keypairs over passwords?
|
| If you have a one-time password, worse case is that some
| man in the middle gets that password.
|
| If you engage in a proof of private key ownership for
| your login, a man in the middle can use that exchange to
| log into another server that has the same public key.
| remram wrote:
| He can do it once, maybe, if you don't authenticate the
| server. With a password, he can do it any number of time,
| to any number of targets, and there's no way to catch it.
|
| Yes, it is still not _perfect_ , but here's the
| advantage.
| tptacek wrote:
| First, if you use an SSH CA, you don't necessarily have
| the first-use problem at all; that's part of the point of
| SSH CAs. You've resolved that problem the same way TLS
| does.
|
| Second, an attacker targeting your keypair-backed SSH
| session on an insecure first-use gets your session;
| against a password, they get your password, which is
| strictly worse.
|
| It's not my claim that keypairs neatly solve the first-
| use problem with SSH (though: that problem can be solved,
| with more keypairs). It's that keys are categorically
| better than passwords. Which, of course, they are.
|
| The alarming thing about this thread is that there's a
| couple people here that clearly seem to believe logging
| in with a password to a "new" SSH server is safe. It's
| literally the basis for the "Wall of Sheep" at hacker
| conferences; they were doing it at Usenix when I was
| there in 1998.
| [deleted]
| [deleted]
| jrockway wrote:
| When you install Ubuntu it asks you for your Github
| username and pulls your public key from there, making
| having the corresponding private key the only way to log
| into the system.
|
| If you lose all your key material, then I wouldn't expect
| for you to ever be able to log into the system. Passwords
| have the same problem; if there's some machine you can
| only remotely connect to and you forget your password,
| you simply won't be accessing that computer anymore.
| dspillett wrote:
| Good passwords are usually not insecure. But if you give your
| password to a host that you don't 100% trust (i.e. that you
| didn't setup yourself locally) you have potentially shared
| that password and if you've reused it anywhere the other
| wheres are potentially compromised.
|
| If you give you public key to be installed to allow access,
| even if the host (or any system you are using to
| build/interact with it) is compromised your private key and
| any other hosts that accept authentication that way are fine.
|
| How much difference this makes to you depends upon your
| threat model and how much extra threat you are willing to
| accept for a little convenience, of course, but key based
| auth is demonstrably more secure than passwords for some
| circumstances and no less secure in others.
|
| Then again given that very few people bother actually
| checking host fingerprints on first connection, then proceed
| to send important data to that unverified host, is the
| password/key issue the first thing we need to fix?
| tialaramex wrote:
| Passwords are a _shared secret_. I 'm not sure I'd choose the
| word "insecure" but only because it's too black and white
| when the reality is more nuanced. They are clearly worse than
| doing public key auth which is the alternative and is
| Mandatory To Implement in the SSH (SecSH) RFCs.
|
| Nobody said anything about requiring certificates in SSH,
| just public keys as authentication.
| SAI_Peregrinus wrote:
| Strong aPAKES can allow passwords to not be shared secrets.
|
| Of course they're super niche now and none of them are
| standardized so they're basically impossible to use, and
| SSH doesn't support them, so this is a pedantic nitpick
| instead of some sort of insightful observation.
| achairapart wrote:
| Speaking of sane defaults, I wonder how many people are aware
| that Caddy serves dotfiles by default.
| mholt wrote:
| That's incorrect. Caddy does not serve _any_ files by default.
| You have to explicitly enable file serving in your config.
___________________________________________________________________
(page generated 2022-03-28 23:00 UTC)