help with ssh choice of autentication

wolffnx

wolffnx

Hi, this is a general question of which one of the ssh methods would be better , for server use
I know that the answer is "never open a ssh port to the internet", so, in the past I have all my servers
with ssh open to the internet..now only 2(of 6)

well, there is 2 choices:

1) ssh key

2) ssh password

I never use the ssh key method, always password with sshguard
the password method is a brute force weak point,but with sshguard is not enough?

in the other hand the keys are more complex and have enough length to make it very secure , not?
 
First of all, I wouldn't agree to never offer ssh over the internet. If you keep your system and ssh daemon up to date, it's IMHO from the technical point of view reasonably secure.

As for your questions: It's hard to tell a "single truth"(*) here. Fact is that with keys, the attack vector by brute forcing credentials is almost closed. OTOH, requiring to always have an SSH private key could be too restrictive, depending on the usecase. And, of course, it will be the user's responsibility to securely store his private key -- if the key itself isn't password protected and someone manages to steal it, the account is owned.

IMHO, it can be ok to allow password authentication, at least if you can make sure "trivial" passwords cannot be used and also implement something that slows down brute-force attacks significantly. But in the end, only you can decide.

(*) except of course: pulling the network plug makes the system secure *scnr*
 
I've been using private keys to access our servers for 16 years without issue. We've used passwords, too, but I feel far better requiring keys.
 
drhowarddrfine said:
I've been using private keys to access our servers for 16 years without issue. We've used passwords, too, but I feel far better requiring keys.
Click to expand...
This is a valid opinion! I just wanted to make clear that a) keys don't give security per-se and b) they might be cumbersome if you're somewhere remote, need to fix something important, and don't have your key with you ;)
Of course, the benefits of keys don't need to be discussed :)
 
wolffnx said:
I know that the answer is "never open a ssh port to the internet",
Click to expand...
As others already noted, there's nothing intrinsically wrong with opening ssh to the internet. You just need to be aware there's a lot of infected machines out on the internet that are going to scan it the minute you put it online. So, don't use easily guessed usernames and certainly not easily guessed passwords. You may find tools like blacklistd(8), security/sshguard and security/py-fail2ban useful to help thwart those attempts.
 
wolffnx said:
in the other hand the keys are more complex and have enough length to make it very secure , not?
Click to expand...
I always use RSA encryption 2048 bits (default) al least. If you want more security I would increase to 4096 bits but no more length
 
In case of a system failure and one needs to get in, for a PC using ssh-keys, the only way out is reaching the Qemu/KVM console, boot into single-user mode, disable use of ssh-keys, log-in with pwd (but no ashing with root) and get the job done.
 
wolffnx said:
the password method is a brute force weak point,but with sshguard is not enough?
Click to expand...
Some of the bad people on the internet are aware their connections will get blocked automatically when there's a number of failed attempts within a small time period. So they try to fly below the radar and only do 1 or 2 attempts per hour for example. SSHguard won't trigger on those. You still need to keep an eye on /var/log/auth.log. The daily security emails will also contain a list of login failures, definitely read it regularly.

in the other hand the keys are more complex and have enough length to make it very secure , not?
Click to expand...
They are theoretically more secure than passwords yes. You could still run into problems though. A couple of years ago a lot of Debian based systems were found to be vulnerable because the generated private keys were weak. This made those keys easy to hack. Other implementation failures for various systems are also found on a regular basis. You will need to keep an eye on any reported security issues too, as they may affect you too.

news.netcraft.com

SSL Certificates Vulnerable to OpenSSL Flaw on Debian | Netcraft

Netcraft's June SSL Survey has found that a significant number of SSL certificates are affected by the Debian OpenSSL vulnerability, including Extended ...
news.netcraft.com news.netcraft.com

Simple fact of the matter is that any port you open to the internet should be considered dangerous. But you can mitigate a lot of those dangers by being careful and use tried and tested configuration methods.
 
Thanks to all for your answers and experiencies , finaly the method I choose is both

the key and then password

Code: 
AuthenticationMethods publickey,keyboard-interactive

I have tested and it works as expected

1) if the remote client dont have the public key is kicked out
2)when the remote client have the remote key THEN is asked for the user password

and also protect the key with password
in a production server of course, its seems very secure


SirDice
Some of the bad people on the internet are aware their connections will get blocked automatically when there's a number of failed attempts within a small time period. So they try to fly below the radar and only do 1 or 2 attempts per hour for example. SSHguard won't trigger on those. You still need to keep an eye on /var/log/auth.log. The daily security emails will also contain a list of login failures, definitely read it regularly.
Click to expand...

Good advise, they will take maybe tooo much long time to brute-force the password,but check
the logs, and maybe one script to filter the failed attempts and send a alert to me via cron job is a good idea

and "never open a ssh port to the internet" idea is changing for "open it,but up to date and secure" ;)

Lamia
In case of a system failure and one needs to get in, for a PC using ssh-keys, the only way out is reaching the Qemu/KVM console, boot into single-user mode, disable use of ssh-keys, log-in with pwd (but no ashing with root) and get the job done.
Click to expand...

All servers are bare-metal, but you let me thinking
my question was made in a "internet and lan access scenario", but is someone get physical access
to the bare-metal server,boot it with a live system, change the sshd_config file directive of using
keys to passwords, damage the ssguard command(rename it for ex)
reboot and done, brute-force all you want

the solution firts is to protect the server(bios password,boot order,devices,etc)
but if the attack is serious ,they will reset the bios password physicaly 😕
so,whe are in the same posible attack scenario

how this can be avoided?
 
wolffnx said:
how this can be avoided?
Click to expand...
It can't really. If they have physical access they own it.
Chassis Intrusion switch might give some a warm feeling but realistically by the time they raise the lid the ethernet is already disconnected. So you might find log evidence after the fact, the break in will have already occurred.

I do remember having trouble getting BIOS access on a IBM Thinkpad. Removing the CMOS battery did not clear the BIOS password.
So something like that might work. I don't know what server boards support such a feature.
 
I'm kind of late to the party ... but two factor authentication with the pam_google_authenticator module is also a strong security enhancement if you feel a password alone isn't enough. A "benefit" for me is that I don't have to deal with creating and distributing keys. :p
 
Supermicro boards do not clear the BIOS password with a battery removal but all you need to do is re-flash the firmware to blank it.

Supermicro Bios Password / Softlayer

Hi, i have bought a Supermicro System whitch has a Bios Password set. I already Contactet Supermicro to get some help on this but the Mainboart is a OEM production for softlayer so there is no chance getting the Bios image from Supermicro to flash it. Of course i did alreayd try a Cemos reset...
forums.servethehome.com forums.servethehome.com
So it boils down to how determined they are to break in.
Plus with EFI BIOS you can restrict the boot to a drive model and UUID.
 
On a related note, I usually move the sshd to a non-standard port (below 1024) on my private machines, preventing it from being found by scans that look at the standard ports only. This is not a real security measure, of course, but it reduces visibility, and – most importantly – it reduces clutter in the log files, so it's easier to analyse the log files for real threats.

An advanced variant of that would be "port knocking" which prevents the sshd from being found even by extensive port scans, but FreeBSD doesn't support port knocking out of the box. It could probably be implemented with a small daemon that uses pcap + firewall rules, but that would be rather inefficient compared to an in-kernel implementation (Linux has this, AFAIK). Maybe this would be a nice little project for a student.
 
wolffnx said:
for server use I know that the answer is "never open a ssh port to the internet"
Click to expand...
Okay, I must be outdated… What is the modern and more secure way to log into a server without using SSH? Here's my usual setup:
  • permit SSH only to 1 special user
  • use a username like "kdUjd7jdjT5.dhd73djfbw423" (never seen something like this in the SSH login attempts)
  • allow only key based login
  • take care of this one key
  • no "comfort tools" like sudo or wget installed
Would be fine to get additional a static IP at home, so I could narrow the login down to this one IP - but that wouldn't get around the fact of an open SSH port on my server. So again: What's the alternative to SSH?
 
Just throwing my 2c in here. I allow SSH via key for one, unpriveledged user, which is a member of the wheel group.
I su to root, when needed, and have to supply root's password, which I can remember but is non-trivial.

If somebody does steal my tablet and remotes into a system, they don't have much traction.
 
jmos said:
Okay, I must be outdated… What is the modern and more secure way to log into a server without using SSH? Here's my usual setup:
  • permit SSH only to 1 special user
  • use a username like "kdUjd7jdjT5.dhd73djfbw423" (never seen something like this in the SSH login attempts)
  • allow only key based login
  • take care of this one key
  • no "comfort tools" like sudo or wget installed
Would be fine to get additional a static IP at home, so I could narrow the login down to this one IP - but that wouldn't get around the fact of an open SSH port on my server. So again: What's the alternative to SSH?
Click to expand...

no alternative,I say that
...of 8 servers only have one running ssh and from there move to the others overl the LAN
 
Actually, if you really want security, two-factor authentication (2FA) should be used.
Typically, the two factors are something that you know and something that you own (physically).
For the latter you can use a USB token, a smart card, an OTP generator on a smartphone (like FreeOTP) or similar.
By the way, OpenSSH recently (since 8.2) implemented support for FIDO / U2F tokens.

PS: Of course, the second factor could also be biometric, for example a fingerprint sensor. But I'm not sure how well these type of things are supported in FreeBSD.
 
olli@ said:
An advanced variant of that would be "port knocking" which prevents the sshd from being found even by extensive port scans, but FreeBSD doesn't support port knocking out of the box.
Click to expand...
The ports have security/knock with nice configuration options and it works like a charm!

When you give it a try make sure you have understood the usage. See knockd(1)

Learn handling first on boxes you can easy access locally! :)
 
getopt said:
The ports have security/knock with nice configuration options and it works like a charm!
Click to expand...
Well, that's exactly the kind of implementation that I described above – It's a userland daemon that needs to listen for all traffic on an interface in order to recognize the "knock" packets. It works, but it's an inefficient hack. Linux has an in-kernel implementation which is a much better approach.
 
getopt said:
At least it uses pcap(3) on FreeBSD. So it is as (in)efficient like bpf(4).
Not too bad, isn't it?
Click to expand...
Well, yes, that's true. It's certainly better than nothing.

It would be nice if ipfw(8) supported a rule action to set a table entry (not just test for it). Then table entries could be used to store state between packets, so you could implement port knocking purely with IPFW rules.
 
You must log in or register to reply here.
Back
Top