Restricting ssh access

B

balanga

It appears that people are trying to hack into my VPS because I see quite a number of failed attempts from people attempting to login. It's only a matter of time before someone manages to discover the password so I want to restrict access to my VPS but am unsure how to do it.

Since I don't have a fixed IP I can't restrict access via IP address.

Any suggestions?

I
 
You really should set a password that is not easily cracked. Even with eight characters of random lowercase/uppercase letters and the 0-9 digits you can get enough randomness to have a strong enough password. Eight such random characters should be possible to remember without writing down. As example passwords, I took these from the password generator at https://www.grc.com/passwords.htm by selecting eight character snippets from the third box (63 random alpha-numeric characters (a-z, A-Z, 0-9)):

Code: 
Jyh2cQVi
P6d6Uys3

I guarantee that those are not crackable by brute force over the internet by trying the password on SSH login. Cracking those requires direct access to the password hashes (master.passwd(5)) that only an intruder that has managed to get superuser privileges could access.
 
Install security/sshguard or security/py-fail2ban. I personally like sshguard because it has no dependencies, fail2ban uses Python and therefore has more dependencies. It is however a lot more versatile.

kpa said:
I guarantee that those are not crackable by brute force over the internet by trying the password on SSH login
Click to expand...
Any password can be brute-forced. That's the whole nature of a brute-force attack. It's just a matter of time. Most internet attacks are however not really brute-force attacks. They're more like dictionary attacks (using well known passwords).
 
I'd definitely opt to use key authentication only and disable password logins entirely. The advantage should be obvious: you can use a (relatively) easy to use password to protect your key without the easy password directly compromising security. Because the actual authentication will be done using the key, not the password. Even popular SSH clients on Windows (thinking PuTTY here) fully support this method.

Of course there is the issue of making sure that your keys are available where you need them.
 
Yeah, that's a good recommendation as well. Since you're on a VPS the SSH access is the only way to access your system, you can always log on to the system console remotely via the management page
SirDice said:
Install security/sshguard or security/py-fail2ban. I personally like sshguard because it has no dependencies, fail2ban uses Python and therefore has more dependencies. It is however a lot more versatile.


Any password can be brute-forced. That's the whole nature of a brute-force attack. It's just a matter of time. Most internet attacks are however not really brute-force attacks. They're more like dictionary attacks (using well known passwords).
Click to expand...

Yes I agree, my point though is that the passwords I showcased are already of such complexity that brute-forcing them over a network connection is not feasible because of the large enough turn-around time for each guess attempt.
 
Use security/sshguard-pf if you use PF. Then use it like this:
Code: 
table <sshguard> persist

block in quick on $ext_if from <sshguard>
Nothing more would be needed.

I do recommend adding your own IP addresses to the whitelist. Or else you might lock yourself out ;)
 
I recommend adding something like AllowGroups wheel staff to /etc/ssh/sshd_config. See sshd_config(5) for a description. That provides a nice additional layer of protection, just in case one of the standard users gains a weak or null password (which really should not happen, but it's still nice to know that ssh is limited to only the real users who actually need it, following the security best practice of "deny all, permit specific").

It should also go without saying that the default PermitRootLogin no should never be opened up on a host which allows access from a large chunk of public address space. Even with things like fail2ban, any password can theoretically be brute forced by a suitably persistent attacker willing to throw (stolen, illegally used) resources at it, and they do keep trying root (according to my logs) despite it being blocked by default in most modern operating systems / ssh daemons. With root blocked, they need much more to get a full compromise (username of a wheel user, that user's password, then the root password), unless something has been added to let them get direct to root from the wheel user. Keep your wheel users minimised, to people who actually have some reasonable understanding of security.

kpa said:
Yes I agree, my point though is that the passwords I showcased are already of such complexity that brute-forcing them over a network connection is not feasible because of the large enough turn-around time for each guess attempt.
Click to expand...

Strong passwords just make it harder to brute force, they don't prevent it. It becomes feasible if the attacker is willing to spend a long time slowly working at it using a vast number of compromised hosts or dynamic address space. With IPv6, each host could have between 2^64 and 2^80 addresses, and it becomes harder to reliably ban specific problem hosts by address (you have no way of knowing if a host's address is a /48, /56, /64, or /128, so essentially impossible to reliably ban just the problem host without collateral damage). If the host has RFC 4941 enabled, the network stack kindly takes care of constantly changing the source address to random numbers within the same subnet.

Your examples are certainly difficult to brute force, but not impossible. Don't use FIPS 181, or similar, on its own (not that those looked like FIPS passwords, they just reminded me of that approach), without further protection… FIPS 181 actually makes it easier to brute force, if the attacker suspects that it is being used, over systems using the full range of strong passwords.
 
kpa said:
Yeah, that's a good recommendation as well. Since you're on a VPS the SSH access is the only way to access your system, you can always log on to the system console remotely via the management page
Click to expand...

What management page?
 
balanga said:
I must admit, I've never used key authentication - never understood it.
Click to expand...
It's really easy once you know how.

  • Generate a key: ssh-keygen
  • Copy the public part of the key to the server: cat ~/.ssh/id_rsa.pub | ssh me@myserver "cat >> ~/.ssh/authorized_keys"
 
SirDice said:
It's really easy once you know how.

  • Generate a key: ssh-keygen
  • Copy the public part of the key to the server: cat ~/.ssh/id_rsa.pub | ssh me@myserver "cat >> ~/.ssh/authorized_keys"
Click to expand...

On FreeBSD 10.0 and newer, you can also use the convenience utility ssh-copy-id(1) to do the key copying for you. It takes care of creating .ssh if needed, avoids key duplication, copying multiple keys, file permissions, and security context on remote Linux systems.
 
SirDice said:
It's really easy once you know how.

  • Generate a key: ssh-keygen
  • Copy the public part of the key to the server: cat ~/.ssh/id_rsa.pub | ssh me@myserver "cat >> ~/.ssh/authorized_keys"
Click to expand...


Can I use the same key from any computer, from any location?
 
balanga said:
It appears that people are trying to hack into my VPS because I see quite a number of failed attempts from people attempting to login. It's only a matter of time before someone manages to discover the password so I want to restrict access to my VPS but am unsure how to do it.
Click to expand...

No, it is not just a matter of time unless you've not set it up correctly. Getting break in attempts at even 100 per minute is just normal and nothing to worry about.

Key authentication has been mentioned, but even if you don't set that up you should disable root login. With even just that, they would have to guess two different passwords and some random username. That's quite a lot right there. As mentioned above you should install Fail2Ban. Remember to set bantime to a couple of days and maxretry=2. Even with the ones that cycle through many IPs, there is just no way they can get through that in a thousand years. You'll be safe. However, make sure to exclude your own IP so you don't get locked out. We've all left our caps lock on for passwords and silly stuff like that. Nevertheless, with a VPS you will also have a backup of being able to login through a temporary virtual terminal in SolusVM or what ever control panel the provider has given you.

Yes, it's scary when you first see the ghoules looking in your window, but you'll get used to it. :)
 
Murph said:
... Strong passwords just make it harder to brute force, they don't prevent it. It becomes feasible if the attacker is willing to spend a long time slowly working at it using a vast number of compromised hosts or dynamic address space. ...
Click to expand...

Murph, the difference between Mathematics and Urban Legends becomes apparent by your above statement.

Mathematics
Let’s assume the password is 8 characters long and randomly formed out of the digits 0-9 and the 52 lower+upper case letters of the ISO basic Latin Alphabet. In the real random case, an attacker would need to brute force up to:

Number of Variations with Repetition: n**k = 62**8 = 218.340.105.584.896

Let's assume a very, very, very, very fast internet connection with a latency of perhaps 100 µs, i.e. 10000 trials per second. 218340105584896/10000/3600/24 = 252708.5 days -- good luck!

So, I fully agree with kpa, that random passwords with 8 characters are secure enough. The various password policy ideas, may do more harm than good, if the policy defeats randomness.

Urban Legend
Even a blind hen sometimes finds a grain.


The other urban legend about the benefits of disabling root login, can be debunked by the way of mathematics as well -- SSHd – Permit root login! So what?
 
Actually I ran those passwords trough a strength test at http://rumkin.com/tools/password/passchk.php and they came out at 34-36 bits of "enthropy" so that's the kind of worst case complexity. I calculated that if you could hammer an SSH login with 50 tries a second (quite unrealistic as far as I know because SSH login deliberately has a certain delay in answering the login result) it would take more than two years for an attacker to do an exhaustive search over the whole search field and of course about one year on average to break the password.

Do note that this doesn't take into account any kind of possible timing attacks or such techniques as "padding oracle" that might be possible on the SSH protocol. If such techniques are possible then it changes the picture completely. SSH already has known vulnerabilities when used with older ciphers and mac codes that it can leak small amounts of encrypted data with cleverly constructed timing attacks. Those were mitigated by the so called "encrypt then mac" message authentication codes in the newer versions of SSH.
 
balanga said:
I must admit, I've never used key authentication - never understood it.
Click to expand...
Easy to read -> https://www.digitalocean.com/commun...ing-the-ssh-encryption-and-connection-process

However, I would also suggest to change the default port to an upper port. You will get rid of the noise in your logs.
Like kpa said, it is very difficult indeed for someone to break a good password. I personally use keys not only for security but for convenience as well. It is hard to remember a strong password sometimes.
 
The reality of password cracking via SSH in this case is that you only have a few tries at it at a time. So how short does a password need to be in order to be able to guess it in a couple dozen tries? As mentioned by kpa, even just 50 tries a second is highly unlikely. And a I mentioned above, on my servers I allow only 2 tries total. Even a 2 letter password would work fine for very strong security. There is indeed a lot of urban myth around this stuff.

balanga The importance of difficult to crack passwords comes into play when an attacker has direct access such as when they're already in.
 
SirDice said:
It's really easy once you know how.

  • Generate a key: ssh-keygen
  • Copy the public part of the key to the server: cat ~/.ssh/id_rsa.pub | ssh me@myserver "cat >> ~/.ssh/authorized_keys"
Click to expand...
One thing though (comment is basically meant for balanga): if you do go this route and got the whole thing set up then don't forget to also disable password based logins.
 
If you can elevate to (or are a member of) wheel group, then typically the master password file can be 'copied' and brute forced 'locally' (much quicker).
 
rufwoof said:
If you can elevate to (or are a member of) wheel group, then typically the master password file can be 'copied' and brute forced 'locally' (much quicker).
Click to expand...
First of all I fail to understand how this has anything to do with the topic of restricting SSH.

Second: please do your homework before making unfounded statements like these:
Code: 
peter@zefiris:/etc $ id
uid=1001(peter) gid=1001(peter) groups=1001(peter),0(wheel),964(git),1003(torrent),1006(dvd)
peter@zefiris:/etc $ ls -ld master*
-rw-------  1 root  wheel  4123 Oct 28 16:26 master.passwd
peter@zefiris:/etc $ cat master.passwd 
cat: master.passwd: Permission denied
 
You must log in or register to reply here.
Back
Top