Authentication and Access Control

In each of these examples, a perimeter firewall protects VShell®. Leaving the Secure Shell port open on the firewall effectively delegates control over tunneled applications to VShell. Doing so creates a single, integrated point of control over remote user authentication, resource access rights, and tunneled applications.

Before any tunneling can occur, the SecureCRT® user is authenticated by VShell, combining strong two-factor and public key methods with Windows NT or 2000 workgroups, computers, and user accounts. It also enforces authentication retry and timeout limits.

VShell filters can be created to allow or deny Secure Shell connections from individual IPs, hosts, subnets, or entire domains. Windows users and groups can be given access to local or remote port forwarding without granting command shell or SFTP privileges. Forwarded hosts and ports can be controlled at more granular levels by creating filters that allow or deny forwarding to IPs, hosts, subnets, domains. For example, forwarding can be allowed to/from *.corp.com, for any port or selected ports.

Port-forward mappings are actually defined by each Secure Shell client. When a Secure Shell connection is established, VShell accepts or rejects the requested port forwards, based on the authenticated user's privileges and port-forward filters. By default, SecureCRT allows port forwarding to and from the localhost, but these client-side Access Control Lists (ACLs) can also be customized.

To more fully appreciate how port forwarding is configured, where authentication and encryption occurs, and the threats addressed by these measures, let's take a closer look at some common applications that can be tunneled over Secure Shell.