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
|
