Child pages
  • ssh server configuration
Skip to end of metadata
Go to start of metadata

You are viewing an old version of this page. View the current version.

Compare with Current View Page History

« Previous Version 9 Next »

Standard Blue Light sshd configuration

/etc/ssh/sshd_config

(warning) The AllowUsers and Match Address changes made in this example may need adjusting for local requirements.

root@localhost:/etc/ssh# diff sshd_config{.org,}
27c27
< PermitRootLogin yes
---
> PermitRootLogin no
51a52
> PasswordAuthentication no
87c88,100
< UsePAM yes
---
> UsePAM no
>
> # Blue Light changes to improve performance
> UseDNS no
> GSSAPIAuthentication no
> Compression yes
>
> # Blue Light extras
> AllowUsers root
> Match Address 192.168.10.0/24
>       PermitRootLogin without-password
> Match Address 10.42.0.1
>       PermitRootLogin without-password

Explanation of some of the above recommended changes

"PasswordAuthentication no" disables login via password.

"UsePAM no" avoids messages like "PAM service(sshd) ignoring max retries; 6 > 3".

"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 IPs

"GSSAPIAuthentication no" not needed as we will be using private/public keys or passwords, not RADIUS, Kerberos, or any other http://en.wikipedia.org/wiki/Generic_Security_Services_Application_Program_Interface

"Compression yes" On fast machines this will enhance throughput.

"AllowUsers root"  TBC

"Match Address 192.168.10.0/24" matches the Blue Light LAN in the Town Hall.  Only required on ssh servers in the Town Hall.

"Match Address 10.42.0.1" matches the Blue Light OpenVPN network node "blav" and so requires that OpenVPN clients (appear to) come from blav.

/etc/default/ssh

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

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

Enable the new configuration by service ssh restart

authorized_keys

command=

Security can be tightened by specifying the command that an authorised key can run by inserting command=<command> before the key itself.  Details in the sshd man page, in the command="command" section.

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:

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

df_regex='^df '
rsync_server_regex='^rsync --server '
stat_regex='^stat --format=%F '

if [[ $SSH_ORIGINAL_COMMAND =~ $df_regex \
    || $SSH_ORIGINAL_COMMAND =~ $rsync_server_regex \
    || $SSH_ORIGINAL_COMMAND =~ $stat_regex \
]]; then
    exec $SSH_ORIGINAL_COMMAND
else
    echo "${0##*/}: command did not pass validation ($SSH_ORIGINAL_COMMAND)" >&2
    exit 1
fi

TODO: enhance the script to read the regexes from a config file.

  • No labels