11 ms·

OpenSSH introduces options to penalize undesirable behavior

401 points by zdw 2y ago

yjftsjthsd-h 2y ago
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 2y ago
  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 2y ago
    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 2y ago
      > 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.
      - aflukasz 2y ago
        Just remember that only first connection, the one creating ControlMaster socket, is being authenticated, subsequent ones are not.
    - megous 2y ago
      It's easy to do per source IP address and reasonably easy to add source IP address to whitelist automatically after successful auth.
- tgv 2y ago
  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 2y ago
  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 2y ago
    > 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?
    - deleted 2y ago
      [deleted]
    - tomxor 2y ago
      Interesting thanks, I hadn't heard of that option.
  - KennyBlanken 2y ago
    > 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'
Grimeton 2y ago
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 2y ago
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 2y ago
  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 2y ago
    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 2y ago
      In practice, this will just result in people and organisations using the last version of OpenSSH that supports password authentication.
  - PhilipRoman 2y ago
Someone1234 2y ago
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 2y ago
  Any time you access an SSH connection from a different computer, you basically need the password.
  - LtWorf 2y ago
    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 2y ago
    This is not true. SSH keys are a viable alternative.
    - sseagull 2y ago
      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 2y ago
        > 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.
idunnoman1222 2y ago
It’s just fail2ban, should have been in core years ago
- deleted 2y ago
  [deleted]
- RockRobotRock 2y ago
  Did you forget to submit a patch for it?
  - idunnoman1222 2y ago
    Sounds like almost as much fun as commenting on hacker news
SoftTalker 2y ago
Also here, didn't gain much notice for some reason. https://news.ycombinator.com/item?id=40605449 https://news.ycombinator.com/item?id=40605449
ComodoHacker 2y ago
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 2y ago
  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 2y ago
This looks like an easy DDoS exploit waiting to happen.
idoubtit 2y ago
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 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 2y ago
  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/ https://cvsweb.openbsd.org/ [2] https://github.com/openbsd/src https://github.com/openbsd/src [3] https://www.openssh.com/portable.html https://www.openssh.com/portable.html [4] https://anongit.mindrot.org/openssh.git https://anongit.mindrot.org/openssh.git [5] https://github.com/openssh/openssh-portable https://github.com/openssh/openssh-portable [6] https://anongit.mindrot.org/openssh.git/tree/servconf.c?id=0e0c69761a4c33ccd4a256560f522784a753d1a8#n443 https://anongit.mindrot.org/openssh.git/tree/servconf.c?id=0...
- frankjr 2y ago
  https://github.com/openssh/openssh-portable/commit/81c1099d22b81ebfd20a334ce986c4f753b0db29#diff-06a27ce3ec94735e1b3de76e872c9a5a3643d87eb63f4b9dd688d27095abbf2aR415-R432 https://github.com/openssh/openssh-portable/commit/81c1099d2...
janosdebugs 2y ago
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/471f0ffe-2626-4d12-8725-2147232d849f/content https://helda.helsinki.fi/server/api/core/bitstreams/471f0ff...
- Latty 2y ago
  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 2y ago
    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.
gweinberg 2y ago
If a client "causes" sshd to crash, isn't that a server error?
pluc 2y ago
So fail2ban?
billyrbledsoeII 2y ago
[dead]
kelnos 2y ago
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 2y ago
  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 2y ago
  There is also endlessh, a very fun project to deploy
kazinator 2y ago
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 2y ago
  > 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 2y ago
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-the-internet-with-hate/ 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 https://github.com/zedshaw/utu
WhatIsDukkha 2y ago
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 2y ago
Chocker :D
sleepydog 2y ago
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 2y ago
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 2y ago
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 2y ago
Why are we building this into SSH itself? Isn't this what things like fail2ban are for?
gnufx 2y ago
Do the people who are going on about fail2ban know whether that's even ported to, and included in, OpenBSD? I suspect not.
- tedunangst 2y ago
  Nobody seems to have noticed that fail2ban is GPL, either.
nazgu1 2y ago
Is it something that can replace fail2ban or sshguard?
cess11 2y ago
So, like a crude fail2ban service?
textninja 2y ago
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 2y ago
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 2y ago
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.
- marshray 2y ago
  1. Sure, there may be cases where you already know the source IP or network block. But there are many scenarios where your legitimate users may be traveling, or using a mobile provider that won't guarantee much about the source IP. If you open your firewall too wide, a sophisticated attacker can find some box they can proxy through. 2. Doesn't wireguard then have the same challenge as SSH? Isn't that just pushing the problem around? Another way to cut down on the log spam is by configuring sshd to listen on a nonstandard port.
  - enasterosophes 2y ago
password4321 2y ago
I would like to see support for blocking by client identifier, though if it were a default all the bots would recompile libssh. Until then this has been a great differentiator for Bitvise SSH.
WhackyIdeas 2y ago
Love it. Now I don’t even need to change the default port numbers to stop all of those damn log entries. Wonder if this is related to why Fail2Ban wasn’t in the pkg repos when I last tried to install it on OpenBSD? There is only one thing on my wish list from the OpenBSD devs out there - that you’ll figure out Nvidia drivers.
est 2y ago
no penalize, just forward the tty to a honeypot and waste the attacker's time. Any login would pass, but you have to figure out if the shell is real.

401 points by zdw 2y ago

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 2y ago
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 2y ago
  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 2y ago
    > 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.
    - aflukasz 2y ago
      Just remember that only first connection, the one creating ControlMaster socket, is being authenticated, subsequent ones are not.
  - megous 2y ago
    It's easy to do per source IP address and reasonably easy to add source IP address to whitelist automatically after successful auth.
tgv 2y ago
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 2y ago
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 2y ago
  > 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?
  - deleted 2y ago
    [deleted]
  - tomxor 2y ago
    Interesting thanks, I hadn't heard of that option.
- KennyBlanken 2y ago
  > 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'

Grimeton 2y ago

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 2y ago

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 2y ago
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 2y ago
  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 2y ago
    In practice, this will just result in people and organisations using the last version of OpenSSH that supports password authentication.
- PhilipRoman 2y ago

Someone1234 2y ago

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 2y ago
Any time you access an SSH connection from a different computer, you basically need the password.
- LtWorf 2y ago
  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 2y ago
  This is not true. SSH keys are a viable alternative.
  - sseagull 2y ago
    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 2y ago
      > 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.

idunnoman1222 2y ago

It’s just fail2ban, should have been in core years ago

deleted 2y ago
[deleted]
RockRobotRock 2y ago
Did you forget to submit a patch for it?
- idunnoman1222 2y ago
  Sounds like almost as much fun as commenting on hacker news

SoftTalker 2y ago

Also here, didn't gain much notice for some reason. https://news.ycombinator.com/item?id=40605449 https://news.ycombinator.com/item?id=40605449

ComodoHacker 2y ago

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 2y ago
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 2y ago

This looks like an easy DDoS exploit waiting to happen.

idoubtit 2y ago

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 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 2y ago
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/ https://cvsweb.openbsd.org/ [2] https://github.com/openbsd/src https://github.com/openbsd/src [3] https://www.openssh.com/portable.html https://www.openssh.com/portable.html [4] https://anongit.mindrot.org/openssh.git https://anongit.mindrot.org/openssh.git [5] https://github.com/openssh/openssh-portable https://github.com/openssh/openssh-portable [6] https://anongit.mindrot.org/openssh.git/tree/servconf.c?id=0e0c69761a4c33ccd4a256560f522784a753d1a8#n443 https://anongit.mindrot.org/openssh.git/tree/servconf.c?id=0...
frankjr 2y ago
https://github.com/openssh/openssh-portable/commit/81c1099d22b81ebfd20a334ce986c4f753b0db29#diff-06a27ce3ec94735e1b3de76e872c9a5a3643d87eb63f4b9dd688d27095abbf2aR415-R432 https://github.com/openssh/openssh-portable/commit/81c1099d2...

janosdebugs 2y ago

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/471f0ffe-2626-4d12-8725-2147232d849f/content https://helda.helsinki.fi/server/api/core/bitstreams/471f0ff...

Latty 2y ago
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 2y ago
  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.

gweinberg 2y ago

If a client "causes" sshd to crash, isn't that a server error?

pluc 2y ago

So fail2ban?

billyrbledsoeII 2y ago

[dead]

kelnos 2y ago

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 2y ago
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 2y ago
There is also endlessh, a very fun project to deploy

kazinator 2y ago

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 2y ago
> 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 2y ago

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-the-internet-with-hate/ 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 https://github.com/zedshaw/utu

WhatIsDukkha 2y ago

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 2y ago

Chocker :D

sleepydog 2y ago

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 2y ago

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 2y ago

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 2y ago

Why are we building this into SSH itself? Isn't this what things like fail2ban are for?

gnufx 2y ago

Do the people who are going on about fail2ban know whether that's even ported to, and included in, OpenBSD? I suspect not.

tedunangst 2y ago
Nobody seems to have noticed that fail2ban is GPL, either.

nazgu1 2y ago

Is it something that can replace fail2ban or sshguard?

cess11 2y ago

So, like a crude fail2ban service?

textninja 2y ago

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 2y ago

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 2y ago

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.

marshray 2y ago
1. Sure, there may be cases where you already know the source IP or network block. But there are many scenarios where your legitimate users may be traveling, or using a mobile provider that won't guarantee much about the source IP. If you open your firewall too wide, a sophisticated attacker can find some box they can proxy through. 2. Doesn't wireguard then have the same challenge as SSH? Isn't that just pushing the problem around? Another way to cut down on the log spam is by configuring sshd to listen on a nonstandard port.
- enasterosophes 2y ago

password4321 2y ago

I would like to see support for blocking by client identifier, though if it were a default all the bots would recompile libssh. Until then this has been a great differentiator for Bitvise SSH.

WhackyIdeas 2y ago

Love it. Now I don’t even need to change the default port numbers to stop all of those damn log entries. Wonder if this is related to why Fail2Ban wasn’t in the pkg repos when I last tried to install it on OpenBSD? There is only one thing on my wish list from the OpenBSD devs out there - that you’ll figure out Nvidia drivers.

est 2y ago

no penalize, just forward the tty to a honeypot and waste the attacker's time. Any login would pass, but you have to figure out if the shell is real.