It's time for an experiment

Post Reply New Topic

About ten years ago, I was looking at the log files on one of my servers and was surprised to see approximately 1.3 million connections in a month to ssh to try to guess passwords. Half of them were from one /24 block in Beijing. Most of them were from outside the US. The other servers were about the same.

So I started blocking incoming foreign connections to port 22 on those computers. The number of tries fell to about 20 a day per server.

Since then, I have been using port 22 only for local connections. From outside our network but in the US, I used port 64022 and for anywhere in the world, I used port 65522. This was done by restricting access to each port in the firewall. It's worked fine. Every once in a while someone would stumble onto those ports and scan them and would give up.

I wasn't so worried about someone guessing passwords ads I wanted to reduce the clutter in the log files.

The other day, I changed everything around again. I went back to just using port 22 for everyone on three servers. On two of them, to connect from outside our network it requires three ssh keys to connect. That way, if one of the keys is weak, the odds are the other two will be okay and so no harm done. No passwords at all. The idea is that since it won't ask them for a password, it just rejects their attempts outright.

On the third server, I set it to require a password and then three keys. So the attacker sees the password prompt, enters a guest, and is rejected. This leaves them the possibility of guessing a password and so they keep going.

So I'm going to give them a couple of weeks for the attackers to spread the word around to try my ip addresses and then collect usage statistics for a month or two to compare the number of attempts.

It is already clear that many attackers don't try to many times on the first two servers but go on and on and on on the third server. After I finish the experiment, I am likely to make all my servers like the first two.

I may tweak it a bit. Most of my accounts do not permit remote connections anyway. For example, if kokopelli were an account, it might permit only local connections. Suppose that netadmin did allow remote connections, then I could connect from a remote location with:

ssh -J netadmin@example.com kokopelli@example.com

One problem is that I have absolutely no idea what the passwords to the accounts that permit remote connections. So I am tempted to set up an exception so that those accounts do not require the password first, just the three keys.

Something like this should work if our address block was 99.99.99.0/24:

Match User kokopelli
AuthenticationMethods publickey,publickey,publickey
ExposeAuthInfo yes
PasswordAuthentication no

Match LocalAddress 99.99.99.1
AllowGroups USAUsers WorldUsers
AuthenticationMethods password,publickey,publickey,publickey
ExposeAuthInfo yes
PasswordAuthentication yes
PermitEmptyPasswords no
PermitRootLogin no
X11Forwarding no

Currently, it just uses the LocalAddress block above.

For what it's worth, for passwords for many accounts, just generate them with "openssl -rand -rand64 100" to generate a random 100 character password and never save the address. I have learned that if you have 2,000 character password, ssh doesn't seem to know what to do with that.

Any suggestions?

Interesting. I use to play around with SSH a bit, but not for years. Didn't know you could require more than one passkey for a login.

I think I understand what the problem is - you're trying to setup two different logins for the same account because the passwords you use are not stored anywhere - one login with a password and 3 passkeys, to waste hackers time, and another login with only the 3 passkeys, without password, for legitimate use. The problem being is the setup isn't working, it doesn't setup the password login.

The obvious solution would be no filtering and use the password for legitimate logins as well, generated with a password generator within a password database such as keepassxc (but it only goes up to 128 characters ) ?

Sorry, I'm not very technical minded.

Using ProtonVPN to test it, I set up a connection through England so that my logins will come in from outside the US and it works perfectly. So to test a server across the room from me, the traffic was going from my workstation, out on the Internet, to England, back to our network, and to the destination server.

The setup of the /etc/ssh/sshd_config file can be rather odd and I did find what appears to be a minor bug in it.

When doing the Match, the first time a keyword is found in a match case, that keyword is ignored in any match cases further down.

My first match case is for loopbacks (Match Address 127.0.0.9/8,::1). The line "AuthenticationMethods publickey password" tell it to try a public key first and then, if no public key, use the password. It also permits root logins as well.

Note that the "Match Address" matches according to the address it is coming from. To match according to the address of the server, it would use a "Match LocalAddress" instead.

The next match case is for our LAN (Match Address 10.1.0.0/16). It permits anyone in the LocalUsers group to connect and is otherwise the same as for loopbacks.

Then comes our network routable block (Match Address 99.99.99.0/24) which handles connections to the server from other computers on our network such as from 99.99.99.2, 99.99.99.3, and so on. While the above blocks allow the root to login with either a key or a password, this block restricts root logins to keys only (PermitRootlogin prohibit-password).

Next (I set this up a couple of hours ago), instead of "Match User", I used "Match Group USAUsers,WorldUsers" to require addresses to any of these accounts to just use three public keys (AuthenticationMethods publickey,publickey,publickey).

Finally, we have a "Match LocalAddress 99.99.99.1" to select traffic going to this machine. This block limits the groups (AllowGroups USAUsers WorldUsers), refuses root logins (which is also covered since root is in neither of those groups), and sets the authentication method to requiring the password and three separate publickeys (AuthenticationMethods password,publickey,publickey,publickey).

Note how the AuthenticatonMethods works. "AuthenticationMethods publickey password" provides two different lists. It will first try the key and if none is found, it will then ask for the password. With spaces between the two single item lists, it is kind of like an "or". On the other hand, "AuthenticationMethods publickey,publickey" would require two distinct public keys and "AuthenticaitonMethods password,publickey,publickey,publickey" would require a password and three distinct public keys. With the comma, we just have a single list and is kind of like an "and". If we used "AuthenticationMethods publickey,publickey,password,publickey", then it would require two distinct public keys and then the password, and then a third distinct publickey.

It takes a little to get used to the way the rules work. When I first configued an ssh server with match cases, I thought the last one would take precedent. But the way it is, you can have different matches that apply to the same connection.

My cloud SSH servers listen *only* inside wireguard tunnels on said servers

I don't know that wireguard would do anything for my servers.

I need to read documentation more often. I haven't read the sshd_config documentation in two or three years. It turns out that they have some new options that look intriguing.

In particular, I should be able to have sshd block ip addresses after they fail to log in after a connection. I'm thinking of blocking them for something between two and six hours.