Summary

BoKS has the ability to allow access to a user or system without password for a limited set of access methods. The level of security implied when using this feature is highly dependent on the access method in use and ranges from very poor to pretty good.

Description

The RSH (the Remote Shell and Remote Copy) by definition doesn't support passwords. This is sometimes referred to as hostbased authentication with the assumption that you are logged in to a trusted host. The use of RSH implies a very low security for two reasons: The communication is not encrypted and there is no authentication - only implicit trust.

All other access methods in BoKS require authentication by default. However some additional methods can be configured to allow access without a password. These are SU, SUEXEC, RLOGIN and WINRUNAS. Configuring these access methods in this way means that authentication is effectively disabled.

SSH supports a broad range of authentication methods including hostbased. With SSH protocol version 2, hostbased authentication makes use of the SSH host-key to authenticate the host.

RSH
Access without password is granted by simple Access Route assignment. I.e. when access is granted passwords are never used. It is possible to allow access from e.g. user Alice to Bob by using the user@ syntax in the from field of the access route definition.

RLOGIN
Access without a password is granted by using the user@ syntax in the from field of the Access Route definition. As with RSH it is possible to allow access from one account on the from-host to another account on the destination host. If the password authentication is disabled this way, the security level is the same as with RSH (i.e. very low).

Note: FoxT strongly recommends that any open Access Routes for RSH or RLOGIN are replaced by the corresponding SSH-methods for better security.

SU, SUEXEC and WINRUNAS
Access without a password can be granted by using the user@ syntax in the from field of the Access Route definition. E.g.

SU:bob@pty*->oracle@ORAHOSTS

If there is a need to grant access without a password for any of the above methods via a User Class, the $USER keyword can be used instead of an explicit user login name. This will allow access for the user owning the route to log in as him- or herself without a password.


Example:

SUEXEC:$USER@*->root@BOKSHOSTS%opt/boksm/sbin/lsbks

SSH
The SSH protocol version 2 supports several ways to access a system in a secure way without a password, all of which assume that the original host is a trusted system and thus that the key used for authentication has not been violated. These include authentication with an x.509 certificate, SSH public key, SSH v2 hostbased and Kerberos. (SSH v1 hostbased is not supported when BoKS protection is enabled).

Hostbased
With SSH v2 hostbased authentication it is possible to grant access without a password from one user on the from-host to another user on the destination host using the user@ syntax in the from-field of the Access Route.

Example:

SSH,SSH_SFTP:alice@ORAHOSTS->FILESRVHOSTS

Note: The user@ syntax is only supported for SSH when hostbased authentication is in use. For any other authentication method the identity of the from-user is unknown during the authentication process and ignored.

Public Key authentication and Agent Forwarding
With BoKS Manager, Agent Forwarding is enabled by default in the SSH client (ForwardAgent parameter in $BOKS_etc/ssh/ssh_config). Agent Forwarding allows a single public key pair to be re-used for subsequent authentications. E.g. you can log in to a stepping stone host using your public key and from there on log in to other hosts with the same key. The public key must be available on each host you wish to log in to but the corresponding private key is kept in one place in the SSH key-agent (e.g on your workstation). Further, if the public key is uploaded to the BoKS database, it will be automatically distributed to all BoKS hosts where your account is defined.

Note however that there are security issues associated with using the SSH Agent Forwarding feature. The following text is reproduced from an article at https://wiki.mozilla.org/Security/Guidelines/OpenSSH:

"SSH Agent forwarding exposes your authentication to the server you're connecting to. By default, an attacker with control of the server (i.e. root access) can communicate with your agent and use your key to authenticate to other servers without any notification (i.e. impersonate you).
For this reason, one must be careful when using SSH agent forwarding. Defaulting to always forwarding the agent is strongly discouraged.
Note also that while the attacker can use your key as long as the agent is running and forwarded, he cannot steal/download the key for offline/later use."

Requirements for Agent Forwarding

  • User has an SSH public key pair.
  • The user's private key is loaded into an SSH Key Agent on the originating host.
  • Agent forwarding is enabled in ssh_config on each intermediary host (default in BoKS).
  • Access Routes have been assigned to the user in BoKS to allow access.
  • The user has the ssh_pk authenticator assigned in BoKS.
  • BoKS is installed on Unix/Linux hosts and the user's public key has been uploaded to the BoKS database or the user's public key has been uploaded to ~/.ssh/authorized_keys on each BoKS host (intermediary- and target).

Note: Agent forwarding is also supported with x.509 certificates.

Kerberos
Kerberos authentication is supported by BoKS SSH. See further information in the BoKS Manager Administration Guide.

See also the following chapters / sections BoKS Manager Administration Guide:

  • User Authentication Basics for FoxT ServerControl
  • Managing Authenticators
  • SSH Access Route Notes
  • SSH Authentication Methods

Still have questions? We can help. Submit a case to Technical Support.

Last Modified On: March 21, 2019