Howdy, Stranger!

It looks like you're new here. If you want to get involved, click one of these buttons!


Best practices for sshd_config
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.

Best practices for sshd_config

How's your sshd_config look like? Does anyone use OpenSSH multiplexing for speed?

«1

Comments

  • OpenSSH is best practice by design.

  • permitrootlogin yes
    keyfiles no

    Thanked by 1FatGrizzly
  • 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

  • DPDP Administrator, The Domain Guy

    I only have multiplexing enabled for my jump server, but other than that, nothing out of the ordinary.

    • Non-standard Port
    • Listening on a specific IP address
    • No RootLogin
    • Key Only
    • No DNS

    Others are covered by firewall and/or hosts.allow/deny.

    Thanked by 1capric98
  • I tell it to listen to ipv6 only, that way you don't have to deal with 99% of the noise out there. :smile:

    Thanked by 2Durs capric98
  • GatewayPorts yes

    Sometimes I need this enabled.

  • Port xxxxx
    PermitRootLogin prohibit-password
    UsePAM no
    X11Forwarding no
    UseDNS no

  • @nvidian said:
    Port xxxxx
    PermitRootLogin prohibit-password
    UsePAM no
    X11Forwarding no
    UseDNS no

    Why no pam?

  • NeoonNeoon Community Contributor, Veteran

    @rcy026 said:
    I tell it to listen to ipv6 only, that way you don't have to deal with 99% of the noise out there. :smile:

    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

  • emgemg Veteran
    edited September 2022

    My steps:

    • Create a user account for admin purposes.
    • Use the "visudo" command to add the new admin account to the sudoers list. No other account gets "sudo" privileges.
    • Stop using the root account. Use the admin account with sudo.
    • Create an unprivileged "remote access" account. No files, no privileges, no nothin'.
      ** Exception: Add your SSH public key to .ssh/authorized_keys in that account
    • Choose a random port for SSH access. Admittedly, this is security by obscurity, but it also keeps the logs much smaller and lets you focus on more serious attempts.
    • Open the random port on your firewall.
    • Copy the original sshd_config file in case you mess up. It also comes in handy for running diff when someone asks an sshd_config question on LowEndTalk: sudo cp -p sshd_config sshd_config.orig
    • Edit/Add to sshd_config:
      • Port (your chosen random port)
      • PermitRootLogin no
      • PubkeyAuthentication yes
      • PasswordAuthentication no
      • AllowUsers (your remote access account)
    • Restart the sshd service.
    • Stay logged in to the current session, but open a new, separate session and verify that you can login using the remote access account on the new port with public key authentication. If something doesn't work, you can fix the problem using the original open session.
    • When everything works as expected, close port 22 on your firewall because you are using a different port.
    • From now on, connect using your public key and the remote access account. If you need privileges, "su" to your admin account and use "sudo" if you need root access. Or "su" to your regular unprivileged working account.

    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.

    Thanked by 3MrLime ElonBezos Liso
  • All these multiple steps for security is avoided if put ssh on wireguard. Simple.

    Thanked by 2adns PearlMoon
  • @LTniger said:
    How's your sshd_config look like? Does anyone use OpenSSH multiplexing for speed?

    @LTniger said:
    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?

  • @emg said:

    @LTniger said:
    How's your sshd_config look like? Does anyone use OpenSSH multiplexing for speed?

    @LTniger said:
    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.

    Thanked by 1emg
  • jackbjackb Member, Host Rep

    @emg said:
    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.

    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.

  • Tony40Tony40 Member
    edited September 2022

    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:

    Port (random)
    PermitRootLogin no
    PasswordAuthentication no
    AllowUsers (unprivileged user)
    

    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.

  • PermitRootLogin no
    PasswordAuthentication no
    and libpam-google-authenticator
    
  • @jackb said:

    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.

    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)

  • @darkimmortal said: HostKeyAlgorithms -ssh-rsa

    Why not ed25519?

    Thanked by 1jsg
  • 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.

  • @fynix said:

    @darkimmortal said: HostKeyAlgorithms -ssh-rsa

    Why not ed25519?

    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

  • @jackb said:

    @emg said:
    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.

    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.

    Interesting. How is this possible? What makes port 1-1023 special that same escalation can't be done?

  • @alilet said:

    @jackb said:

    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.

    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.

  • @alilet said:

    Interesting. How is this possible? What makes port 1-1023 special that same escalation can't be done?

    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.

    Thanked by 2alilet Mumbly
  • @LTniger said: 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.

    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

    Thanked by 1Levi
  • @nvidian said: UseDNS no

    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.

    Thanked by 2vyas11 gzz
  • jsgjsg Member, Resident Benchmarker

    @LTniger said:
    ... I have few dozen servers which conects to one central server periodically.

    SPOF

Sign In or Register to comment.