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

SSH Tectia 
PreviousNextUp[Contents] [Index]

    About This Document >>
    Installing SSH Tectia Server >>
    Getting Started >>
        Location of Installed Files >>
        Starting and Stopping the Server >>
        Operation of the Server >>
        SSH Tectia Server (T) >>
            Tunneling User
            Restricting Services
        SSH Tectia Server (A) >>
        SSH Tectia Client >>
        Examples of Use
    Configuration >>
    Authentication >>
    Application Tunneling >>
    Troubleshooting >>
    Man Pages
    Advanced Options >>
    Log Messages >>

Tunneling User

The SSH Tectia Connector users must be able to log in to an existing user account, preferably a non-privileged user account, on the server.

Users can have their own user accounts. If the Windows login name can be used also as the server-side login name, the variable %USERNAME% can be conveniently used in the configuration of SSH Tectia Connector.

Most of the authentication methods supported by SSH Tectia Server can be used with SSH Tectia Connector users. The authentication methods include password, any Keyboard-Interactive methods such as SecurID or RADIUS, public-key authentication with certificates on smart cards, and GSSAPI if the SSH Tectia Server and SSH Tectia Connector computers are part of the same Windows domain or the SSH Tectia Server can perform initial login to MIT Kerberos realm on behalf of the SSH Tectia Connector user .

User interaction is required for the Keyboard-Interactive authentication methods and typically at least the first time when the private key stored on a smart card is accessed in public-key authentication. Please see Section Authentication for details of the user authentication methods.

In case the tunneled applications provide sufficient user authentication, it is possible to use a shared user account, for example with a shared password, not requiring user interaction. Note that the shared account and password must only be used for tunneling, as the account is common to several users and the shared password is stored as plaintext in the SSH Tectia Connector configuration file.

See the operating system documentation for instructions on how to create a new user account, for example tunnel, with minimal privileges. It is very important that the shared user account is properly configured on the operating system level. The user should be denied at least shell access and the file system permissions should be restricted. This is done as precaution in case the user is able to access the system using some other means than Secure Shell.

To deny shell access on the operating-system level, you can set the user's shell to /bin/false or use a script that can also inform the user of the situation.

For example, you could have the following saved to name /bin/no-shell:

#!/bin/sh

echo "Shell access to this account has been disabled."
exit 1

PreviousNextUp[Contents] [Index]


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

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


 

 
Highlights from the SSH.COM blog:

  • Cryptomining with the SSH protocol: what big enterprises need to know about it

    Cryptomining malware is primarily thought of as targeting desktops and laptops and is used to hijack system resources to mine cryptocurrency.
    Read more
  • SLAM the door shut on traditional privileged access management

    Did you know that something as trivial-sounding as granting access for your developers or third parties to a product development environment can throw a gorilla-sized monkey wrench into your operations and productivity?
    Read more
  • We broke the IT security perimeter

    Everyone understands the concept of a security perimeter. You only gain access if you are identified and authorized to do so.
    Read more