New on LowEndTalk? Please Register and read our Community Rules.
All new Registrations are manually reviewed and approved, so a short delay after registration may occur before your account becomes active.
All new Registrations are manually reviewed and approved, so a short delay after registration may occur before your account becomes active.
Comments
OpenSSH is best practice by design.
permitrootlogin yes
keyfiles no
I only change several things in my sshd_config file like the following and use only authorized SSH keys to log in.
PermitRootLogin no
PasswordAuthentication no
AllowUsers user1 user2
I only have multiplexing enabled for my jump server, but other than that, nothing out of the ordinary.
Others are covered by firewall and/or hosts.allow/deny.
I tell it to listen to ipv6 only, that way you don't have to deal with 99% of the noise out there.
GatewayPorts yes
Sometimes I need this enabled.
Port xxxxx
PermitRootLogin prohibit-password
UsePAM no
X11Forwarding no
UseDNS no
Why no pam?
Funny, enough attacks on IPv6 already.
Changing the port and making SSH listen on just IPv6 when the port is publicly accessible is just security through obscurity which I would never recommend. It's one of the first lessons that I learnt in IT. If information is somehow publicly accessible, it will find its way to the public eventually.
If someone really wants to target your system, they can easily port scan from a lot of different IP addresses without being blocked by any active firewall systems that you have in place. No matter how good your defences are, if it's publicly accessible then the port/IP can eventually be identified.
Obviously if you lock down the SSH port to be only accessible from certain networks, it helps to change the port but if someone infiltrates one of the whitelisted networks, it would've been harder to do that than to find out the SSH port of your server.
Following on from that, always lock down the SSH traffic to your server. Either have a static IP address for your connection and have it whitelisted or use a trusted VPN that requires 2FA to log into.
Never permit password logins and always use keys. Have no keys setup for the root user but have them setup for users that are part of the wheel group or another group that needs specific access. It would take quite the hacker to get your key and know your password to run commands that can cause issues on the server.
HostKeyAlgorithms -ssh-rsa
My steps:
** Exception: Add your SSH public key to .ssh/authorized_keys in that account
sudo cp -p sshd_config sshd_config.orig
Question for Others:
-> When choosing a random port for SSH, which port range do you choose from?
* Well-known ports (1-1023) ?
* Registered ports (1024-49151) ?
* Ephemeral ports (49152-65535) ?
The choice has security considerations.
All these multiple steps for security is avoided if put ssh on wireguard. Simple.
'scuse me for askin', but why did you start this thread?
Looking for examples regarding multiplexing. Security is well discussed topic. I have few dozen servers which conects to one central server periodically. Looking for advice maybe, how to speed up ssh connections. Googled about ssh connection re-use.
So, looking more about this. Sorry if was not clear.
In theory anything 1024 and over is open to local privilege escalation - where someone could crash the SSH daemon, and start a malicious process in its place.
An unlikely scenario but might as well use 1-1023.
What work for me.
Change Default SSH Port #
PermitRootLogin no
AllowUsers username@loginIP
I also setup a alert email script . I get a alert every time someone login via ssh with IP detail.
This is what I use:
Next, I only allow connections to ssh from one IP (jump server).
The jump server has the the same settings and only accept connections from specific IP/Ranges.
That is the scenario I had in mind when I asked the question.
-> I am still curious to know what others are doing regarding the same choice of SSH ports:
Well-known? (<1024),
Reserved? (1024 up to 49151)
Ephemeral? (>49151)
Why not ed25519?
Doesn't Mozilla still maintain a current recommended config?
There was also a really good one years ago but he stopped maintaining it and then became a liability and I can't even remember the short domain anymore (cipher related?). But it was by one of the guys who is often involved in open source and VPN/security shit. Probably a William, iirc.
Is disabling ssh-rsa host keys, which is soon to be the default but most server OS’s aren’t on a new enough openssh yet
Interesting. How is this possible? What makes port 1-1023 special that same escalation can't be done?
I believe he's saying you don't gain much security by using the higher ports which are the ones available to non-priv'ed users.
Superuser (root) privileges are required to bind to a well-known port from 1-1023, but special privileges are not required to bind to higher numbered ports.
An attacker could find a fatal bug in SSH and crash it, then try to substitute their own malicious process to listen on the same port. That malicious process could pretend to be SSH to collect usernames and passwords, for example.
If SSH is on a well-known port (1-1023), then the hacker's malicious process must have superuser privileges to listen on that same port. If you move SSH to a higher port, then superuser privileges are not required for the hacker's malicious process to listen on that port.
Multiplexing wont help with that. It's for combining multiple outgoing SSH sessions over a single connection.
SSH is the wrong tool to ping a central server. Have your servers talk to each other over IRC/Telegram. If you want to roll your own, there are distributed message queues like ZeroMQ, RabbitMQ
Out of curiosity, its there apart from potential short delay any negative implication with keeping "UseDNS yes"?
I find it useful in some specific cases where it's convenient to use "AllowUsers user@*.dynamic.hostname.net" instead of static IP/subnet.
Buy a private cage with key card access, lock down the server from the internet, fly over to the datacenter every time you need to access the server.
SPOF