Page History

...

Warning: if doing this remotely, when implementing configuration changes, keep the existing ssh session open and test by starting a new one.

If a parameter keyword value is set twice, it may be the first value in the file which is may be effective!  Found Experiment showed that was true for PermitRootLogin .  Found not to be true and UsePrivilegeSeparation but not for UsePAM.  More information in BLAVORG-590.A pro-forma file is available For simplicity we decided not to set any keywords twice (outside Match sections).

There are sshd_config files in the Blue Light git at in the conf/ssh /sshd_config.

Explanation of some of the recommended changes

"PasswordAuthentication no" disables login via password.

"UsePAM no" directory.

The parameters we change:

• AcceptEnv commented out.  This ensures no unexpected side effects from having especially non-standard locale variables.
• AllowUsers tightens security.  We set this to root and add others as the need arises.
  
• GSSAPIAuthentication no turns off several authentication methods which are not needed when using private/public keys or passwords.  Reference: http://en.wikipedia.org/wiki/Generic_Security_Services_Application_Program_Interface
• PasswordAuthentication no or without-password disables login via password.
• PermitRootLogin no or without-password disables login via password.  We always use without-password, sometimes globally and sometimes within Match Address conditional section(s).
• UsePrivilegeSeparation yes.  In LXCs only (otherwise we use the as-installed no).  Otherwise ssh does not work.
  
• UsePAM no avoids messages like "PAM service(sshd) ignoring max retries; 6 > 3".

...

•  
  The message is caused by PAM's compiled-in retry limit being less than sshd's.
• UseDNS no disables reverse DNS lookups to see if your hostname matches the IP

...

• address you are connecting from.  Does not make sense with dynamic

...

"GSSAPIAuthentication no" turns off several authentication methods which are not needed when using private/public keys or passwords.  Refrrence: http://en.wikipedia.org/wiki/Generic_Security_Services_Application_Program_Interface

"Compression yes"  enhances throughput, as long as the CPU is not slow or overloaded.

• IP addresses.

/etc/ssh/sshd_config generation

ssh package installation generates /etc/ssh/sshd_config (a change from the original package installation which copied the file) so the as-installed file may not be identical on all systems.

Editing policy

As far as practicable, for easy identification, Blue light changes are made outside the package-generated file's text block and the original text block is surrounded by:

# ==== THE ORIGINAL /etc/ssh/sshd_config, edited, STARTS HERE ====
...
# ==== THE ORIGINAL /etc/ssh/sshd_config, edited, ENDS HERE ====

Within that original block, the only changes should be to comment out keywords.  To aid identification they can be commented out with a #@ prefix.

After the original block ...

# Blue Light changes to as-installed settings (should be commented out above)
PermitRootLogin without-password     # Comment out if using the Match Address stanzas below
UsePAM no
UsePrivilegeSeparation no            # Required in an lxc container

# Blue Light additions to change as-installed settings not specified above (defaults)
AllowUsers root
PasswordAuthentication no

# Blue Light additions to improve performance
UseDNS no
GSSAPIAuthentication no

Match Address stanzas

We are still evolving how we use these.  TODO: does the order matter (does sshd stop processing these stanzas after the first match?)?  TODO: do these PermitRootLogin values override any global setting?

Some samples:

# Allow root login from the BLUE OpenVPN addresses
Match Address 10.42.23.0/24
    PermitRootLogin without-password

# Allow root login from the BL OpenVPN server
Match Address 10.42.0.1
    PermitRootLogin without-password

# Allow root login from blav2
Match Address 148.251.233.235
    PermitRootLogin without-password
Match Address 10.42.0.2
    PermitRootLogin without-password

/etc/default/ssh

root@localhost:~# diff /etc/default/ssh{.org,}
5c5
< SSHD_OPTS=
---
> SSHD_OPTS=-u0

...

Sometimes this is not convenient because several commands are to be run.  A solution is to specify a script in authorized_keys and for the script to validate the commands.  For example (old version of bung's validate_ssh_cmd.sh):

#!/bin/bash
# Purpose: validates the command a remote host is attempting to execute by ss

...