Your browser does not allow storing cookies. We recommend enabling them.

SSH Tectia 
PreviousNextUp[Contents] [Index]

    About This Document >>
    Installing SSH Tectia Server (M) >>
    Using SSH Tectia Server (M) >>
    Troubleshooting SSH Tectia Server (M) >>
    Configuration >>
        Configuration Files >>
        Subconfigurations >>
        Ciphers and MACs
        Configuring Root Logins
        Restricting User Logins
        Auditing >>
        Securing SSH Tectia Client and Server >>
            Server Configuration
            Client Configuration
    Authentication >>
    Application Tunneling >>
    Sample Files >>
    Man Pages
    Log Messages >>

Server Configuration

Disabling Tunneling

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).

Disabling Terminal Access

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 X11 forwarding and agent forwarding if Terminal Access is denied in sshd2_config.

AllowX11Forwarding       no
AllowAgentForwarding     no

Note that the users will be able to use SFTP and other subsystems defined in the SSH Tectia Server configuration. Any other "exec" and "shell" requests will be denied for the users. This includes forced commands with public keys described in Section Forced Commands and the legacy style password changing when performed as forced command.

Disabling Root Login

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 Section Forced Commands 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. Put the following to your sshd2_config:

PermitRootLogin     nopwd

This way, jobs automated with forced commands will work. If you use PAM authentication, you may need to modify that configuration as well to disable root access via sshd2.

Forced Commands (with Public Keys)

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.

options command="tar zxvf - /usr/local"

This would, on a successful login with, force a backup job to start.

You can also use the command that was given on the ssh2 command line:

options command="echo $SSH2_ORIGINAL_COMMAND"

Running ssh2:

% ssh2 localhost kukkuu
Authentication successful.

See the man page for ssh2 for a detailed description of public-key options.

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.

PreviousNextUp[Contents] [Index]

[ Contact Information | Support | Feedback | SSH Home Page | SSH Products ]

Copyright © 2005 SSH Communications Security Corp.
This software is protected by international copyright laws. All rights reserved.
Copyright Notice




What to read next:

  • Reduce Secure Shell risk. Get to know the NIST 7966.

    The NISTIR 7966 guideline from the Computer Security Division of NIST is a direct call to action for organizations regardless of industry and is a mandate for the US Federal government.
    Download now
  • ISACA Practitioner Guide for SSH

    With contributions from practitioners, specialists and SSH.COM experts, the ISACA “SSH: Practitioner Considerations” guide is vital best practice from the compliance and audit community.
    Download now