man pages

vshelld_config

NAME

SYNOPSIS

DESCRIPTION

vshelld_config
is the configuration file that contains the settings for the
vshelld
(VShell(R) for UNIX) server.
vshelld
uses the SSH2(TM) protocol.

OPTIONS

Configuration options are described below.

AccessControl

Provides ability to allow or deny specific users or groups access to the following server functions:
Logon
Shell
SFTP
SCP
Ftps
PortForwarding
RemotePortForwarding
RemoteExecution
Access controls are defined in a nested list. An explicit denial of an option will take precedence over an explicit allowance. In other words, if a user (or group) or any group to which that user belongs, is denied access to a function, the user will be denied access even if they are explicitly allowed the permission as a member of another group. An empty list is considered an implicit denial of access.
Note: Users must have Logon access (either as a user or in a group) to use any of the other server functions (even if they are specifically granted access to those functions). This allows administrators to easily deny all access to any user without having to removed that user from every group.
There are two special forms for the AccessControl option:
Logon { } means all users are denied logon - the
same is true for the other four access types
Logon { AllowUser{*} } means allow all users
logon. The same is true for DenyUsers. Using
an * in an allow or deny group is an error.
Example:
AccessControl {

Logon {

AllowUsers{ * }

DenyUsers{ root } #Deny logon to user "root"

DenyGroups{ wheel } #Deny logon to members of

group "wheel" even if allowed elsewhere

}

Shell {

AllowUsers{ alice } #Allow shell to user "alice"

AllowGroups{ staff } #Allow shell access to the

group "staff"

DenyUsers{ root } #Deny shell to user "root"

}

SFTP {

AllowUsers{ bob } #Allow SFTP to user "bob"

AllowGroups{ ops, faculty } #Allow SFTP access

to members of "ops" and "faculty"

DenyUsers{ root } #Deny SFTP to user "root"

DenyGroups{ wheel } #Deny SFTP access to

members of group "wheel" even if allowed

elsewhere

}

SCP {

AllowUsers{ alice, bob } #Allow SCP access to

users "alice" and "bob"

DenyGroups{ staff } #Deny SCP access to members

of group staff

}

FTPS {

AllowGroups{ staff } #Allow FTPS access to

members of group staff

DenyUsers{ root } #Deny FTPS access to

user "root"

}

PortForwarding {

AllowUsers{ alice, bob } #Allow port forwarding

access to users "alice" and "bob"

DenyUsers{ root } #Deny port forwarding to

"root"

}

RemotePortForwarding { } #Deny all users remote

port forwarding

}

RemoteExecution { } #Deny all users ability to

remotely execute programs such as alternate

command shells
}
Variables can also be formatted as in the following example:
AccessControl {

Specifies the path of the authentication banner file. If you have defined an authentication banner file,
vshelld
will display the contents of this file before allowing a client to log on.
Type: string
Values: location of the authentication banner file
Default: empty

AuthenticationsAllowed

Lists the authentication methods that the server allows the client to use during authentication. If this setting is not defined the following methods are allowed: publickey, password, gssapi-with-mic, and gssapi-keyex. An empty list disallows all authentication methods. To allow keyboard-interactive or other methods, they must be listed explicitly.
Note: To use Kerberos v5 authentication via GSSAPI, you must manually create a soft link from your libgssapi-krbs.so to libgssapi.so. libgssapi.so must also be in the dynamic linker library path. In Red Hat Linux, this may require modification of ld.so.conf or setting the LD_LIBRARY_PATH environment. Other platforms may require other configuration changes.
Note2: The keyboard-interactive method is implemented using Pluggable Authentication Modules (PAM). Keyboard-interactive cannot be chosen as a valid authentication method on systems that do not natively support PAM. If keyboard-interactive is selected as an allowed authentication method, additional PAM configuration may be necessary.
Example usage:

Lists the authentication methods that must succeed in order for the client to log on. An empty list means that any supported authentication method can be used to connect to the server.
Note: To use Kerberos v5 authentication via GSSAPI, you must manually create a soft link from your libgssapi-krbs.so to libgssapi.so. libgssapi.so must also be in the dynamic linker library path. In Red Hat Linux, this may require modification of ld.so.conf or setting the LD_LIBRARY_PATH environment. Other platforms may require other configuration changes.
Example usage:

Specifies the number of seconds that
vshelld
will wait for authentication to take place before disconnecting. If this value is 0, there is no timeout.
Type: time
Values: 0, 30s-10m
Default: 600s

AutoCreateUserVirtualRootPath

Automatically creates the directory for a virtual root if $USER is in the root's path. The permissions for the connecting user will be applied to the newly created direcory. The connecting user must have permissions to create directories in the existing "base" directory (the directory before the $USER portion of the path).
Type: Boolean
Values: true or false
Default: false

AutoGenerateHostKey

Generates a new host key. Host keys are required by
vshelld to make secure connections. You can also generate host keys using the vkeygen command-line utility. If a valid host key is not present at startup under UNIX and this option is true, a host key is generated.
Type: Boolean
Values: true or false
Default: true

CertificateIntermediatesDirectory

Specifies a directory that contains intermediate certificates. When
vshelld
starts or is restarted, it checks to ensure that each intermediate certificate in this directory chains to a trusted root. If it does not,
vshelld
will log a message. When started or restarted,
vshelld
also checks to ensure that each certificate in this directory is within its validity period. If any of them are not,
vshelld
will log a message.
Note: Client authentication using X.509 certificates is not supported on VShell for FreeBSD, macOS, Ubuntu, or 64-bit versions of Red Hat Enterprise Linux.
Certificates must be in PEM-encoded format. The specified directory must not be writable by any user other than root (or the user as which vshelld is running).
Type: string
Values: location of directory
Default: empty (not using intermediate certificate(s))

CertificatePathPKIXLevel

Specifies the PKIX level used when attempting to validate a certificate chain. When started or restarted,
vshelld
reviews the status of this level. If the level is 1 or 2,
vshelld
checks to ensure that all root (CertificateTrustedRootsDirectory) and intermediate (CertificateIntermediatesDirectory) certificates have CA:TRUE BasicConstraints. If they do not,
vshelld
will log a message.
Note: Client authentication using X.509 certificates is not supported on VShell for FreeBSD, macOS, Ubuntu, or 64-bit versions of Red Hat Enterprise Linux.
Type: integer
Values:

Specifies a directory that contains trusted root certificates. X.509 client authentication will succeed only if the certificate presented for authentication chains to one of the certificates located in the specified directory. When
vshelld
starts or is restarted, it checks to ensure that each certificate (in this directory and in the directory specified in CertificateIntermediatesDirectory) is within its validity period. If any of them are not,
vshelld
will log a message.
Note: Client authentication using X.509 certificates is not supported on VShell for FreeBSD, macOS, Ubuntu, or 64-bit versions of Red Hat Enterprise Linux.
Certificates must be in PEM-encoded format. The specified directory must not be writable by any user other than root (or the user as which vshelld is running).
Type: string
Values: location of directory
Default: empty (disallow X.509 public-key certificate authentication)

CertificateUsernameMapFilename

Specifies a file that maps certificate thumbprints to usernames. The format of the file is as follows:
Username test1 thumbprint "df42 9492 d373
28f1 e6ab 4adf 989b 5875 ecc1 b189"
In the above format, the word "Username" is followed by a space, followed by a username, followed by the word "thumbprint", followed by the SHA-1 thumbprint of the certificate.
The thumbprint should only contain 0-9 and a-f (hexadecimal digits), optional spaces, or colon characters. If there are spaces, the thumbprint should be quoted, as in the example above.
Blank lines, lines beginning with a pound sign (#), and lines beginning with a semicolon (;) will be ignored.
If
vshelld
encounters a line that is not formatted correctly, it will log a message, skip the erroneous line, and continue reading the rest of the file.
The specified file must not be writable by any user other than root (or the user as which vshelld is running).
When certificate authentication is requested,
vshelld
checks to ensure that the name specified as the CertificateUsernameMapFilename is actually a file. If entry is not a file,
vshelld
will log a message.
Note: Client authentication using X.509 certificates is not supported on VShell for FreeBSD, macOS, Ubuntu, or 64-bit versions of Red Hat Enterprise Linux.
Type: string
Values: filename
Default: empty (not using certificate to username map file)

ChrootGroups

Restricts the members of the listed groups to their home directories when connecting with shell access, remote command execution, SFTP, or subsystem execution.
Note: Users that are included in a "ChrootGroups" list will, by default, be restricted to their home directory with SFTP; however, if "SFTPVirtualDirectories" are defined for that user, the user will be able to access those directories with SFTP.
When members of the listed groups connect, they are placed in a "chroot jail" with their home directory appearing to them as their root ("/") folder and with no other parts of the file system accessible to them. Any files that the user must access, including their shell and any executables they can run, must be available to them in their home directory.
Note: All shared libraries must also be moved to the user's home directory or have hard links created to them.
Type: comma-separated list
Values: group names
Default: empty

ChrootUsers

Restricts listed users to their home directories when connecting with shell access, remote command execution, SFTP, or subsystem execution.
Note: Users that are included in a "ChrootUsers" list will, by default, be restricted to their home directory with SFTP; however, if "SFTPVirtualDirectories" are defined for that user, the user will be able to access those directories with SFTP.
When listed users connect, they are placed in a "chroot jail" with their home directory appearing to them as their root ("/") folder and with no other parts of the file system accessible to them. Any files that the user must access, including their shell and any executables they can run, must be available to them in their home directory. The ChrootUsers list may contain the wildcard entry "*" which will cause all users connecting to vshelld to be "chrooted" to their home directories.
Note: All shared libraries must also be moved to the user's home directory or have hard links created to them.
Type: comma-separated list
Values: usernames, *
Default: empty

Ciphers

Allows
vshelld
to accept connections from clients using the specified cipher or ciphers. By encrypting the data using the cipher algorithm specified for the session,
vshelld
can provide secure communication over a nonsecure channel. The cipher selected must also be supported by the client. WARNING: If None is specified for the cipher and the client is also using None as its cipher, data for that client session (including passwords) will not be encrypted.
Type: set of comma-separated strings
Values:

Sets the server compression level for the data being sent from
vshelld
to the client if you have enabled compression (the client controls the compression level of data being sent to
vshelld
). A higher compression level means better compression but slower performance.
Note: Compression levels above 5 provide only a nominal increase in compression with much diminished performance levels.
Type: integer
Values: 1-9
Default: 5

Compressions

Allows clients to use Zlib compression or no compression when transferring data to and from the
vshelld
server.
Type: set of comma-separated strings
Values: none, zlib
Default: none, zlib

ConnectionFilterTableV2

With
vshelld
, you can configure filters that allow or deny connections from specific hosts. Connection filters are defined in a nested list and applied from the first to last. When a request to connect arrives at the server, it is checked against the filter list. The server compares the request with the first filter entry and then goes through the list to the last filter entry. When a request meets the criteria of a filter entry, that filter is applied and the rest of the list is ignored. An empty list will deny all host connection requests.
Filters may be applied to: IP addresses (e.g., 192.168.0.3); IP addresses with a Netmask (e.g., 192.168.0.0 as the Network and 255.255.255.0 as the Netmask); domains (e.g., *.vandyke.com); and hosts (e.g., mail).
If the filter list includes any domain or host entries,
vshelld
must perform a reverse DNS lookup. If this lookup fails, the connection is denied. WARNING: Host and domain entries rely on DNS lookup and should be used with care. DNS is an unsecure service and could be used as part of an attack on your system.
Type: nested lists
Values: { {<name> <value>, <name> <value>...}
{<name> <value>, <name> <value>...} ...}

Specifies whether to check client certificates against certificate revocation lists (CRLs). The CRLs should be located in the same directory as the trusted root certificates. When this option is enabled, a CRL must exist for each certificate in the chain. If this flag is set,
vshelld
checks to ensure that a CRL is loaded for each root (CertificateTrustedRootsDirectory) and intermediate certificate (CertificateIntermediatesDirectory). If it is not,
vshelld
will log a message.
Note: Client authentication using X.509 certificates is not supported on VShell for FreeBSD, macOS, Ubuntu, or 64-bit versions of Red Hat Enterprise Linux.
CRLs must be in PEM-encoded format.
Type: Boolean
Values: true or false
Default: true

DefaultUmask

Allows the user to specify the default global UMASK used for connections.
Type: integer
Values: octal value between 0 and 0777
Default: 0777

DisallowBlankPasswords

Requires that the user authenticate with a password, public key, or both. If this option is included, users will not be able to authenticate using blank passwords.
Note: PAM (used by
vshelld
to authenticate passwords) will not authenticate a blank password. However, if the user's password is blank, PAM will authenticate using any password (e.g., a space).
Type: Boolean
Values: true or false
Default: true

DownloadCommand

Defines the command to be run (triggered) after a file has been downloaded. The replacement values can appear anywhere in a command string.
Note: Quotation marks should not be used around the entire command (e.g., "executable param1"). Quotes can be used around the individual parts of the command (e.g., "executable" "param1"). The command also needs to be on one line.
Type: string
Values: executable <param1> <paramN>

Enables key re-exchange for clients that do not yet support key re-exchange.
Type: Boolean
Values: true or false
Default: true

EncodeAuthDataAsUTF8

Determines whether the user's password is decoded as UTF-8 or as an ANSI string. When this option is set to true, the password is decoded as UTF-8. SSH2 draft-compliant clients should always send passwords encoded as UTF-8, however, many SSH2 clients do not do this. In order to allow interoperate with such clients, it may be necessary to disable this option, especially if international characters are present in passwords.
Note: If this option is set to false, it may also be necessary to set the "RevealVersionInfo" option to false if you connect to VShell using VanDyke Software clients such as SecureCRT and SecureFX. Concealing vshelld's default version string in this way will cause these clients to also avoid encoding passwords as UTF-8.
Type: Boolean
Values: true or false
Default: true

EnvironmentVariableFilter

Specifies the environment variables that can be set via the "env" option on a channel request in the SSH2 protocol.
The SSH protocol supports the ability to have a client specify arbitrary environment variable (name and value) that should be set during a login session. However, in order to avoid unnecessary security exposure,
vshelld
limits the environment variables that it allows to be specified to those explicitly allowed by the system administrator.
The default variable list contains the VDS_*, allowing any variable beginning with VDS_ to be defined by the client through the SSH protocol. VShell supports the * (match any number of characters) and ? (match one character) wildcards.
Note: Environment variable names are case sensitive.
Example:
The following example string allows any variable beginning with VDS_, the PATH variable, and any two character environment variable beginning with X.
EnvironmentVariableFilter { VDS_*, PATH, X? }
Type: comma-separated list
Values: environment variable, *, ?
Default: VDS_*

FailedAuthCommand

Defines the command to be run (triggered) when MaximumAuthenticationRetries is exceeded. The replacement values can appear anywhere in a command string.
Note: Quotation marks should not be used around the entire command (e.g., "executable param1"). Quotes can be used around the individual parts of the command (e.g., "executable" "param1"). The command also needs to be on one line.
Type: string
Values: executable <param1> <paramN>

Valid values for replacement parameter:

Parameter Replacement Value

$D date

$I IP address

$T time

$U user

Note: Usernames that contain a $p will have

the pathname substituted in the trigger

command. For example, if the username is

"smith$pete", the file uploaded is

"xyzzy.txt", and the trigger command is

"echo $u", the command expected to be

executed is:

echo smith$pete

but will actually be:

echo smithxyzzy.txtete
Default: empty

FileDeleteCommand

Defines the command to be run (triggered) when a file is deleted. The replacement values can appear anywhere in a command string.
Note: Quotation marks should not be used around the entire command (e.g., "executable param1"). Quotes can be used around the individual parts of the command (e.g., "executable" "param1"). The command also needs to be on one line.
Type: string
Values: executable <param1> <paramN>

Valid values for replacement parameter:

Parameter Replacement Value

$C error code: 0 indicates

success, any other number is
an operating system error
code

$D date

$I IP address

$P path (complete pathname)

$R protocol of connection

$T time

$U user

Note: Usernames that contain a $p will have

the pathname substituted in the trigger

command. For example, if the username is

"smith$pete", the file uploaded is

"xyzzy.txt", and the trigger command is

"echo $u", the command expected to be

executed is:

echo smith$pete

but will actually be:

echo smithxyzzy.txtete
Default: empty

FileRenameCommand

Defines the command to be run (triggered) when a file is renamed. The replacement values can appear anywhere in a command string.
Note: Quotation marks should not be used around the entire command (e.g., "executable param1"). Quotes can be used around the individual parts of the command (e.g., "executable" "param1"). The command also needs to be on one line.
Type: string
Values: executable <param1> <paramN>

Valid values for replacement parameter:

Parameter Replacement Value

$C error code: 0 indicates

success, any other number is
an operating system error
code

$D date

$I IP address

$O old path (complete pathname)

$P path (complete pathname)

$R protocol of connection

$T time

$U user

Note: Usernames that contain a $p will have

the pathname substituted in the trigger

command. For example, if the username is

"smith$pete", the file uploaded is

"xyzzy.txt", and the trigger command is

"echo $u", the command expected to be

executed is:

echo smith$pete

but will actually be:

echo smithxyzzy.txtete
Default: empty

FireFileTriggersOnError

Specifies whether or not to run triggers if an error is received during file transfer. When set to 1, this option allows all specified upload and download triggers to run even if an error code is received. When set to 0, this option will not allow triggers to run if an error code is received unless the error code is for a successful (0) upload, successful (0) download, or end of file reached (-1).
Type: boolean
Values: 1, 0
Default: 1

FolderCreateCommand

Defines the command to be run (triggered) when a folder is created. The replacement values can appear anywhere in a command string.
Note: Quotation marks should not be used around the entire command (e.g., "executable param1"). Quotes can be used around the individual parts of the command (e.g., "executable" "param1"). The command also needs to be on one line.
Type: string
Values: executable <param1> <paramN>

Valid values for replacement parameter:

Parameter Replacement Value

$C error code: 0 indicates

success, any other number is
an operating system error
code

$D date

$I IP address

$P path (complete pathname)

$R protocol of connection

$T time

$U user

Note: Usernames that contain a $p will have

the pathname substituted in the trigger

command. For example, if the username is

"smith$pete", the file uploaded is

"xyzzy.txt", and the trigger command is

"echo $u", the command expected to be

executed is:

echo smith$pete

but will actually be:

echo smithxyzzy.txtete
Default: empty

FolderDeleteCommand

Defines the command to be run (triggered) when a folder is deleted. The replacement values can appear anywhere in a command string.
Note: Quotation marks should not be used around the entire command (e.g., "executable param1"). Quotes can be used around the individual parts of the command (e.g., "executable" "param1"). The command also needs to be on one line.
Type: string
Values: executable <param1> <paramN>

Valid values for replacement parameter:

Parameter Replacement Value

$C error code: 0 indicates

success, any other number is
an operating system error
code

$D date

$I IP address

$P path (complete pathname)

$R protocol of connection

$T time

$U user

Note: Usernames that contain a $p will have

the pathname substituted in the trigger

command. For example, if the username is

"smith$pete", the file uploaded is

"xyzzy.txt", and the trigger command is

"echo $u", the command expected to be

executed is:

echo smith$pete

but will actually be:

echo smithxyzzy.txtete
Default: empty

FolderRenameCommand

Defines the command to be run (triggered) when a folder is renamed. The replacement values can appear anywhere in a command string.
Note: Quotation marks should not be used around the entire command (e.g., "executable param1"). Quotes can be used around the individual parts of the command (e.g., "executable" "param1"). The command also needs to be on one line.
Type: string
Values: executable <param1> <paramN>

Valid values for replacement parameter:

Parameter Replacement Value

$C error code: 0 indicates

success, any other number is
an operating system error
code

$D date

$I IP address

$O old path (complete pathname)

$P path (complete pathname)

$R protocol of connection

$T time

$U user

Note: Usernames that contain a $p will have

the pathname substituted in the trigger

command. For example, if the username is

"smith$pete", the file uploaded is

"xyzzy.txt", and the trigger command is

"echo $u", the command expected to be

executed is:

echo smith$pete

but will actually be:

echo smithxyzzy.txtete
Default: empty

FTPSEnablePassivePortRange

Enables and specifies the range of ports that vshell-ftpsd will use for PASV data connections. If this option is set to true, the two arguments shown in the following example are required.

FTPSEnablePassivePortRange false

FTPSPassivePortRangeMinimum

FTPSPassivePortRangeMaximum

FTPSExplicitListenAddressesV2

Specifies a list of IP addresses on which vshell-ftpsd will listen for explicit TLS connections. The use of TLS on explicit addresses is based on a response from the client. The CertificatePath option is not required for explicit listen addresses that will only provide non-secure FTP access.
RequiredEncryptionLevel values:

0 : Do not require encryption - This is not a valid value for
implicit listen addresses.

1 : Require encrypted authentication - The command and data
channels can be unencrypted after authentication.

2 : Require encrypted connections - The command and data
channels must be encrypted for the life of the connection.

Specifies an alternate server identification string sent to clients connecting to vshell-ftpsd.

FTPSImplicitListenAddressesV2

Specifies a list of IP addresses on which vshell-ftpsd will listen for implicit TLS connections. The vshell-ftpsd server will immediately and unconditionally negotiate TLS for connections to the implicit address. As such, a path to the TLS validation certificate must be specified for the CertificatePath option for each implicit address.
RequiredEncryptionLevel values:

0 : Do not require encryption - This is not a valid value for
implicit listen addresses.

1 : Require encrypted authentication - The command and data
channels can be unencrypted after authentication.

2 : Require encrypted connections - The command and data
channels must be encrypted for the life of the connection.

Enable and specify an alternate IP address that vshell-ftpsd will use for PASV data connections. If this option is set to true, the argument shown in the following example is required.

FTPSUseAlternatePASVAddress false

FTPSAlternatePASVAddress

HostKeyFilenames

Specifies the filenames for your host key files.
vshelld
supports the use of multiple host keys, but only one host key of each supported algorithm can be used at one time. The supported host key algorithms are ssh-dss, ssh-rsa, X.509v3-sign-dss, and X.509v3-sign-rsa.
Type: comma-separated list
Values: locations of the host key files
Default if not present:
{{VSHELLD_HOSTKEY_PATH}}

IdleTimeout

Specifies the time that a session can remain idle before being disconnected by the
vshelld
server. If this value is 0, there is no idle timeout.
Type: time
Values: 0, 1m-30d
Default: 0

KeepAlive

Enables TCP/IP feature that allows the underlying system software to quickly detect when the other party becomes unreachable. Without keep alives, it may not be possible, or would take a long time to detect that a client connection has dropped. However, keep alives do consume a small amount of bandwidth. They can also cause "false" detection of a dropped connection if the route to a host is temporarily lost.
Type: Boolean
Values: true or false
Default: true

KeyExchangeMethods

Specifies algorithms used for key exchange. At least one algorithm must be specified.
Note: To configure
vshelld
to allow the use of GSSAPI-authenticated Diffie-Hellman key exchange algorithms, the name of one or more GSSAPI-authenticated key exchange algorithms must be included in the KeyExchangeMethods list. The SSH2 protocol defines the names of these algorithms to include a hash of the underlying GSSAPI mechanism's identifier (OID). The mechanisms that are available on the machine where
vshelld
runs will vary depending on the GSSAPI implementation and its configuration. A typical list of GSSAPI-authenticated key exchange methods that are available on a machine with MIT Kerberos installed will look like the following:
gss-group1-sha1-toWM5Slw5Ew8Mqkay+al2g==
gss-group1-sha1-A/vxljAEU54gt9a48EiANQ==
gss-group1-sha1-Yd6WXxLtAfKB2gCNGH7aqQ==
The Kerberos v5 GSSAPI mechanism is "gss-group1-sha1-toWM5Slw5Ew8Mqkay+al2g==". This algorithm may also be enabled by including the common name "Kerberos" in this list.
Type: set of comma-separated strings
Values: diffie-hellman-group1-sha1, diffie-hellman-group-exchange-sha1, Kerberos, gssapi-sha1-<implementation OID>
Default: diffie-hellman-group1-sha1, diffie-hellman-group-exchange-sha1

KeyRe-ExchangeMB

The amount of data passed before key re-exchange occurs. Keys are re-exchanged when either the KeyRe-ExchangeMB limit or KeyRe-ExchangeTimeout limit is reached, which ever is reached first.
Type: integer
Values: range not implemented
Default: 1024 (per draft)
Description: A key re-exchange is made after the specified amount of data has been sent.

KeyRe-ExchangeTimeout

The amount of time between key exchange operations. Keys are re-exchanged when either the KeyRe-ExchangeMB limit or KeyRe-ExchangeTimeout limit is reached, which ever is reached first.
Type: time (see the Time Fields section)
Values: 10m-1w
Default: 30m

ListenAddresses

Specifies a list of IP addresses on which VShell listens. On multi-homed machines, this provides control over which NIC VShell listens to, proving better lock down access to the server.
Example usage:

Defines the command to be run (triggered) on a successful login. The replacement values can appear anywhere in a command string.
Note: Quotation marks should not be used around the entire command (e.g., "executable param1"). Quotes can be used around the individual parts of the command (e.g., "executable" "param1"). The command also needs to be on one line.
Type: string
Values: executable <param1> <paramN>

Valid values for replacement parameter:

Parameter Replacement Value

$D date

$I IP address

$T time

$U user

Note: Usernames that contain a $p will have

the pathname substituted in the trigger

command. For example, if the username is

"smith$pete", the file uploaded is

"xyzzy.txt", and the trigger command is

"echo $u", the command expected to be

executed is:

echo smith$pete

but will actually be:

echo smithxyzzy.txtete
Default: empty

LogoutCommand

Defines the command to be run (triggered) on logout/disconnect after a successful login. The replacement values can appear anywhere in a command string.
Note: Quotation marks should not be used around the entire command (e.g., "executable param1"). Quotes can be used around the individual parts of the command (e.g., "executable" "param1"). The command also needs to be on one line.
Type: string
Values: executable <param1> <paramN>

Valid values for replacement parameter:

Parameter Replacement Value

$D date

$I IP address

$T time

$U user

Note: Usernames that contain a $p will have

the pathname substituted in the trigger

command. For example, if the username is

"smith$pete", the file uploaded is

"xyzzy.txt", and the trigger command is

"echo $u", the command expected to be

executed is:

echo smith$pete

but will actually be:

echo smithxyzzy.txtete
Default: empty

LogTopicAuthentication

Log authentication messages to the
vshelld
log file. Unless explicitly configured in /etc/syslog.conf to use another file,
vshelld
will record messages for this option to the /var/log/messages file on Linux systems or to the /var/adm/messages file on Solaris systems.
Example authentication messages:

Log connection messages to the
vshelld
log file. Unless explicitly configured in /etc/syslog.conf to use another file,
vshelld
will record messages for this option to the /var/log/messages file on Linux systems or to the /var/adm/messages file on Solaris systems.
Example connection messages:

Log debugging messages to the
vshelld
log file. Unless explicitly configured in /etc/syslog.conf to use another file,
vshelld
will record messages for this option to the /var/log/messages file on Linux systems or to the /var/adm/messages file on Solaris systems.
Example debugging message:

time(hh:mm:ss),group,connection number: message (debug messages can be very long)

Log error messages to the
vshelld
log file. Error messages are always logged in the system event log file. Unless explicitly configured in /etc/syslog.conf to use another file,
vshelld
will record messages for this option to the /var/log/messages file on Linux systems or to the /var/adm/messages file on Solaris systems.
Example error message:

Log forwarding messages to the
vshelld
log file. Unless explicitly configured in /etc/syslog.conf to use another file,
vshelld
will record messages for this option to the /var/log/messages file on Linux systems or to the /var/adm/messages file on Solaris systems.
Example forwarding messages:

Log informational messages to the
vshelld
log file. Informational messages are always logged in the system event log file. Unless explicitly configured in /etc/syslog.conf to use another file,
vshelld
will record messages for this option to the /var/log/messages file on Linux systems or to the /var/adm/messages file on Solaris systems.
Example informational messages:

Log SFTP messages to the
vshelld
log file. Unless explicitly configured in /etc/syslog.conf to use another file,
vshelld
will record messages for this option to the /var/log/messages file on Linux systems or to the /var/adm/messages file on Solaris systems.
Example SFTP messages:

Log warning messages to the
vshelld
log file. Warning messages are always logged in the system event log file. Unless explicitly configured in /etc/syslog.conf to use another file,
vshelld
will record messages for this option to the /var/log/messages file on Linux systems or to the /var/adm/messages file on Solaris systems.
Type: Boolean
Values: true or false
Default: true

MACs

Allows
vshelld
to accept connections from clients using the specified MAC or MACs. A MAC (Message Authentication Code) provides
vshelld
increased security which ensures data integrity.
vshelld
requires that at least one MAC be selected in the MAC list. WARNING: If None is specified for the MAC and the client is also using None as its MAC, client sessions will be susceptible to packet insertion attacks.
Type: set of comma-separated strings
Values:

Name String

MD5 hmac-md5

SHA1 hmac-sha1

SHA1-96 hmac-sha1-96

MD5-96 hmac-md6-96

None none

Default: hmac-md5, hmac-sha1, hmac-sha1-96, hmac-md6-96

MaximumAuthenticationRetries

Specifies the number of times that a client can attempt to send valid credentials before
vshelld
disconnects the client. If this value is 0, there is no limit.
Type: integer
Values: 0-20
Default: 5

MOTDPath

Specifies the location of the message of the day file. If a client connects with no PTY, the message will not be displayed. If ~/.hushlogin exists it also will not be displayed.
In the Solaris operating environment, the logon shell by default displays the message of the day. Therefore, if you also include the MOTDPath option in your vshelld_config file,
vshelld
misinterprets this as a second instruction to display the message of the day. To suppress the second message, comment out or remove the MOTDPath/etc/motd setting in the vshelld_config file.
Type: string
Values: location of the motd file
Default: empty

Port to which you want the server to listen.
Type: integer
Values: 1-65535
Default: 22

PortForwardFilterTableV2

With
vshelld
, you can configure filters that allow or deny port forwarding requests. Port-forwarding filters are defined in a nested list and applied from the first to last. When a request to port forward arrives at the server, it is checked against the filter list. The server compares the request with the first filter entry and then goes through the list to the last filter entry. When a request meets the criteria of a filter entry, that filter is applied and the rest of the list is ignored. An empty list will deny all port-forwarding requests.
Filters may be applied to: IP addresses (e.g., 192.168.0.3); IP addresses with a Netmask (e.g., 192.168.0.0 as the Network and 255.255.255.0 as the Netmask); domains (e.g., *.vandyke.com); and hosts (e.g., mail).
If the client port-forwarding request is specified as a host,
vshelld
attempts a DNS lookup before performing any checks. If the lookup fails,
vshelld
will deny the port-forward connection. If the filter list includes any domain or host entries, and the client port-forwarding request is specified as an IP address,
vshelld
must perform a reverse DNS lookup. If this lookup fails, the request is denied. WARNING: Host and domain entries rely on DNS lookup and should be used with care. DNS is an unsecure service and could be used as part of an attack on your system.
Type: nested lists
Values: { {<name> <value>, <name> <value>...}
{<name> <value>, <name> <value>...} ...}

The folder in which you want to store your public key file. This option must contain the variable $HOME or $USER such as the default value:
$HOME/.vshell/publickey
Another example would be the following:
usr/local/etc/vshell/$USER/publickey
When you create or change the public key folder, the following permissions are recommended for the new folder:

Specifies how strict
vshelld
should be in checking permissions on a user's public key folder during authentication. It is recommended that the pathto the user's public key folder not be world writable.

Type: string
Values:

VeryStrict - Check permissions on full path up
to root

Strict - Check permission on path up to user's
home directory

None- No permissions are checked

Default: Strict

ResolveHostnamesForUtmp

Resolves IP addresses for users gaining shell access to VShell. If set to true, the log file entry in utmp and wtmp will contain the client's hostname instead of the IP address.
Type: Boolean
Values: true or false
Default: false

By default,
vshelld
identities itself to clients by adding product and version information to the protocol version string sent when a connection is made. When set to false, this option sends "SSH-2.0-0.0" as the version string.
Type: Boolean
Values: true or false
Default: true

SendDisconnectErrorsToClient

By default,
vshelld
does not return license error messages to the client. When a client tries to connect to
vshelld
using a license that is expired or invalid or if the number of licensed onnections has been exceeded, the connection is simply dropped. This is designed to help the server work faster and can be useful if your server comes under denial-of-service attack. If you want VShell to send an SSH disconnect error message to clients under these circumstances, you will need to set this option to true.
Type: Boolean
Values: true or false
Default: false

SFTPVirtualDirectories

Establishes a list of directories and controls access to each directory by allowing or denying access to specific users or groups. Virtual directories are defined by a nested list of Alias statements.
The supported permission clauses are as follows:
AllowUsers
AllowGroups
DenyUsers
DenyGroups
An explicit denial of access will take precedence over an explicit allowance. In other words, if a user or group is denied access to a directory, the user or group member will be denied access even if they are explicitly allowed access as a member of another group. An empty list is considered an implicit denial of access to all users.
"Directory" clauses are required and must be the first clause in all Alias statements, except for the Unrestricted statement. Directory clauses are forbidden in the Unrestricted statement.
Users and groups that are allowed unrestricted access will see the actual directory structure and not the alias virtual directories.
Vshelld
supports the RestrictSFTPtoHome option, but if it is used at the same time as SFTPVirtualDirectories, a parse error will occur.
Alias and directory names may be constants or variables and may contain spaces. The alias name may not contain / : * ? " < > or |. Neither alias nor directory names may contain { } or newline characters. Quotation marks around the alias and directory names are required. Directory names must resolve to a real directory that the user has permission to access.
Vshelld
supports $HOME and $USER substitution for directory names, but only $USER for alias names.
Symbolic links may point from one SFTP virtual directory to another, or point within a virtual directory. If symbol links point outside of the permitted virtual directories, access is denied.
When a directory does not resolve to a user accessible directory or there is a duplicate alias name, a message is logged to the
vshelld
log. An example of a duplicate alias is shown in the last example below where there is a user named "bin" as well as a hard root named "bin". You may need to ask your admin for details about access to virtual directories that you cannot see.
Note: If a user's operating system home directory (e.g., /etc/passwd) is a subdirectory of one of the SFTPVirtualDirectories, the user will be automatically placed in their home directory.
Examples:
When commented out, the SFTPVirtualDirectories feature is turned off.
# SFTPVirtualDirectories {
# }
When there is an empty list, all users will be allowed access to all directories.
SFTPVirtualDirectories {
}
In the example below, permission to see the whole directory structure is given to user "root" and group "wheel", and to no one else. This is similar to using access control lists to let "root" and "wheel" see the whole directory tree.

SFTPVirtualDirectories {
Unrestricted {
AllowUsers { root }
AllowGroups { wheel }
}
}
In the following example, users may see their own home directories (which will always be called "home") and two other directories. Note that the "xxx" alias is visible to everyone. The user "alice" will see three directories: "/home", "/bin", and "/xxx". The user "root" will see two directories: "/bin" and "/xxx".

Subconfigurations can be used to override server settings for connections from a specific location. Supported server settings specified in a subconfiguration will replace the default settings given in the vshelld configuration file.
When a connection is made,
vshelld
reviews its SubconfigurationNetworkMap list to see if the connected location appears on the list. The server compares the location with the first network entry and then goes down the list to the last entry. If the location matches a network entry, that subconfiguration is applied and takes precedence over the
vshelld
default configuration; the rest of the SubconfigurationNetworkMap list is ignored. An empty list will mean that the
vshelld
default configuration will be used.
Note: When a subconfiguration is applied, only settings specified in the subconfiguration are overridden. Settings that are not specifically changed retain their default value. A SubconfigurationNetworkMap only allows the following settings to be overridden:
- AuthenticationsAllowed
- AuthenticationsRequired
- PortForwardFilterTableV2
After connecting, when a user authenticates,
vshelld
could also check that user against its SubconfigurationUserMap list. User and group subconfiguration settings will override network subconfiguration settings as well as
vshelld
default configuration settings.
Example:
SubconfigurationNetworkMap {
{<name> <value>,<subconfig path>}
...
{<name> <value>,<subconfig path N>}
}
Type: nested lists
Values: { {<name> <value>, <subconfig path>...}
{<name> <value>, <subconfig path>...} ...}

Valid values for name-value pairs:

name = <type>

Type Value

IP <IP address>

netmask <netmask>

Default: none

SubconfigurationUserMap

Subconfigurations can be used to override server settings for connections from a specific user or group. Supported server settings specified in a subconfiguration will replace the current settings given in a network subconfiguration or in the
vshelld
configuration file.
When a user authenticates,
vshelld
reviews its SubconfigurationUserMap list to see if that user appears on the list. The server compares the user with the first entry and then goes down the list to the last entry. If the user or group matches an entry, that subconfiguration is applied and takes precedence over any network subconfiguration as well as over the
vshelld
default configuration; the rest of the SubconfigurationUserMap list is ignored. An empty list will mean that any applied network subconfiguration or the
vshelld
default configuration will be used.
Note: When a subconfiguration is applied, only settings specified in the subconfiguration are overridden. Settings that are not specifically changed retain their current value. A SubconfigurationUserMap only allows the following settings to be overridden:
- AuthenticationsRequired
- PortForwardFilterTableV2
Example:

Specifies the facility that is used by
vshelld
when logging messages to syslogd(8). The allowed values for this entry are:
LOG_DAEMON
LOG_LOCAL0
LOG_LOCAL1
LOG_LOCAL2
LOG_LOCAL3
LOG_LOCAL4
LOG_LOCAL5
LOG_LOCAL6
LOG_LOCAL7
Default: LOG_DAEMON

SyslogServer

Specifies the hostname or IP address and an optional port number for the syslog server.
Example:

Defines the command to be run (triggered) after a file has been uploaded. The replacement values can appear anywhere in a command string.
Note: Quotation marks should not be used around the entire command (e.g., "executable param1"). Quotes can be used around the individual parts of the command (e.g., "executable" "param1"). The command also needs to be on one line.
Type: string
Values: executable <param1> <paramN>

Specifies whether X11 forwarding is allowed. When X11 forwarding is enabled, there may be additional exposure to the server and to client displays if the
vshelld
proxy display is configured to listen on the wildcard address (see X11UseLocalhost below); however, this is not the default. Additionally, the authentication spoofing and authentication data verification and substitution occur on the client side. The security risk of using X11 forwarding is that the client's X11 display server may be exposed to attack when the Secure Shell client requests forwarding.
A system administrator may have a stance in which they want to protect clients that may expose themselves to attack by unwittingly requesting X11 forwarding, which can warrant a "false" setting.
Type: Boolean
Values: true or false
Default: false

X11DisplayOffset

Specifies the first display number available for
vshelld
X11 forwarding. This prevents
vshelld
from interfering with real X11 servers.
Type: integer
Values: range not implemented
Default: 10

X11ListenAddresses

Specifies a list of IP addresses on which VShell listens for X11 client connections. This allows X11 forwarding to use multiple addresses and also allows IPv6 in addition to IPv4.
Example usage: