13 ms·

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 fut

• 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.
    • tonyarkles 2y ago
      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 2y ago
        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 2y ago
          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 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.
• mananaysiempre 2y ago
  > 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 https://github.com/skx/pam_pwnd
  • 1oooqooq 2y ago
    meh. enabling any of the (fully local) complexity rules pretty much had the same practical effect of checking against a leak. if the password have decent entropy, it won't be in the top 1000 of the leaks so not used in blond brute force like this.
• overstay8930 2y ago
  > 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 2y ago
    The alternative to ipv6 is ipv4 over cgnat, which arguable has the same problem.
  • deleted 2y ago
    [deleted]
• waihtis 2y ago
  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 2y ago
  > 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 2y ago
    > 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 2y ago
      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 2y ago
        Turning every piece of software into a kitchen sink increases its security exposure in other ways.
        • fragmede 2y ago
          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.
• crote 2y ago
  > 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.
  • janosdebugs 2y ago
    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.
  • aftbit 2y ago
    FYI it's pretty common to get a /48 or a /56 from a data center, or /60 from Comcast.
    • hot_gril 2y ago
      Maybe the only equivalent is to penalize a /32, since there are roughly as many of those as there are ipv4 addresses.
      • aftbit 2y ago
        My ISP has a /28 block, so if they chose to penalize my /32 for some reason, that would include 1/16th of the customers of my ISP. Just guessing based on population and situation, that might include on the order of 50000 people.
      • janosdebugs 2y ago
• andix 2y ago
  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 2y ago
    How did you accidentally expose it to the Internet, was your host DMZ?
    • janosdebugs 2y ago
      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 2y ago
        Yeah on some cloud provider, the virtual networks can be all too confusing. But this story sounded like a home machine.
        • pixl97 2y ago
          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.
    • 2y ago
• hartator 2y ago
  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 2y ago
    Fail2ban can help with that
• hot_gril 2y ago
  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 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 2y ago
  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 2y ago
    Putting aside everything else. How long is your password vs how long is your key?
    • hot_gril 2y ago
      It's this, plus the potential that you've reused your password, or that it's been keylogged.
  • marcrosoft 2y ago
    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.
    • dizhn 2y ago
      Another option is putting SSH on an IP on the wireguard only subnet.
      • sleepybrett 2y ago
        I've recently done this for all my boxes, but tailscale over barebones wireguard. So fucking awesome. I just run tailscale at all times on all my boxes, all my dns regardless of what network i'm on goes to my internal server that upstreams over tls. It's great, and tailscale is a snap to set up.
  • cubesnooper 2y ago
    I’ve seen lots of passwords accidentally typed into an IRC window. Never seen that happen with an SSH key.
• mardifoufs 2y ago
  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!
  • deleted 2y ago
    [deleted]
  • palata 2y ago
    I sometimes use this: https://pico.sh/ https://pico.sh/
  • omoikane 2y ago
    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 2y ago
    Git over SSH
  • asveikau 2y ago
    GitHub is an example of a service that would want to disable this option. They get lots of legit ssh connections from all over the world including people who may be behind large NATs.
    • mardifoufs 2y ago
      I somehow didn't think about that, even if I used that feature just a few hours ago! Now I'm curious about how GitHub handles the ssh infra at that scale...
      • asveikau 2y ago
• Grimeton 2y ago
  Just throw away that document and switch to kerberos. All the problems in this document are solved immediately.
• chuckadams 2y ago
  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.
  • mike_hock 2y ago
    I certainly don't want to expose any more surface area than necessary to potential exploits by an attacker who hasn't authenticated successfully.
    • chuckadams 2y ago
      Yeah you're right, the screw-with-them-shell would have to be strictly a honeypot thing, with a custom-compiled ssh and all the usual guard rails around a honeypot. The password tarpit could stay, though script kiddie tools probably scale well enough now that it's not costing them much of anything.
• yardstick 2y ago
  > 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).
  • 1oooqooq 2y ago
    most places barely even have the essential monthly email with essential services' ip in case of dns outage. nobody cares about ips.
• skissane 2y ago
  > 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. Is it possible to create some kind of reverse proxy for SSH which blocks password-based authentication, and furthermore only allows authentication by a known list of public keys? The idea would be SSH to the reverse proxy, if you authenticate with an authorised public key (or certificate or whatever) it forwards your connection to the backend SSH server; all attempts to authenticate with a password are automatically rejected and never reach the backend. In some ways what I'm describing here is a "bastion" or "jumphost", but in implementations of that idea I've seen, you SSH to the bastion/jumphost, get a shell, and then SSH again to the backend SSH – whereas I am talking about a proxy which automatically connects to the backend SSH using the same credentials once you have authenticated to it. Furthermore, using a generic Linux box as a bastion/jumphost, you run the same risk that someone might create a weak password account–you can disable password authentication in the sshd config but what if someone turns it on? With this "intercepting proxy" idea, the proxy wouldn't even have any code to support password authentication, so you couldn't ever turn it on.
  • lcampbell 2y ago
    > what if someone turns [password authentication back] on sshd_config requires root to modify, so you've got bigger problems than weak passwords at this point.
    • skissane 2y ago
      It is a lot more likely for some random admin to inappropriately change a single boolean config setting as root, than for them to replace an entire software package which (by design) doesn't have code for a certain feature with one that does.
  • Too 2y ago
    Check out the ProxyJump and ProxyCommand option in ssh config. They let you skip the intermediate shell.
• Too 2y ago
  Interesting paper from Tatu Ylonen. He seem to be quick on throwing out the idea of certificates only because there is no hardened CA available today? Wouldn’t it be better to solve that problem, rather than going in circles and making up new novel ways of using keys? Call it what you want, reduced to their bare essentials, in the end you either have delegated trust through a CA or a key administration problem. Whichever path you choose, it must be backed by a robust and widely adopted implementation to be successful.
  • janosdebugs 2y ago
    As far as OpenSSH is concerned, I believe the main problem is that there is no centralized revocation functionality. You have to distribute your revocation lists via an external mechanism and ensure that all your servers are up to date. There is no built-in mechanism like OCSP, or better yet, OCSP stapling in SSH. You could use Kerberos, but it's a royal pain to set up and OpenSSH is pretty much the defacto standard when it comes to SSH servers.
• solatic 2y ago
  Serious question: why doesn't OpenSSH declare, with about a year's notice ahead of time, the intent to cut a new major release that drops support for password-based authentication?
  • janosdebugs 2y ago
    There are very legit reasons to use passwords, for example in conjunction with a second factor. Authentication methods can also be chained.
  • jamesrr39 2y ago
    By the time it gets into distros' package managers, is it not often that long (or more) anyway?
  • DEADMINCE 2y ago
    Password authentication is still entirely necessary. I don't want to have to setup keys just to ssh into a VM I just setup, as one very minor example.
• qwertox 2y ago
  > innocent bystanders as CGNs are deployed SSH is not HTTPS, a resource meant for the everyday consumer. If you know that you're behind a CGN, as a developer, an admin or a tool, you can solve this by using IPv6 or a VPN. > Worst case, this will give bad actors the option to lock the original owner out of their own server Which is kind of good? Should you access your own server if you are compromised and don't know it? Plus you get the benefit of noticing that you have a problem in your intranet. I understand the POV that accessing it via CGN can lead to undesirable effects, but the benefit is worth it. Then again, what benefit does it offer over fail2ban?