[HN Gopher] OpenSSH introduces options to penalize undesirable b...
___________________________________________________________________
OpenSSH introduces options to penalize undesirable behavior
Author : zdw
Score : 275 points
Date : 2024-06-07 17:08 UTC (5 hours ago)
(HTM) web link (undeadly.org)
(TXT) w3m dump (undeadly.org)
| yjftsjthsd-h wrote:
| I've seen MaxAuthTries used for similar reasons, and of course
| fail2ban, but this seems like a nice improvement and it's built
| in which is probably a win in this case.
| lxgr wrote:
| It does seem to be very similar in spirit and implementation:
|
| > PerSourceNetBlockSize > Specifies the number of bits of
| source address that are grouped together for the purposes of
| applying PerSourceMaxStartups limits. Values for IPv4 and
| optionally IPv6 may be specified, separated by a colon. The
| default is 32:128, which means each address is considered
| individually.
|
| Just like fail2ban, this seems like it can be equal parts
| helpful, a false sense of security, and a giant footgun.
|
| For example, allowing n invalid login attempts per time
| interval and (v4) /24 is not a big problem for botnet-based
| brute force attacks, while it's very easy for somebody to get
| unintentionally locked out when connecting from behind a CG-
| NAT.
| SoftTalker wrote:
| ufw/iptables and other firewalls can also throttle repeated
| connection attempts, which is almost always fine but could be
| something you don't want if you have a legitmate need to
| support many rapid ssh connections from the same source (CM
| tools, maybe?)
| yjftsjthsd-h wrote:
| > if you have a legitmate need to support many rapid ssh
| connections from the same source (CM tools, maybe?)
|
| If you're doing that, I strongly suggest using
| ControlMaster to reuse the connections; it makes security
| tools like this less grumpy, but it's also a nice
| performance win.
| tgv wrote:
| I managed one machine with such a mechanism, and I had to
| remove it, because it basically took all resources. I can't
| remember which daemon it was, but now the machine is only
| accessible from a limited set of ip addresses.
| tomxor wrote:
| I've used fail2ban in production for many years but eventually
| removed it due to causing very large iptables leading high
| memory use and ultimately a source of instability for other
| services (i.e it turns into a DDoS vulnerability for the whole
| server). I know the usual advice then is to reduce ban time and
| just not have permabanning, but that seems to kind of defeat
| the purpose.
|
| I wonder how this SSH feature differs since it's implemented at
| the SSH level.
|
| So long as the SSH and or PAM config requires more than a
| password (I use hardware keys), the main concern to me is log
| noise (making it hard to identify targeted security threats)
| and SSH DDoS. I know tarpits and alternative ports are another
| way of dealing with that, but when SSH is used for many things
| having to change the port is kind of annoying.
|
| I think I'm probably just going to end up layering it like
| everyone else and stick everything behind a wireguard gateway,
| although that concept makes me slightly anxious about that
| single point of access failure.
| yjftsjthsd-h wrote:
| > I've used fail2ban in production for many years but
| eventually removed it due to causing very large iptables
| leading high memory use and ultimately a source of
| instability for other services (i.e it turns into a DDoS
| vulnerability for the whole server). I know the usual advice
| then is to reduce ban time and just not have permabanning,
| but that seems to kind of defeat the purpose.
|
| Didn't the advice switch to using ipset a while back,
| precisely in the name of efficiency?
| tomxor wrote:
| Interesting thanks, I hadn't heard of that option.
| KennyBlanken wrote:
| > causing very large iptables leading high memory use
|
| > I know the usual advice then is to reduce ban time and just
| not have permabanning, but that seems to kind of defeat the
| purpose.
|
| The purpose is to make random password attempts even more
| impractical. With even fairly lax fail2ban rules, it'll take
| multiple lifetimes to find a password made up of just two
| _common use_ english words.
|
| However, that's not really their goal. I think that these SSH
| probes are mostly intended to find systems that have been
| compromised and have common backdoor passwords, though.
| ...and they use networks of zombie machines to do it.
|
| That's where stuff like Crowdsec and IP ban lists come in,
| with the side benefit of your IP addresses becoming less
| 'visible'
| yardstick wrote:
| Sounds like you were running SSH on the default port tcp/22?
| I would expect attacks to exponentially drop off as soon as
| you move to a custom port.
| Grimeton wrote:
| pam-script with xt_recent works just fine.
|
| Everytime when an authentication fails, you add the ip address to
| the xt_recent list in /proc and in iptables you just check via
| --hits and --seconds and then reject the connection attempt the
| next time.
| cedws wrote:
| The OpenBSD approach to security always seems to be _adding_
| things rather than removing them. For example, this feature is
| intended to make it harder for attackers to break in by guessing
| the password. So why not remove password authentication, or
| enforce a minimum password complexity? Password auth for SSH is
| almost always a bad idea anyway - good, secure software should
| nudge people towards using it securely, not give them the option
| to configure it with a gaping security hole.
|
| It's the same with the OpenBSD operating system. There's so much
| extremely obscure, complex code that attempts to address the same
| problems we have been dealing with for 30+ years. What if we
| started removing code and _reducing_ the attack surface instead
| of trying to patch over them, or we came up with an entirely new
| approach?
|
| A good example of how code should be stripped down like this is
| WireGuard vs the old VPNs. WireGuard came along with fresh
| cryptography, took all of the bells, whistles, and knobs away and
| now provides an in-kernel VPN in a _fraction_ of the LOC of IPsec
| or OpenVPN. As a result, it can be proven to be significantly
| more secure, and it 's more performant too.
| idunnoman1222 wrote:
| If you want password auth, you already have to change a default
| setting in SSHD and restart it. How exactly is removing that as
| a option 'less complex' for the downstream distros?
| cedws wrote:
| I don't really understand your question. Removing password
| auth reduces code complexity and therefore attack surface
| whilst also preventing users from using the software with a
| dangerous configuration. Maybe the users don't want that, but
| tough shit, maybe it's the nudge they need to use SSH keys.
| joshuaissac wrote:
| In practice, this will just result in people and
| organisations using the last version of OpenSSH that
| supports password authentication.
| tedunangst wrote:
| That's a pretty weird summary of openbsd development.
| dd_xplore wrote:
| OpenSSH is used in variety of platforms, enforcing secret key
| will prohibit it's usage in lot of places due to the added
| complexity.
| wkat4242 wrote:
| Indeed. And then someone will just fork it and the situation
| will be messier.
| SoftTalker wrote:
| You can (and need) to do both. And OpenBSD does. LibreSSL as
| one example removed a huge amount of dead/spaghetti/obsolete
| code from OpenSSL. And they are removing old/obsolete features
| all the time. Do you use OpenBSD? Do you read the release
| notes?
| cedws wrote:
| That's not really good enough though, the distros just enable
| the build flags that let them do naughty things. The
| _software_ needs to be opinionated on how to use it securely,
| not leave it up to the users, because the developers that
| wrote it probably know best! The code simply needs to not
| exist. If users want to fork and maintain their own insecure
| branch, let them.
| adamrt wrote:
| OpenBSD is also known for this. They constantly push back
| against adding configuration knobs or running non standard
| configurations.
|
| Have you used OpenBSD? You're telling them they should be
| doing something, that is already basically their mission
| statement.
| cedws wrote:
| Looking at OpenSSH tells a different story. It is a
| massive, overly configurable behemoth. The 'WireGuard of
| SSH' would be 1% of the LOC. It would not provide
| password auth, or let you log in as root with password
| auth, or let you use old insecure ciphers.
|
| Maybe OpenBSD itself is better at sticking to these
| principles than OpenSSH. I haven't used (experimented
| with) it for ~5 years but read about various updates
| every so often.
| akerl_ wrote:
| As the parent comments note, LibreSSL ripped out tons of
| code. Not "hidden behind build flags". Deleted.
|
| There's plenty of flaws with any project, but OpenBSD is
| pretty well known for doing exactly the thing you're
| claiming they don't do.
| karmarepellent wrote:
| Just for info: there are alternative SSH server implementations
| out there that disable features that are discouraged (e.g.
| password authentication)[0]
|
| Tinyssh is just one I already knew, I suppose you would find
| more via a proper search.
|
| [0] https://tinyssh.org/
| freedomben wrote:
| By removing password auth from openssh, you're not reducing the
| complexity, you're just moving it somewhere else. I would argue
| that you're actually adding significantly more complexity
| because now users/admins can't just bootstrap by using a
| default or generated root password on a new machine, creating a
| user, copying over the public key, and then disabling password
| auth. Now you have to figure out how to get that key into the
| image, an image you may or may not control. God help you if you
| don't have physical access to the machine.
|
| Edit: I realized after posting that I was equivocating on
| "complexity" a bit because you're talking about code complexity
| for openssh itself. I don't disagree with you that openssh
| itself would be less complex and more secure without password
| auth features, but I think it would have spillover effect that
| isn't a net positive when considering the whole picture.
| yjftsjthsd-h wrote:
| > It's the same with the OpenBSD operating system. There's so
| much extremely obscure, complex code that attempts to address
| the same problems we have been dealing with for 30+ years. What
| if we started removing code and reducing the attack surface
| instead of trying to patch over them, or we came up with an
| entirely new approach?
|
| OpenBSD absolutely removes things: Bluetooth, Linux binary
| compatibility, and sudo, off the top of my head, with the
| sudo->doas replacement being _exactly_ what you 're asking for.
| arp242 wrote:
| Also Apache - httpd, sendmail - (open)smtpd, ntpd -
| (open)ntpd. Probably some other things I'm forgetting.
|
| I've seen a number of reasonable criticisms of OpenBSD over
| the years. Not being minimalist enough is certainly a novel
| one.
| adamrt wrote:
| I can't think of any long term, open source project that has
| removed and ripped out more code than OpenBSD.
|
| They are know for doing exactly what you are suggesting.
|
| Go ask @tedunangst. It was literally called "tedu'd" for
| ripping out old crusty code.
| Someone1234 wrote:
| This is great, and helps solve several problems at once.
|
| I would like to remind everyone that an internet facing SSH with
| a password is very unwise. I would argue you need to be able to
| articulate the justification for it, using keys is actually more
| convenient and significantly more secure.
|
| Aside from initial boot, I cannot think of the last time I used a
| password for SSH instead of a key even on a LAN. Support for keys
| is universal and has been for most of my lifespan.
| timw4mail wrote:
| Any time you access an SSH connection from a different
| computer, you basically need the password.
| LtWorf wrote:
| If it's in the cloud, you pass the public key when creating
| the vm. If it's a real machine, ask the data center person to
| do it.
| krisoft wrote:
| This is not true. SSH keys are a viable alternative.
| sseagull wrote:
| If I can be charitable, I think they mean a different
| computer than one you usually use (that doesn't have the
| SSH key already in authorized_keys). Spouses computer, etc.
| traceroute66 wrote:
| > If I can be charitable, I think they mean a different
| computer than one you usually use
|
| If I can be charitable ....
|
| What the hell are you doing storing your SSH keys on-disk
| anyway ? :)
|
| Put your keys on a Yubikey, take your keys with you.
| unethical_ban wrote:
| Right, much easier than a password! And so easy to
| backup!
|
| I'm not arguing it isn't more secure. The point of this
| subthread is that SSH keys are not as easy to do ad-hoc
| as passwords, especially when moving workstations.
| nottorp wrote:
| > Right, much easier than a password! And so easy to
| backup!
|
| Extremely easy to recover from when the device you rely
| on to authenticate for everything gets lost or stolen
| too!
| doublepg23 wrote:
| Does that work with macOS? I'm currently using 1Password
| as my ssh key agent.
| koito17 wrote:
| It indeed works on Mac OS. I have been using SoloKeys
| with ed25519-sk keys for about three years now. It should
| be sufficient to run ssh-keygen -t
| ed25519-sk
|
| while a FIDO2 key is connected. You may need to touch the
| key to confirm user presence. (At least SoloKeys do).
|
| If I recall correctly, the SSH binaries provided by Apple
| don't have built-in support for signing keys, but if you
| install OpenSSH from Nix, MacPorts, etc., then you don't
| have to worry about this.
|
| Another thing to be mindful of is that some programs have
| a very low timeout for waiting on SSH authentication,
| particularly git. SSH itself will wait quite a long time
| for user presence when using a signing key, whereas Git
| requires me to confirm presence within about 5 seconds or
| else operations fail with a timeout.
| Rucadi wrote:
| It's just an usually bigger password.
| securam wrote:
| Some might argue SSH certificates are even better:
| https://smallstep.com/blog/use-ssh-certificates/
| mianosm wrote:
| There's a high bar to set for most organizations. Leveraging
| certificates is excellent if the supporting and engineering
| actors are all in accordance with how to manage and train the
| users and workforce how to use them (think root authorities,
| and revoking issued certificates from an authority).
|
| I've seen a few attempts to leverage certificates, or GPG;
| and keys nearly always are an 'easier' process with less
| burden to teach (which smart(er) people at times hate to do).
| wkat4242 wrote:
| You can store your regular keys in gpg, it's a nice middle
| ground especially if you store them on a yubikey with
| openpgp.
|
| Of course OpenSSH also supports fido2 now but it's pretty
| new and many embedded servers don't support it. So I'm
| ignoring it for now. I need an openpgp setup for my
| password manager anyway.
| KAMSPioneer wrote:
| I use both PKCS#11 and OpenPGP SSH keys and in my
| opinion, PKCS#11 is a better user experience if you don't
| also require PGP functionality. Especially if you're
| supporting MaxOS clients as you can just use
| Secretive[0]. As you say, FIDO is even better but comes
| with limitations on both client and server, which makes
| life tough.
|
| [0] https://github.com/maxgoedjen/secretive
| wkat4242 wrote:
| Oh yeah I don't really use macOS anymore. And I do really
| need PGP functionality for my password manager.
|
| I used pkcs11 before with openct and opensc (on OpenHSM
| PIV cards) and the problem I had with it was that I
| always needed to runtime-link a library to the SSH binary
| to make it work which was often causing problems on
| different platforms.
|
| The nice thing about using PGP/GPG is that it can
| simulate an SSH agent so none of this is necessary, it
| will just communicate with the agent over a local socket.
| palata wrote:
| > And I do really need PGP functionality for my password
| manager.
|
| Just curious: is it https://www.passwordstore.org/?
| upon_drumhead wrote:
| SSH Certificates are vastly different then the certificates
| you are referencing.
|
| SSH Certificates are actually just a SSH Key attested by
| another SSH Key. There's no revocation system in place, nor
| anything more advanced then "I trust key x and so any keys
| signed by X I will trust"
| karmarepellent wrote:
| I am no familiar with SSH certificates either. But if
| there is no revocation system in place, how can I be sure
| access from a person can be revoked?
|
| At our org we simply distribute SSH public keys via
| Puppet. So if some leaves, switches teams (without access
| to our servers) or their key must be renewed, we simply
| update a line in a config file and call it a day.
|
| That way we also have full control over what types of
| keys are supported and older, broken kex and signature
| algorithms are disabled.
| hotdogs wrote:
| The certificates have a validity window that sshd also
| checks. So the CA can sign a certificate for a short
| window (hours), until the user has to request a new one.
| chgs wrote:
| One department in my cops y does this - you authenticate
| once with your standard company wide oidc integration
| (which has instant JML), and you get a key for 20 hours
| (enough for even the longest shift but not enough that
| you don't need to reauth the next day).
| magmastonealex wrote:
| There is a revocation system in place (the RevokedKeys
| directive in the sshd configuration file, which seems to
| be system-wide rather than configured at the user-level.
| At least, that's the only way I've used it)
|
| I agree with the sentiment though, it is far less
| extensive than traditional X.509 certificate
| infrastructure.
| gnufx wrote:
| > SSH Certificates are vastly different then the
| certificates you are referencing.
|
| And the SSH maintainers will refuse offers of X.509
| support, with a justification.
| jeroenhd wrote:
| I like SSH certificates, and I use them on my own servers,
| but for organizations there's a nasty downside: SSH
| certificates lack good revocation logic. OCSP/CRL checks
| and certificate transparency protect browsers from this,
| but SSH doesn't have that good a solution for that.
|
| Unless you regenerate them every day or have some kind of
| elaborate synchronisation process set up on the server
| side, a malicious ex-employee could abuse the old
| credentials post-termination.
|
| This could be worked around leveraging TPMs, which would
| allow storing the keys themselves on hardware that can be
| confiscated, but standard user-based auth has a lot more
| (user-friendly) tooling and integration options.
| GordonS wrote:
| I setup a test smallstep instance recently, and it works
| really well. Setup is... complicated though, and the CLI has
| a few quirks.
| jppittma wrote:
| Holy shit. I wondered if this was possible a few weeks ago
| and couldn't find anything on it. Thanks for the link!
| hot_gril wrote:
| The more complicated something is, the higher chance I screw
| it up.
| gnufx wrote:
| Some would argue that in an organization where you'd consider
| SSH certificates, it's best to use Kerberos and have general
| SSO. (Some of the GSSAPI functionality is patched in by most
| distributions, and isn't in vanilla OpenSSH.)
| GordonS wrote:
| Another good option is making SSH only accessible over
| Tailscale or a VPN.
| nativeit wrote:
| This, with key pairs, is the best blend of security and
| convenience. I use ZeroTier and UFW on the server and it's
| really very simple and extremely reliable. On the very rare
| occasion that ZeroTier encounters a problem, or my login
| fails, I still have IPMI access through Proxmox/VMWare and/or
| my server provider.
| Someone1234 wrote:
| The two aren't exclusive of one another. We've also witnessed
| situations, with major companies, wherein an SSH "leaks"
| outside the VPN due to network misconfiguration or
| misconfiguring interfaces on the server.
|
| As I said above, keys are actually more convenient than
| passwords. Only reason people still use passwords is because
| they believe keys are difficult to use or manage.
| vaylian wrote:
| How do you protect the access to the VPN/Tailscale? I suppose
| you are not using a password?
| GordonS wrote:
| SSO and MFA, with a Microsoft account.
| _JamesA_ wrote:
| The number of expect scripts I find in production that are used
| to automate ssh password authentication is ridiculous.
| TacticalCoder wrote:
| > ... using keys is actually more convenient and significantly
| more secure.
|
| And for those for whom it's an option, using U2F keys (like
| Yubikeys) is now easily doable with SSH.
|
| So unless the attacker can hack the HSM inside your Yubikey,
| he's simply not getting your private SSH keys.
| im3w1l wrote:
| I resent that every application needs its own special snowflake
| auth method. One uses a certain 2fa app. Another uses another
| 2fa app. Another uses emailed code. Another uses text code.
| Another uses special ssh keys. Another opens a prompt in the
| browser where I have to confirm. Another uses special scoped
| tokens.
|
| Yes there are good reasons. But it is quite a hassle to manage
| too.
| KennyBlanken wrote:
| > I would like to remind everyone that an internet facing SSH
| with a password is very unwise.
|
| Bullshit. You can have a terrible password and your system will
| still be nearly impossible to get into. Also, these attackers
| are usually looking for already exploited systems that have
| backdoor account/password combos, unless they are specifically
| attacking your organization.
|
| Repeat after me: dictionary attack concerns have nothing to do
| with remote access authentication concerns.
|
| Let's say my password is two common-use English words
| (100k-200k.) That's ten billion possibilities. Assume you hit
| on my password half-way through. That would be _fifteen years_
| of continuous, 24x7x365 testing at 10 password attempts per
| second....and then there 's the small matter of you not knowing
| what my username is, or even whether you've got the right
| username or not, unless the ssh server has a timing-based
| detection attack.
|
| The only argument for putting this functionality in the daemon
| itself is that by locating it in the daemon, it can offer
| advanced application-layer capabilities, such as failing auth
| attempts _no matter what_ after the limit is tripped so that
| brute-forcing becomes more pointless - unless you get it right
| within the first few attempts, you could hit the right password
| and never know it. If they intend to implement features like
| that in the future, great - but if it 's just going to do what
| fail2ban does, then...just run fail2ban.
|
| Fail2ban has a higher overview of auth on the system, is
| completely disconnected from the ssh daemon in terms of
| monitoring and blocking, and the blocking it does happens at
| the kernel level in the networking stack instead of in
| userspace with much more overhead and in a proprietary system
| specific to SSH.
|
| As a sysadmin, this is 'yet another place you have to look' to
| see why something isn't working.
| palata wrote:
| > You can have a terrible password and your system will still
| be nearly impossible to get into.
|
| Ok, let's try an example of a terrible password for the user
| "root": "password". Is that nearly impossible to get into? Or
| does that not qualify as a "terrible password" per your
| definition?
| joelthelion wrote:
| > internet facing SSH with a password is very unwise
|
| If your password is strong, it's not.
| idunnoman1222 wrote:
| It's just fail2ban, should have been in core years ago
| RockRobotRock wrote:
| Did you forget to submit a patch for it?
| SoftTalker wrote:
| Also here, didn't gain much notice for some reason.
|
| https://news.ycombinator.com/item?id=40605449
| ComodoHacker wrote:
| Will it really help today, when anyone with any serious intent
| doesn't launch their attacks from one or two standalone hosts,
| but buys botnet capacity?
| verandaguy wrote:
| I don't think this attempts to address botnet attacks, but to
| be fair, there are very few tools that you can just run on a
| single physical or VPS host that can effectively defend against
| a botnet. Frankly, most things that aren't Cloudflare (or in
| the same ballpark) will be ineffective against well-crafted
| botnet attacks.
|
| This is useful in a defence-in-depth scenario, same as
| fail2ban. You might be able to defeat the odd hacker or
| researcher doing recon on your host, and sometimes that's good
| enough for you.
|
| If you need botnet protection, you shop around for botnet
| protection providers, and you get a botnet protection solution.
| Easy as.
| juancn wrote:
| This looks like an easy DDoS exploit waiting to happen.
| idoubtit wrote:
| I've read the commit message in the post, and read it again, but
| I did not understand how it would be configured. The penalty
| system seems complex but only 2 parameters are mentioned.
|
| From the documentation, one of these parameters is in fact a
| group of 8 parameters. I guess the separator is space, so one
| could write: PerSourcePenalties authfail:1m
| noauth:5m grace-exceeded:5m min:2m
|
| See https://man.openbsd.org/sshd_config.5#PerSourcePenalties
|
| Unfortunately, the default values are undocumented. So
| `PerSourcePenalties yes` (which will be the default value,
| according to the blog post) will apply _some_ penalties. I did
| attempt to read the source code, but I 'm reluctant to install a
| CVS client, two decades after dropping that versioning system.
| mananaysiempre wrote:
| The OpenBSD project provides a CVSWeb interface[1] and a GitHub
| mirror[2]. The portable OpenSSH project[2] that most of the
| world gets their OpenSSH from uses a Git repo[4] that also has
| a Web interface (at the same address) and a GitHub mirror[5].
| Per the code there[6], the default configuration seems to be
| PerSourcePenalties crash:90 authfail:5 noauth:1 grace-
| exceeded:20 max:600 min:15 max-sources:65536
| overflow:permissive
|
| [1] https://cvsweb.openbsd.org/
|
| [2] https://github.com/openbsd/src
|
| [3] https://www.openssh.com/portable.html
|
| [4] https://anongit.mindrot.org/openssh.git
|
| [5] https://github.com/openssh/openssh-portable
|
| [6]
| https://anongit.mindrot.org/openssh.git/tree/servconf.c?id=0...
| jiripospisil wrote:
| https://github.com/openssh/openssh-portable/commit/81c1099d2...
| janosdebugs wrote:
| Having written an SSH server that is used in a few larger places,
| I find the perspective of enabling these features on a per-
| address basis by default in the future troubling. First, with
| IPv4 this will have the potential to increasingly penalize
| innocent bystanders as CGNs are deployed. Worst case, this will
| give bad actors the option to lock the original owner out of
| their own server if they have a botnet host in the same network.
| With IPv6 on the other hand, it is trivially easy to get a new
| IP, so the protection method described here will be completely
| ineffective.
|
| From my experiments with several honeypots over a longer period
| of time, most of these attacks are dumb dictionary attacks.
| Unless you are using default everything (user, port, password),
| these attacks don't represent a significant threat and more
| targeted attacks won't be caught by this. (Please use SSH keys.)
|
| I have seen experienced sysadmins create the test user with the
| password of "test" on a live server on port 22 because they were
| having an "autopilot moment". It got hacked within 20 minutes of
| going online and these mechanisms wouldn't have saved it, the
| attacker got in on the second or third try.
|
| If you want to have a read about unsolved problems around SSH
| that should be addressed, Tatu Ylonen (the inventor of SSH) has
| written a paper about it in 2019:
| https://helda.helsinki.fi/server/api/core/bitstreams/471f0ff...
| Latty wrote:
| And even with IPv4, botnets are a common attack source, so
| hitting from many endpoints isn't _that_ hard.
|
| I'd say "well, it might catch the lowest effort attacks", but
| when SSH keys exist and solve many more problems in a much
| better way, it really does feel pointless.
|
| Maybe in an era where USB keys weren't so trivial, I'd buy the
| argument of "what if I need to access from another machine",
| but if you really worry about that, put your (password
| protected) keys on a USB stick and shove it in your wallet or
| on your keyring or whatever. (Are there security concerns
| there? Of course, but no more than typing your password in on
| some random machine.)
| janosdebugs wrote:
| You can use SSH certificate authorities (not x509) with
| OpenSSH to authorize a new key without needing to deploy a
| new key on the server. Also, Yubikeys are useful for this.
| tonyarkles wrote:
| Just a warning for people who are planning on doing this:
| it works amazingly well but if you're using it in a shared
| environment where you may end up wanting to revoke a key
| (e.g. terminating an employee) the key revocation problem
| can be a hassle. In one environment I worked in we solved
| it by issuing short-term pseudo-ephemeral keys (e.g.
| someone could get a prod key for an hour) and side-stepped
| the problem.
|
| The problem is that you can issue keys without having to
| deploy them to a fleet of servers (you sign the user's
| pubkey using your SSH CA key), but you have no way of
| revoking them without pushing an updated revocation list to
| the whole fleet. We did have a few long-term keys that were
| issued, generally for build machines and dev environments,
| and had a procedure in place to push CRLs if necessary, but
| luckily we didn't ever end up in a situation where we had
| to use it.
| tiberious726 wrote:
| Setting up regular publishing of CRLs is just part of
| setting up a CA. Is there some extra complexity with ssh
| here, or are you (rightfully) just complaining about what
| a mess CRLs are?
|
| Fun fact: it was just a few months ago that Heimdall
| Kerberos started respecting CRLs at all, that was a crazy
| bug to discover
| semi wrote:
| There's extra complexity with ssh, it has its own file of
| revoked keys in RevokedKeys and you'll have to update
| that everywhere.
|
| see https://man.openbsd.org/ssh-
| keygen.1#KEY_REVOCATION_LISTS for more info
|
| And unlike some other sshd directives that have a
| 'Command' alternative to specify a command to run instead
| of reading a file, this one doesn't, so you can't just
| DIY distribution by having it curl a shared revocation
| list.
| janosdebugs wrote:
| The hard part is making sure every one of your servers
| got the CRL update. Since last I checked OpenSSH doesn't
| have a mechanism to remotely check CRLs (like OCSP), nor
| does SSH have anything akin to OCSP stapling, it's a
| little bit of a footgun waiting to happen.
| tiberious726 wrote:
| Oh wow... That's pretty nuts. I guess the reason is to
| make it harder for people to lock themselves out of all
| their servers if OSCP or whatever is being used to
| distribute the CRL is down.
| EthanHeilman wrote:
| You might want to check out my project OpenPubkey[0] with
| uses OIDC ID Tokens inside SSH certs. For instance this
| let's you SSH with your gmail account. The ID token in
| SSH certificate expires after a few hours which makes the
| SSH certificate expire. You can also do something similar
| with SSH3 [1].
|
| [0] OpenPubkey -
| https://github.com/openpubkey/openpubkey/
|
| [1] SSH3 - https://github.com/francoismichel/ssh3
| tiberious726 wrote:
| Moneysphere lets you do this with tsigs on gpg keys. I find
| the web of trust marginally less painful than X509
| mananaysiempre wrote:
| > I have seen experienced sysadmins create the test user with
| the password of "test" on a live server on port 22 because they
| were having an "autopilot moment".
|
| pam_pwnd[1], testing passwords against the Pwned Passwords
| database, is a(n unfortunately abandoned but credibly feature
| complete) thing. (It uses the HTTP service, though, not a local
| dump.)
|
| [1] https://github.com/skx/pam_pwnd
| overstay8930 wrote:
| > With IPv6 on the other hand, it is trivially easy to get a
| new IP, so the protection method described here will be
| completely ineffective.
|
| I'm sure this will be fixed by just telling everyone to disable
| IPv6, par for the course.
| dmm wrote:
| The alternative to ipv6 is ipv4 over cgnat, which arguable
| has the same problem.
| waihtis wrote:
| Agreed. In addition to the problems you mentioned, this could
| also cause people to drop usage of SSH keys and go with a
| password instead, since it's now a "protected" authentication
| vector.
| TacticalCoder wrote:
| > First, with IPv4 this will have the potential to increasingly
| penalize innocent bystanders... Worst case, this will give bad
| actors the option to lock the original owner out of their own
| server if they have a botnet host in the same network.
|
| So instead of looking, like the author of these new options,
| for ways to make life for the bad guys harder we do nothing?
|
| Your concerned are addressed in TFA:
|
| > ... and to shield specific clients from penalty
|
| > A PerSourcePenaltyExemptList option allows certain address
| ranges to be exempt from all penalties.
|
| It's easy for the original owner to find the list of all the IP
| blocks the three or four ISPs he's legitimately be connecting
| from to that exemption list.
|
| I don't buy your argument nor all the variation on the same
| theme: _" There's a minuscule risk of X, so we absolutely
| nothing but saying there's nothing to do and we let bad guys
| roam free!"_.
|
| There's nothing more depressing than that approach.
|
| Kudos to the author of that new functionality: there may be
| issues, it may not be the panacea, but at least he's _trying_.
| usrbinbash wrote:
| > So instead of looking, like the author of these new
| options, for ways to make life for the bad guys harder we do
| nothing?
|
| The thing is, we have tools to implement this without
| changing sshd's behavior. `fail2ban` et. al. exist for a
| reason.
| sleepybrett wrote:
| Sure but if I only used fail2ban for sshd why should I
| install two separate pieces of software to handle the
| problem which the actual software I want to run has it
| built in?
| pixl97 wrote:
| Turning every piece of software into a kitchen sink
| increases its security exposure in other ways.
| fragmede wrote:
| a system where sshd outputs to a log file then someone
| else picks it up and then pokes at iptables, seems much
| more of hacky than having sshd supporting that natively,
| imo. Sshd is already tracking connection status, having
| it set the status to deny seems like less of a kitchen
| sink and more just about security. the S in ssh for
| secure, and this is just improving that.
| hnlmorg wrote:
| Normally I would agree with you, but fail2ban is a Python
| routine which forks processes based on outcomes from log
| parsing via regex. There's so many ways that can go
| wrong...and has gone wrong, from one or two experiences
| I've had in the past.
|
| This is exactly the sort of thing that should be part of
| the server. In exactly the same way that some protocol
| clients have waits between retries to avoid artificial
| rate limiting from the server.
| dfox wrote:
| The issue is that the log parsing things like fail2ban work
| asynchronously. It is probably of only theoretical
| importance, but on the other hand the meaningful threat
| actors are usually surprisingly fast.
| hnlmorg wrote:
| Yeah, they exist because nothing better was available at
| that time.
|
| It doesn't hurt to have this functionality in openssh too.
| If you still need to use fail2ban, denyhosts, or whatever,
| then don't enable the openssh behaviour feature. It's
| really that simple.
| hartator wrote:
| It would be frustrating to be denied access to your own
| servers because you are traveling and are on a bad IP for
| some reason.
|
| Picture the amount of Captchas you already getting from a
| legitimate Chrome instance, but instead of by-passable
| annoying captchas, you are just locked out.
| grepfru_it wrote:
| I have fail2ban configured on one of my servers for port 22
| (a hidden port does not have any such protections on it)
| and I regularly lock out my remote address because I fat
| finger the password. I would not suggest doing this for a
| management interface unless you have secondary access
| bartekrutkowski wrote:
| Why would you use password based auth instead of priv/pub
| key auth? You'd avoid this and many other security risks.
| fragmede wrote:
| what do you if you get mugged and you laptop and phone
| and keys are taken or stolen from you? or lost?
|
| After this party, this guy needed help, he lost his
| wallet and his phone, his sister also went to the party
| and gave him a ride there but had left. he didn't know
| her number to call her, and she'd locked down her socials
| so we couldn't use my phone to contact her. we were lucky
| that his socials weren't super locked down and managed to
| find someone that way, but priv keys are only good so
| long as you have them.
| akira2501 wrote:
| I use a yubikey. You need a password to use the key. It
| has it's own brute force management that is far less
| punishing than a remote SSH server deciding to not talk
| to me anymore.
| fragmede wrote:
| but what do you do if you don't have the key? unless it's
| implanted (which, https://dangerousthings.com/), I don't
| know that I won't lose it somehow.
| akira2501 wrote:
| My keyboard has a built in USB hub and ports. They key
| lives there. They keyboard travels with me. It's hard to
| lose.
|
| I have a backup key in storage. I have escrow mechanisms.
| These would be inconvenient, but, it's been 40 years
| since I've lost any keys or my wallet, so I feel pretty
| good about my odds.
|
| Which is what the game here is. The odds. Famously humans
| do poorly when it comes to this.
| semi wrote:
| It would also be very rare. The penalties described here
| start at 30s, I don't know the max, but presumably whatever
| is issuing the bad behavior from that IP range will give up
| at some point when the sshd stops responding rather than
| continuing to brute force at 1 attempt per some amount of
| hours.
|
| And that's still assuming you end up in a range that is
| actively attacking your sshd. It's definitely possible but
| really doesn't seem like a bad tradeoff
| hot_gril wrote:
| What's the alternative? If you get onto a bad IP today,
| you're essentially blocked from the entire Internet.
| Combined with geolocks and national firewalls, we're
| already well past the point where you need a home VPN if
| you want reliable connectivity while traveling abroad.
| janosdebugs wrote:
| There is nothing wrong with this approach if enabled as an
| informed decision. It's the part where they want to enable
| this by default I have a problem with.
|
| Things that could be done is making password auth harder to
| configure to encourage key use instead, or invest time into
| making SSH CAs less of a pain to use. (See the linked paper,
| it's not a long read.)
| benchaney wrote:
| > So instead of looking, like the author of these new
| options, for ways to make life for the bad guys harder we do
| nothing?
|
| Random brute force attempts against SSH are already a 100%
| solved problem, so doing nothing beyond maintaining the
| status quo seems pretty reasonable IMO.
|
| > I don't buy your argument nor all the variation on the same
| theme: "There's a minuscule risk of X, so we absolutely
| nothing but saying there's nothing to do and we let bad guys
| roam free!".
|
| Setting this up by default (as is being proposed) would
| definitely break a lot of existing use cases. The only risk
| that is minuscule here is the risk from not making this
| change.
|
| I don't see any particularly reason to applaud making
| software worse just because someone is "trying".
| crote wrote:
| > With IPv6 on the other hand, it is trivially easy to get a
| new IP
|
| OpenSSH already seems to take that into account by allowing you
| to penalize not just a single IP, but also an _entire subnet_.
| Enable that to penalize an entire /64 for IPv6, and you're in
| pretty much the same scenario as "single IPv4 address".
|
| I think there's some limited value in it. It could be a neat
| alternative to allowlisting your own IP which doesn't
| completely block you from accessing it from other locations.
| Block larger subnets at once if you don't care about access
| from residential connections, and it would act as a _very_
| basic filter to make annoying attacks stop. Not providing any
| real security, but at least you 're not spending any CPU cycles
| on them.
|
| On the other hand, I can definitely see CGNAT resulting in
| accidental or intentional lockouts for the real owner. Enabling
| it by default on all installations probably isn't the best
| choice.
| aftbit wrote:
| FYI it's pretty common to get a /48 or a /56 from a data
| center, or /60 from Comcast.
| hot_gril wrote:
| Maybe the only equivalent is to penalize a /32, since there
| are roughly as many of those as there are ipv4 addresses.
| janosdebugs wrote:
| That may be true mathematically, but there are no
| guarantees that a small provider won't end up having only
| a single /64, which would likely be the default unit of
| range-based blocking. Yes, it "shouldn't" happen.
| hot_gril wrote:
| Right. It's analogous to how blocking an ipv4 is unfair
| to smaller providers using cgnat. But if someone wants to
| connect to your server, you might want them to have skin
| in the game.
| janosdebugs wrote:
| The provider doesn't care, the owner of the server who
| needs to log in from their home internet at 2AM in an
| emergency cares. Bad actors have access to botnets, the
| server admin doesn't.
| hot_gril wrote:
| Unfortunately the only answer is "pay to play." If you're
| a server admin needing emergency access, you or your
| employer should pay for an ISP that isn't using cgnat
| (and has reliable connectivity). Same as how you probably
| have a real phone sim instead of a cheap voip number
| that's banned in tons of places.
|
| Or better yet, a corp VPN with good security practices so
| you don't need this fail2ban-type setup. It's also weird
| to connect from home using password-based SSH in the
| first place.
| dfox wrote:
| You cannot reasonably build an ISP network with single
| /64. RIPE assigns /32s to LIRs and LIRs are supposed to
| assign /48s downstream (which is somewhat wasteful for
| most of kinds of mass-market customers, so you get things
| like /56s and /60s).
| hot_gril wrote:
| What if it uses NAT v6 :D
| janosdebugs wrote:
| As I said, "should". In some places there will be enough
| people in the chain that won't be bothered to go to the
| LIR directly. Think small rural ISPs in small countries.
| janosdebugs wrote:
| IPv6 has the potential to be even worse. You could be
| knocking an entire provider offline. At any rate, this
| behavior should not become default.
| andix wrote:
| I had a similar experience with a Postgres database once. It
| only mirrored some publicly available statistical data, and it
| was still in early development, so I didn't give security of
| the database any attention. My intention was anyway to only
| expose it to localhost.
|
| Then I started noticing that the database was randomly "getting
| stuck" on the test system. This went on for a few times until I
| noticed that I exposed the database to the internet with
| postgres/postgres as credentials.
|
| It might have been even some "friendly" attackers that changed
| the password when they were able to log in, to protect the
| server, maybe even the hosting provider. I should totally try
| that again once and observe what commands the attackers
| actually run. A bad actor probably wouldn't change the
| password, to stay unnoticed.
| hot_gril wrote:
| How did you accidentally expose it to the Internet, was your
| host DMZ?
| janosdebugs wrote:
| I saw a Postgres story like this one. Badly managed AWS org
| with way too wide permissions, a data scientist sort of
| person set it up and promptly reconfigured the security
| group to be open to the entire internet because they needed
| to access it from home. And this was a rather large IT
| company.
| hot_gril wrote:
| Yeah on some cloud provider, the virtual networks can be
| all too confusing. But this story sounded like a home
| machine.
| pixl97 wrote:
| DMZ setting on a router makes this pretty easy.
|
| I've faced the DMZ at an IP on DHCP. Later when the host
| changed I had noticed traffic from the internet getting
| blocked on the new host and realized my mistake.
| hartator wrote:
| Yes, I agree. This seems a naive fix.
|
| Just silencing all the failed attempts may be better. So much
| noise in these logs anyway.
| grepfru_it wrote:
| Fail2ban can help with that
| hot_gril wrote:
| It's not quite fair, but if you want the best service, you have
| to pay for your own ipv4 or, in theory, a larger ipv6 block.
| Only alternative is for the ISP deploying the CGN to penalize
| users for suspicious behavior. Classic ip-based abuse fighter,
| Wikipedia banned T-Mobile USA's entire ipv6 range:
| https://news.ycombinator.com/item?id=32038215 where someone
| said they will typically block a /64, and Wikipedia says
| they'll block up to a /19.
|
| Unfortunately there's no other way. Security always goes back
| to economics; you must make the abuse cost more than it's
| worth. Phone-based 2FA is also an anti-spam measure, cause
| clean phone numbers cost $. When trying to purchase sketchy
| proxies or VPNs, it basically costs more to have a cleaner ip.
| jimmaswell wrote:
| I like being able to log into my server from anywhere without
| having to scrounge for my key file, so I end up enabling both
| methods. Never quite saw how a password you save on your disk
| and call a key is so much more secure than another password.
| sleepybrett wrote:
| Putting aside everything else. How long is your password vs
| how long is your key?
| hot_gril wrote:
| It's this, plus the potential that you've reused your
| password, or that it's been keylogged.
| marcrosoft wrote:
| My home IP doesn't change much so I just open ssh port only
| to my own IP. If I travel I'll add another IP if I need to
| ssh in. I don't get locked out because I use VPS or cloud
| provider firewall that can be changed through console after
| auth/MFA. This way SSH is never exposed to the wider
| internet.
| cubesnooper wrote:
| I've seen lots of passwords accidentally typed into an IRC
| window. Never seen that happen with an SSH key.
| arp242 wrote:
| I heard that if you type your password in HN it will
| automatically get replaced by all stars.
|
| My password is **********
|
| See: it works! Try it!
| cubesnooper wrote:
| A few more things:
|
| An SSH key can be freely reused to log in to multiple SSH
| servers without compromise. Passwords should never be reused
| between multiple servers, because the other end could log it.
|
| An SSH key can be stored in an agent, which provides some
| minor security benefits, and more importantly, adds a whole
| lot of convenience.
|
| An SSH key can be tied to a Yubikey out of the box, providing
| strong 2FA.
| janosdebugs wrote:
| Use TOTP (keyboard-interactive) and password away!
| swinglock wrote:
| It's more secure because it's resistant to MITM attacks or a
| compromised host. Because the password is sent, the private
| key isn't.
| belthesar wrote:
| This is definitely a common fallacy. While passwords and keys
| function similarly via the SSH protocol, there's two key
| things that are different. 1, your password is likely to have
| much lower entropy as a cryptographic secret (ie: you're
| shooting for 128 bits of entropy, which takes a pretty
| gnarly-sized password to replicate), and 2. SSH keys
| introduce a second layer of trust by virtue of you needing to
| add your key ID to the system before you even begin the
| authentication challenge.
|
| Password authentication, which only uses your password to
| establish you are authentically you, does not establish the
| same level of cryptographic trust, and also does not allow
| the SSH server to bail out as quickly, instead needing to
| perform more crypto operations to discover that an
| unauthorized authentication attempt is being made.
|
| To your point, you are storing the secret on your filesystem,
| and you should treat it accordingly. This is why folks
| generally advocate for the use of SSH Agents with password or
| other systems protecting your SSH key from being simply
| lifted. Even with requiring a password to unlock your key
| though, there's a pretty significant difference between key
| based and password based auth.
| mardifoufs wrote:
| Wait, how often do you connect to a ssh remote that isn't
| controlled by you or say, your workplace? Genuinely asking, I
| have not seen a use case for something like that in recent
| years so I'm curious!
| palata wrote:
| I sometimes use this: https://pico.sh/
| omoikane wrote:
| Perhaps at a university where all students in the same class
| need to SSH to the same place, possibly from the same set of
| lab machines. A poorly configured sshd could allow some
| students to DoS other students.
|
| This might be similar to the workplace scenario that you have
| in mind, but some students are more bold in trying dodgy
| things with their class accounts, because they know they
| probably won't get in big trouble at an university.
| heavyset_go wrote:
| Git over SSH
| Grimeton wrote:
| Just throw away that document and switch to kerberos.
|
| All the problems in this document are solved immediately.
| chuckadams wrote:
| I'd love to penalize any attempt at password auth. Not the IP
| addresses, just if you're dumb enough to try sending a password
| to my ssh server, you're going to wait a good long time for the
| failure response.
|
| Actually I might even want to let them into a "shell" that
| _really_ screws with them, but that 's far outside of ssh's
| scope.
| yardstick wrote:
| > Worst case, this will give bad actors the option to lock the
| original owner out of their own server if they have a botnet
| host in the same network.
|
| According to to the article, you can exempt IPs from being
| blocked. So it won't impact those coming from known IPs
| (statics, jump hosts, etc).
| gweinberg wrote:
| If a client "causes" sshd to crash, isn't that a server error?
| pluc wrote:
| So fail2ban?
| kelnos wrote:
| This seems like something I wouldn't want. I already use
| fail2ban, which does exactly the same thing, in a more generic
| manner. sshd is a security-sensitive piece of software, so
| ideally I want _less_ code running in that process, not more.
| akvadrako wrote:
| The security sensitive parts of SSH run in a separate process.
| I would assume that most of the new code would be in the
| unprivileged part.
| 3abiton wrote:
| There is also endlessh, a very fun project to deploy
| kazinator wrote:
| If these people don't know what to do with themselves next that
| much, they should so something useful, like learn git, instead of
| implementing fail2ban-style features that nobody needs or wants
| in the software itself.
|
| People who want this sort of thing and already have a single
| solution that handles multiple services have to complicate their
| setup in order to integrate this. They keep their existing
| solution for monitoring their web and mail server logs or
| whatever and then have this separate config to deal with for
| OpenSSH.
|
| What if you don't want to refuse connections that exhibit
| "undesirable behavior" but do something else, like become a black
| hole to that IP address, and perhaps others in the IP range?
|
| You want the flexibility to script arbitrary actions when
| arbitrary events are observed.
|
| In my log monitoring system (home grown), the rules are sensitive
| to whether the account being targeted is the superuser or not.
| SoftTalker wrote:
| > What if you don't want to refuse connections that exhibit
| "undesirable behavior"
|
| Then you disable the behavior by turning it off in
| /etc/ssh/sshd_config.
| olooney wrote:
| This reminds me of Zed Shaw's Utu protocol from back in the day:
|
| https://weblog.masukomi.org/2018/03/25/zed-shaws-utu-saving-...
|
| I am not a crypto guy, but my understanding is that users can
| downvote each other, and the more downvotes a user gets the
| harder the proof-of-work problem they had to solve before they
| post. If you received enough hate, your CPU would spike for a
| couple of minutes each time you tried to post, thus
| disincentivizing bad behavior.
|
| I see on github the project is officially dead now:
|
| https://github.com/zedshaw/utu
| WhatIsDukkha wrote:
| This seems like a bad fix to the problem of insisting that ssh
| continue to only use TCP.
|
| Wireguard only responds to a complete useful key from incoming
| UDP (as I understand). Probe resistant.
|
| I get the legacy argument here but it seems like almost two
| decades of "this tcp thing has some downsides for this job"?
| opentokix wrote:
| Chocker :D
| sleepydog wrote:
| I'm not a fan of this feature. First, I don't think it's going to
| help all that much for the reasons other people have stated (it's
| easy to obtain a new IP, and using ssh key-only remote login
| nullifies most attacks anyway).
|
| More importantly, though, is that it is difficult to debug why
| you can't login to a remote system, unless you've been diligent
| enough to setup remote logging and some kind of backdoor you can
| use in a pinch. I imagine many companies have some unimportant
| script running in the background that logs into a remote system
| over ssh, and the person who set it up left the company years
| ago. One password change/key rotation later, and suddenly 25% of
| employees cannot login to that remote system because the script
| got one of the office's 4 public IPv4 addresses blocked on the
| remote server.
|
| It's very easy to say "you should manage your systems better, you
| should separate your networks better", and so on. But in my line
| of work (customer support), I only hear about the issue after
| people are already locked out. And I've been on many phone calls
| where users locked themselves out of their server that had
| fail2ban setup (ubuntu setup fail2ban by default in one of its
| releases).
| a-dub wrote:
| ip addresses are kinda meaningless these days, and address based
| accounting and penalization can penalize legitimate users.
| (bitcoind has a banscore system, it's kinda cute but these kinds
| of things tend to be bandaidy)
|
| it's a hard problem. wireguard has a pretty good attempt at it
| built into its handshaking protocol, but like all of these
| things, it's not perfect.
|
| could maybe do something interesting with hashcash stamps for
| client identity assertion (with some kind of temporal validity
| window). so a client creates a hashcash stamped cookie that
| identifies itself for 30 minutes, and servers can do ban
| accounting based on said cookie.
| semi wrote:
| This is interesting but something i feel like id disable on most
| of my ssh servers as they are only exposed through a shared jump
| host, and I don't want users that have too many keys in their
| agent to cause the jump host IP to be penalized.
|
| On the jump host itself it makes sense though
| kyrofa wrote:
| Why are we building this into SSH itself? Isn't this what things
| like fail2ban are for?
| nazgu1 wrote:
| Is it something that can replace fail2ban or sshguard?
| cess11 wrote:
| So, like a crude fail2ban service?
| gnufx wrote:
| Do the people who are going on about fail2ban know whether that's
| even ported to, and included in, OpenBSD? I suspect not.
| tedunangst wrote:
| Nobody seems to have noticed that fail2ban is GPL, either.
| textninja wrote:
| A "SSHal credit score" tied to a pooled resource, yes, that will
| work out well! Kind of like how a used car purchase should come
| with all its tickets!
|
| EDIT: To this feature's credit, it's not federated centrally, so
| a DDOS to nuke IP reputation would have its blast radius limited
| to the server(s) under attack.
| tonymet wrote:
| Can you trigger a command when they are in the "penalty box" ? it
| would be nice to firewall those sources so they stop consuming
| sshd cpu
| enasterosophes wrote:
| People keep mentioning fail2ban. I claim that both this new
| behavior in sshd, and fail2ban, are unprincipled approaches to
| security. Now, I know fail2ban is a crowd favorite, so let me
| explain what I mean by unprincipled.
|
| This is the problem fail2ban (and now sshd) try to solve: I want
| a few people to log into my computer, so I open my computer to
| billions of other computers around the world and allow anyone to
| make a login attempt, and then I want to stop all the
| illegitimate attempts, after they were already able to access
| port 22.
|
| It's simple Bayesian probability that any attempt to head off all
| those illegitimate accesses will routinely result in situations
| where legitimate users are blocked just due to random mistakes
| rather than malicious intent. Meanwhile, illegitimate attempts
| continue to come en masse thanks to botnets, allowing anyone with
| an ssh exploit the chance to try their luck against your server.
|
| A more principled approach to security is to not roll out the
| welcome mat in the first place. Instead of opening up sshd to the
| world, allowing anyone to try, and then blocking them, instead
| _don 't open up sshd to the world in the first place._
|
| 1. If possible, only permit logins from known and (relatively)
| trusted networks, or at least networks where you have some
| recourse if someone on the same network tries to attack you.
|
| 2. If access is needed from an untrusted network, use wireguard
| or similar, so sshd only needs to trust the wireguard connection.
| Any attempt at illegitimate access needs to crack both wireguard
| and ssh.
|
| With those one or two simple measures in place, have another look
| at your sshd auth logs and marvel at the silence of no one trying
| to attack you a million times per day, while also having
| confidence that you will never accidentally lock yourself out.
___________________________________________________________________
(page generated 2024-06-07 23:00 UTC)