SSH Bastion Host Best Practices
Good writup.  One thing I would add for bastions if you wanted to harden them would be to disable session multiplexing if you are using MFA&#x2F;2FA.<p><pre><code>  MaxSessions 1
</code></pre>
The default is 10.  The plus side of multiplexing is that subsequent connections using the same ssh connection <i>channels</i> are not validated against the authorization mechanisms such as <i>login</i> or <i>2FA</i>.  This reduces friction and speeds up the login process <i>because login is not actually occurring</i>.  The trade-off of multiplexing is that all subsequent logins using that ssh connection are not logged nor are they validated with MFA.  This means a person phishing your team members can easily hijack their connections without needing a password or 2FA and there are no <i>lastlog</i> entries.  SSH Session multiplexing combined with passwordless sudo makes taking over a company trivial even if they have 2FA and strong passwords.<p>Another risk with a bastion model is port forwarding.  As an organization you have to decide what is appropriate for that bastion.  Unrestricted forwarding? Restricted? Denied?<p><pre><code>  AllowAgentForwarding                    no
  AllowTcpForwarding                      yes
  PermitOpen                              192.168.1.2:22
</code></pre>
If this bastion is for a PCI environment then one may want tighter restrictions.  If it is for a development environment then maybe less restrictions and just better auditing on each host to enable forensic remediation.<p>If your bastion is also used for automation to drop files into a staging area, you can limit that automation to file transfers and even limit what it may do with files.  This prevents the automation from having a shell or performing port forwarding.<p>The keys should be outside of the home directories to prevent malicious tools from appending additional authorized_keys into the account.  Make use of automation to manage key trusts and add a comment to keys to map them to an internal tracking system like Jira.  This assumes your MFA&#x2F;2FA is excluding specific accounts or groups via PAM and permitting the use of ssh keys with specific groups or accounts.<p><pre><code>  AuthorizedKeysFile               &#x2F;etc&#x2F;ssh&#x2F;keys&#x2F;%u

  Match Group                      sftpusers
        Banner                     &#x2F;etc&#x2F;ssh&#x2F;banner_sftp.txt
        PubkeyAuthentication       yes
        PasswordAuthentication     no
        PermitEmptyPasswords       no
        GatewayPorts               no
        ChrootDirectory            &#x2F;data&#x2F;sftphome&#x2F;%u
        ForceCommand               internal-sftp -l DEBUG1 -f AUTHPRIV -P symlink,hardlink,fsync,rmdir,remove,rename,posix-rename
        AllowTcpForwarding         no
        AllowAgentForwarding       no
</code></pre>
-P sets limits on what may not be done in sftp.  -p does the inverse and limits what may be done. [1]  -l DEBUG1 or VERBOSE will give you syslog entries of what commands were executed on the files.  This is useful for audits.  Some redundant settings above are also useful to set explicitly for audits.<p>Another thing mentioned in the article is iptables.  In a PCI environment one may want to also have explicit outbound rules using the <i>owner</i> module to limit what users or groups are permitted to ssh out.  So if your organization have a group of people allowed to use this host as a bastions, then one could write a rule like<p><pre><code>  iptables -I OUTPUT -m owner --gid-owner devops -p tcp --dport 22 -d 192.168.0.0&#x2F;16 -j ACCEPT
</code></pre>
Or specify what CIDR blocks, ports, protocols may be used.  You can use REJECT rules after this rule to make it obvious a connection was not allowed so that people do not spend hours debugging.  This module is also handy for limiting which daemons may speak to your infrastructure.  How strict or liberal the rule is entirely at the needs of your organization.<p>Lastly I would add that bastions should have as minimal an OS install possible and have SELinux enforcing.  Actions denied by SELinux should go to a security operations center after you spend some time tuning out the noise and false positives.<p>[1] - <a href="https:&#x2F;&#x2F;man7.org&#x2F;linux&#x2F;man-pages&#x2F;man8&#x2F;sftp-server.8.html" rel="nofollow">https:&#x2F;&#x2F;man7.org&#x2F;linux&#x2F;man-pages&#x2F;man8&#x2F;sftp-server.8.html</a>