Secure system administration is the traditional use case for Secure Shell.
Usually, allowing direct root logins from the network is a bad idea.
It is better to use forced commands to automate tasks requiring privileges
(described in Forced Commands (with Public Keys) below), and make people use
su
or sudo
to elevate privileges
otherwise.
In addition to AllowUsers
and
DenyUsers
, you can easily disable root logins with
passwords (Configuring Root Logins ). Put the following to
your sshd2_config
:
PermitRootLogin nopwd
This way, jobs automated with forced commands will work.
If you are sure you or your users do not need to create tunnels
(possibly going around firewall restrictions or such), you can disable
tunneling (port forwarding) altogether by adding the following to your
sshd2_config
:
AllowTcpForwarding no
If you need more fine-grained control, consider using
AllowTcpForwardingForUsers
(and related keywords
DenyTcpForwardingForUsers
,
AllowTcpForwardingForGroups
and
DenyTcpForwardingForGroups
). With
ForwardACL
you can even allow and deny tunnels based on
originator and destination (based on the IP address and port). See
Restrictions to Tunneling.
If you only want to enable file transfers or tunneling for users in
group users
, you can disable terminal access by adding the
following to your sshd2_config
:
Terminal.DenyGroups users
Other related keywords that can be used are:
Terminal.AllowUsers
, Terminal.DenyUsers
and Terminal.AllowGroups
.
It is recommended to deny also agent forwarding if Terminal Access is
denied in sshd2_config
.
AllowAgentForwarding no
Note that the users will be able to use SFTP and other subsystems defined in the Tectia Server configuration. Any other "exec" and "shell" requests will be denied for the users. This includes forced commands with public keys described in Forced Commands (with Public Keys) and the legacy style password changing when performed as forced command.
If you have maintenance jobs requiring non-interactive access to your server, use public-key authentication and forced commands. This way, if the private key is compromised, the public key cannot be used to perform anything other than the predetermined command on the server. (This is, of course, also bad, but it would be worse if the malicious attacker would have unrestricted access to the machine.)
Do not use the root account for jobs where it is not absolutely necessary.
You can set up a forced command in the
authorization
file.
key backup-key.pub options command="tar zxvf - /usr/local"
This would, on a successful login with
backup-key.pub
, force a backup job to start.
You can also use the command that was given on the
ssh2
command line:
key backup-key.pub options command="echo $SSH2_ORIGINAL_COMMAND"
Running ssh2
:
% ssh2 localhost kukkuu Authentication successful. kukkuu %
For more information on the public-key options in the authorization file, see Using the Authorization File.
Note that if
the user or the user's group has been denied terminal access (with the
Terminal.DenyUsers
or Terminal.DenyGroups
keywords), also forced commands will be denied.
Tectia Server can be configured to reject connection attempts from unknown
hosts. For example the following allows connections only from the internal
network 10.1.0.0/8
IP addresses and from an external host
with the IP address 195.20.116.1
:
AllowHosts \i10\.1\..*,\i195\.20\.116\.1
Please see Restricting User Logins for information on the regular expression syntax and for more configuration examples and options.
On systems with several network interfaces, Tectia Server can also be bound
to a specific network interface so that the server can be only accessed
from the intended network. For example, the following will bind the
listener to address 10.1.60.25
using port 2222:
ListenAddress 10.1.60.25 Port 2222
Tectia Server logs are most important for auditing. The logs also provide troubleshooting information, for example, when user authentication fails and a user is unable to log in. Please see Auditing for more information.
It is recommended to notify the users before they decide to log in that their actions are logged. In some jurisdictions this is required.
To display for example the following text to the users before login,
the banner message saved to name
/opt/tectia/etc/ssh_banner_message
can be used.
Unauthorized use of this system is prohibited. All actions are logged.