# help with ssh choice of autentication



## wolffnx (Jul 10, 2020)

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?


----------



## zirias@ (Jul 10, 2020)

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*


----------



## drhowarddrfine (Jul 10, 2020)

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.


----------



## zirias@ (Jul 10, 2020)

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.


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


----------



## SirDice (Jul 10, 2020)

wolffnx said:


> I know that the answer is "never open a ssh port to the internet",


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.


----------



## diego (Jul 10, 2020)

wolffnx said:


> in the other hand the keys are more complex and have enough length to make it very secure , not?


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


----------



## Lamia (Jul 10, 2020)

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.


----------



## SirDice (Jul 10, 2020)

wolffnx said:


> the password method is a brute force weak point,but with  sshguard is not enough?


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?


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. 









						SSL Certificates Vulnerable to OpenSSL Flaw on Debian | Netcraft News
					

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
				




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.


----------



## graudeejs (Jul 10, 2020)

Option 1.1) Use hardware token to store your ssh key (actually GPG key stored on token). For example I use Nitrokey Pro for past 3-4 years. I love it.


----------



## Phishfry (Jul 10, 2020)

I use ssh keys with ed25519 on my linode instances.
I also use a password on my private key.


----------



## wolffnx (Jul 12, 2020)

Thanks to all for your answers and experiencies , finaly the method I choose is both

the key and then password


```
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.



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.



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?


----------



## Phishfry (Jul 12, 2020)

wolffnx said:


> how this can be avoided?


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.


----------



## driesm (Jul 12, 2020)

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.


----------



## Phishfry (Jul 12, 2020)

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
				



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.


----------



## olli@ (Jul 12, 2020)

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.


----------



## jmos (Jul 12, 2020)

wolffnx said:


> for server use I know that the answer is "never open a ssh port to the internet"


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?


----------



## leebrown66 (Jul 12, 2020)

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.


----------



## wolffnx (Jul 13, 2020)

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)
> ...



no alternative,I say that
...of 8 servers only have one running ssh and from there move to the others overl the LAN


----------



## olli@ (Jul 13, 2020)

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.


----------



## getopt (Jul 13, 2020)

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.


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!


----------



## olli@ (Jul 13, 2020)

getopt said:


> The ports have security/knock with nice configuration options and it works like a charm!


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 (Jul 13, 2020)

olli@ said:


> It works, but it's an inefficient hack.


At least it uses pcap(3) on FreeBSD. So it is as (in)efficient like bpf(4).
Not too bad, isn't it?


----------



## olli@ (Jul 14, 2020)

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?


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.


----------

