Need help to secure my ssh

Im trying to learn linux to a "manage my own server company awesomeness level" but as of right now im still a noob, im working with ubuntu 14.04 server so terminal use only i dont have a gui installed

My main question is what are the necessary steps to secure my ssh port, every guide i look at tells me something different , should i use fail2ban or not?

{everything is running on my lan i have not portforwarded through my roughter yet}
i have no root user only sudo access to my user account
im all up to date
i have openssh installed and running
edited the ssh file to not alow root access
i have arno-iptables-firewall installed and running

Side question, I assume this should make a pretty powerful server to test on? what are my limitations with this rig?. (ive been using oracle on my laptop for the last 6 months this is my first physical dedicated machine as always tho i built it out of spare parts)

The server is running on a fx4100 with 4gb of ram on a 500gb drive on lan w/ 3mbps down & 1.5 mbps up (connection speeds are awful i know ill get that upgraded later in life =) I have no intention of upgrading the rig unless I start making money with my it )

1 Like

yes

good, no root login through ssh period

You could enable root with its own strong password though; so wen your user and the password gets compromised your root isnt as well.

way to go

Very well

I would highly suggest you to switch from password authentication for SSH to public/private key; that way your the most secure;

Depends totally on what your going to run on it - I would suggest you to at least raid1 another harddisk so if one fails your not going down immediately.

@ruberbandman109 That's unnecessary. You can simply use the root user. You need to enable public-key-authentication - or better disable password authentication. Having a locked down root user and a standard user having ssh and sudo access, doesn't make any sense - if the sudoer gets compromised, you are fucked. Here is a guide from DigitalOcean on how to set up SSH correctly.

https://www.digitalocean.com/community/tutorials/how-to-use-ssh-keys-with-digitalocean-droplets

Uhm isn't that exactly what I wrote - and you quoted it even?

Not really because root with password is a bad idea.

Public key authentication + a private key with a password is the only real option. SSH with plain text password-only authentication is never a good idea - if someone is able to read your network traffic, he would get the password and would have access to the server; with public-key authentication, he still needs your private and public key to get to the server - so he would basically need to steal the files from your PC.

Also having a second user being a sudoer is bad. If this user gets compromised it can do equal damage to the system - it's almost like having two root users and trying to secure both; just adds more possible points of failure.

Here is what could happen:

  1. sudoer gets compromised
  2. attacker connects to the server
  3. attacker edits sshd config and disables root access
  4. attacker restarts sshd
  5. attacker creates a new user, deploys public key and grants sudo access
  6. attacker disconnects
  7. attacker reconnects using his new user
  8. attacker removes original sudoer
  9. attacker is the only person being able to access the machine
  10. GG

So, if the only user that has public/private key enabled for SSH, SSH with passwords is disabled, sudo is not used and root has a strong password, where is the problem?

I would not want to have the ssh private key to a direct root shell on my laptop, even with its hard-disk being fully encrypted.
Having the key password protected is good, but it is prone to offline brute forcing; if you got the private key you can have hascat or jacktheripper have their way on it without anyone knowing until it is to late.

ssh -> private/public key -> normal user -> su root -> password -> root

SSH does not support plain text passwords - ever sniffed a SSH connection? I is NOT telnet ;-)
Even if you authenticate against a SSH server with a password, the password is already being transited over an encrypted channel which is secured by fingerprinting.

So the only way to MITM that would be on the very first connect ever made, and keep the MITM atack running for as long as the macine is running or if the person connecting ignores the warning and removes the fingerprint of the server from the known hosts file.

I am totally aware of that attack vector;
With my approach of having and unprivileged user being the one allowed to connect to SSH with ppk (passwords completely disabled for SSH if not needed) and than having su to root the off line attack against a lost private key (for the unprivileged user) is mitigated by starveling login attempts to root; I have an e-mail alert after 3 attempts to su root without success.

So even if the ppk got compromised by the private key being stolen the atacker is still at user level and either needs the root password or a exploit for a local privilege escalation.

damn i just checked my server log and

"There were 475 failed login attempts since the last successful login."

last time i logged was like 4 hours ago.. ok.. time to open SSH port just for my IP

If you have port 22 open to the internet you're going to get a lot of bots and script kiddies trying to brute force it. But don't worry too much. If you're using public keys and have passwords disabled they're not going to get in, even a decent password will stop them as they're just looking for the weakest configurations.

If you want you can change the port from 22 to something else, this will pretty much stop these kinds of attacks. And setting up fail2ban will stop these attacks as well.

well i blacklisted "all" and allowed only my IP in server hosts file, changed password to like 32 char "matrix style" and probably gonna open 22 just for my IP as last wall :)

checked log, surprise!! it was Chinese IP :D

... and i installed fail2ban

We talk about two different things.

is totally fine.

ssh -> private/public key -> privileged user -> sudo <everything I want>

is the problem.

If you have a privileged user's ppk, that will be a problem - that's what the OP seems to have.

I thought you were talking about a "strong" SSH password since the thread title says "Need help to secure my SSH".
A lot of "admins" are not aware of "su root" and simply use sudo everywhere without understanding the security issue.
That's what was my point - a privileged user with SSH is not better than root without SSH.

1 Like

simply reading all this I can tell you: fail2ban is a good basis.

  • Change SSH port
  • disable root login via ssh
  • disable root login or better: use a strong passphrase in case you really need to change stuff
  • only allow public key auth for your user, disable password ssh auth !
  • use a very strong key (for your client as well as server key!)
  • if possible add sshfp record to DNS (and have a valid DNSSEC)

if you're using sudo: keep logs, add replay, add notifications! either have a private irc chat with a bot reporting or mail stuff.
Maybe even lock out user if sudo passphrase is entered incorrectly 3 times (you would still have the root user)
disable certain programs/paths for sudoers

for additional layer of security: only open a openvpn port, run a server

  • openvpn server as: user nobody;group nobody;
    so no privilege escalation might worry you
  • only allow ssh from vpn connections or intranet

well.. just some thoughts to the topic.
PS.: yes, your openvpn will run without problems on your HW.

2 Likes

thats alot more info than i was expecting guys thanks alot! =) ill be leaning how to set all of this up over the next few days.

(i will have to sett up the root user first i believe, me only having a privileged user one the machine, is due to how Ubuntu server installs by default) (why is that default on a server distro if thats so unsecured?)

It isn't.

You would have configured a root password when you installed ubuntu, you can't not have a root user. The default user that you created when you installed will have sudo access, but if you wanted you can create users who do not have sudo access, or only have limited sudo access.

You should disabled root login on ssh so that an attacker cannot brute force the root login. What @Th3Z0ne is saying is that having a privileged user log in via public keys and then use sudo to gain root access is more secure than allowing root login via public key as an attacker can brute force the key offline, which you can't detect. Whereas if they gain access as the privileged user they will have to brute force the sudo password which you should be able to detect.

At any rate you should disable root login, enable and configure public key authentication and (when it's working) disable password logins. You should also set up fail2ban in case someone does get your private key and is able to log in, but that is a pretty unlikely situation, especially for a home system.

@ruberbandman109 Actually he was talking about su, not sudo - sudo is insecure.

su = set user
sudo = superuser do

"su root" forces the user to authenticate as root using the root password
"sudo <everything I want>" forces the user to authenticate using his user password

If the user account was compromised, sudo allows the attacker to do everything.
Therefore the standard user should neither be part of the "sudoers" group nor have an entry in "/etc/sudoers".

im confused

when i set up ubuntu it only asked me for 1 user "brandon" and 1 password "123456" now when i reboot the machine i log in with this same user name and password but i also have to use this same password when using the sudo command this is how ubuntu has the set up process by default, this is a standard user with sudo access to my knowledge thus i have no root password yet.

but @Dexter_Kane said i had to have sett up the root password in the sett up, this would mean that i have a standard user named brandon with no password and root with the 123456 password (and this makes no sense to me)

Require key authentication AND password and only listen on some unusual port

Pastebin
(Can someone Please explain my why I'm getting Error 403 when I try to place above in a Code tag and Post it?)

My server is local so I'm running a script when I'm out of house that allows access from work or other typical network I connect from, can be Starbucks, library, mobile network whatever:

~/sh/settingRemote.sh
sudo iptables -I INPUT 3 -s 111.222.0.0/16 -i eth1 -p tcp --dport 54651 -j ACCEPT
sudo iptables -I INPUT 3 -s 333.444.0.0/16 -i eth1 -p tcp --dport 54651 -j ACCEPT

And one that forbids it again when I return:

~/sh/settingLocal.sh
sudo iptables -D INPUT -s 111.222.0.0/16 -i eth1 -p tcp --dport 54651 -j ACCEPT
sudo iptables -D INPUT -s 333.444.0.0/16 -i eth1 -p tcp --dport 54651 -j ACCEPT

after which I check SSH login attempt logs:

 journalctl -u sshd |tail -100

I tryed around with port knocking but didn't get it working for me.

Nope:
su = switch user
Source

First of all: That's completely pointless. Secondly: It's Linux, not Unix. Therefore it is "substitute user" if you want to start a wording contest: http://www.man7.org/linux/man-pages/man1/su.1.html

1 Like

That is the default for ubuntu - it is a convenience feature; Root itself on ubuntu is disabled so you can not login with root+password.
To reactivate root go for:
sudo -i (to get root)
passwd (to create a password for root)

after that you can login as root+password

than edit the sudoers file with "visudo" and remove your default user form it.

1 Like

In addition to:

You cannot set the root password during the installation process. You only define your user password and Ubuntu automatically generates a root password - ensuring that root always has a password even if you don't set one during the installation.

Edit:

That was a misconception based on wrong information provided by another forum. For clarification see: https://forum.teksyndicate.com/t/need-help-to-secure-my-ssh/102321/26