|
|
vshelld_config
Section: File Formats (5) Updated: Version 3.8
NAME
vshelld_config - VanDyke Software Secure Shell server daemon
SYNOPSIS
vshelld_config
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 {
Logon { AllowUsers{ * }
DenyUsers{ root } #Deny logon access to
user "root"
DenyGroups{ wheel } #Deny members of
group "wheel" logon access even if
allowed somewhere else
}
}
Type: nested lists
Values: AllowGroups, AllowUsers, DenyGroups, DenyUsers
Default: Allow all users access to Logon, Shell, SFTP, and PortForwarding,
and deny all users access to RemotePortForwarding
- AuthenticationBannerPath
-
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:
AuthenticationsAllowed { publickey, password, gssapi-with-mic }
Type: comma-separated list
Values: publickey, password, gssapi-with-mic, gssapi-keyex, keyboard-interactive
Default: empty
- AuthenticationsRequired
-
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:
AuthenticationsRequired { publickey, password }
All items in the AuthenticationsRequired list must also appear in AuthenticationsAllowed.
Type: comma-separated list
Values: publickey, password, gssapi-with-mic, gssapi-keyex, keyboard-interactive
Default: empty
- AuthenticationTimeout
-
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, Mac OS X, 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, Mac OS X, Ubuntu, or 64-bit versions of Red Hat Enterprise Linux.
Type: integer
Values:
Value Definition
0 Process certificate path as specified
by X.509 v1 (ignores certificate
extensions)
1 Process certificate path as specified
by RFC 2459
2 Process certificate path as specified
by RFC 3280
Default: 2
- CertificateTrustedRootsDirectory
-
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, Mac OS X, 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, Mac OS X, 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:
Name String
AES-128 aes128-cbc
AES-192 aes192-cbc
AES-256 aes256-cbc
Twofish twofish-cbc
Blowfish blowfish-cbc
3DES 3des-cbc
RC4 arcfour
None none
Default: aes128-cbc, aes192-cbc, aes256-cbc, twofish-cbc, blowfish-cbc, 3des-cbc, arcfour
- CompressionLevel
-
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>...} ...}
Valid values for name-value pairs:
name = <type>
Type Value
host <host>
IP <IP address>
netmask <netmask>
domain <domain>
name = comment, value = <text>
name = access, value = allow or deny
Default: netmask 0.0.0.0/0.0.0.0, access allow, comment "allow everyone access"
Examples:
ConnectionFilterTableV2 {
{domain *.evil.org, access deny, comment "deny
connections from evil.org"}
{netmask 0.0.0.0/0.0.0.0, access allow, comment
"allow everyone else access"}
}
A more restrictive example of connection filters is as follows:
ConnectionFilterTableV2 {
{host remotehost.isp.com, access allow, comment
"remote users access"}
{domain *.vandyke.com, access allow, comment
"allows connections from vandyke.com"}
{domain *.trusted.com, access allow, comment
"allows connections from trusted.com"}
}
- CRLCheckingEnabled
-
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, Mac OS X, 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>
Valid values for replacement parameter:
Parameter Replacement Value
$B bytes read or written
$C error code: 0 indicates
success, any other number is
an operating system error
code
$D date
$E end of file: 0 indicates the
end of file has not been
reached, 1 indicates it has
$I IP address
$P path to filename
$R protocol of connection
$T time
$U user
Default: empty
- EnableUmaskDiscovery
-
Starts a non-interactive shell to determine the default UMASK for SFTP connections.
Type: Boolean
Values: true or false
Default: true
- EnableKeyRe-ExchangeCompatibility
-
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 SSL connections. The use of SSL 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.
FTPSExplicitListenAddressesV2
{{ Address 0.0.0.0:21,
CertificatePath /path/to/certificate,
RequiredEncryptionLevel 2 }}
- FTPSIdentVersion
-
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 SSL connections. The vshell-ftpsd server will immediately and unconditionally negotiate SSL for connections to the implicit address. As such, a path to the SSL 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.
FTPSImplicitListenAddressesV2
{{ Address 0.0.0.0:990,
CertificatePath /path/to/certificate,
RequiredEncryptionLevel 2 }}
- FTPSPidFilename
-
Specifies the filename for the vshell-ftpsd.pid file.
- FTPSUseAlternatePASVAddress
-
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:
ListenAddresses { 192.168.0.2, 10.0.0.2 }
Type: comma-separated string
Values: IP addresses
Default: 0.0.0.0
- LogFolder
-
Specifies a directory where
vshelld
will store log files.
Type: string
Values: Location of log file folder
Default: empty
- LoginCommand
-
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:
time(hh:mm:ss),group,connection number: message
15:13:19,auth,00001: Password for user administrator accepted.
15:46:26,auth,00003: Publickey for user administrator rejected because it is unsupported.
Type: Boolean
Values: true or false
Default: true
- LogTopicConnection
-
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:
time(hh:mm:ss),group,connection number: message
15:13:12,conn,00001: Connection accepted from 192.168.0.203:1180.
15:15:07,conn,00002: Connection closed.
Type: Boolean
Values: true or false
Default: true
- LogTopicDebug
-
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)
16:53:14,debug,03421: Scraper for a shell session has started (137)
Type: Boolean
Values: true or false
Default: false
- LogTopicError
-
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:
time(hh:mm:ss),group,message
17:05:11,err,Failed to lookup authentication package
AUTHENTICATION_PACKAGE_V1_0: A specified authentication package is unknown.
Type: Boolean
Values: true or false
Default: true
- LogTopicForward
-
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:
time(hh:mm:ss),group,connection number: message
16:56:12,fwd ,00004: Starting port forward to 192.168.0.203:111.
16:53:14,fwd ,00002: Port forward to 192.168.0.203:111 rejected by filter.
Type: Boolean
Values: true or false
Default: true
- LogTopicInfo
-
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:
time(hh:mm:ss),group,message
15:02:16,info,The VShell service is running.
15:03:57,info,VShell configuration has been changed.
15:16:37,info,The VShell service has stopped.
Type: Boolean
Values: true or false
Default: true
- LogTopicSFTP
-
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:
time(hh:mm:ss),group,connection number: message
09:57:58,sftp,00001: Sftp subsystem initialized; remote version is 3.
09:57:58,sftp,00001: Sending VERSION packet to remote (3)
09:58:03,sftp,00001: Sftp subsystem terminated.
Type: Boolean
Values: true or false
Default: true
- LogTopicWarning
-
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 connect to a port and fail 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
- PidFilename
-
Filename for your vshelld.pid file.
Type: string
Values: location of the pid file
Default if not present: {{VSHELLD_PID_PATH}}
- Port
-
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>...} ...}
Valid values for name-value pairs:
name = <type>
Type Value
host <host>
IP <IP address>
netmask <netmask>
domain <domain>
name = comment, value = <text>
name = access, value = allow or deny
name = port, value = <port> or 0 (any port)
Default: netmask 0.0.0.0/0.0.0.0, access allow, port 0, comment "allow all hosts/ports"
Example:
PortForwardFilterTableV2 {
{domain *.isp.com, port 0, access allow, comment
"allow port forwarding to any port in the
isp.com domain}
{host www.trusted.com, port 80, access allow,
comment "only allow port forwarding toport 80
on www.trusted.com"}
}
- PublicKeyFolder
-
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:
0700
or
user:rwx, group:none, other:none
Type: string
Values: Directory location of public key
Default: /$HOME/.vshell/publickey
- PublickeyPathPermissionChecking
-
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
- RestrictSFTPtoHome
-
Restricts SFTP access to users' home directories.
Type: Boolean
Values: true or false
Default: false
- RevealVersionInfo
-
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".
SFTPVirtualDirectories {
Alias "home" {
Directory "$HOME"
AllowUsers { alice }
AllowGroups { ops, faculty }
DenyUsers { root }
DenyGroups { wheel }
}
Alias "bin" {
Directory "/usr/bin"
AllowUsers { * }
}
Alias "xxx" {
Directory "/home/common"
AllowUsers { alice }
}
}
The following is a common type of usage that combines some users that are allowed to see unrestricted virtual directories and some users who are not. Users that are allowed to see unrestricted virtual directories will see the whole file system. The restricted users will only see their permitted virtual directories. The "root" user sees the whole file system, whereas "alice" sees only "/alice" and "/bin".
SFTPVirtualDirectories {
Unrestricted {
AllowUsers { root }
}
Alias "$USER" {
Directory "$HOME"
AllowUsers { alice }
AllowGroups { ops, faculty }
DenyUsers { root }
DenyGroups { wheel }
}
Alias "bin" {
Directory "/usr/bin"
AllowUsers { * }
}
}
When the access control list part of a virtual directory is empty, no one is allowed to use the virtual directory. For instance, in the following example, no one is allowed to see "/bin".
SFTPVirtualDirectories {
Unrestricted {
AllowUsers { root }
}
Alias "$USER" {
Directory "$HOME"
AllowUsers { alice }
AllowGroups { ops, faculty }
DenyUsers { root }
DenyGroups { wheel }
}
Alias "bin" {
Directory "/usr/bin"
}
}
Type: nested lists
Values: AllowGroups, AllowUsers, DenyGroups, DenyUsers
Default: Allow all users access to all directories
- SubconfigurationNetworkMap
-
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:
SubconfigurationUserMap {
{
Path "path1"
Users{user1,user2,...userN}
Groups{group1,group2,...groupN}
}
...
{
Path "pathN"
Users{user1,user2,...userN}
Groups{group1,group2,...groupN}
}
}
Type: nested lists
Values: path, user, group
Default: none
- SubSystemList
-
Configures an external subsystem (e.g., file transfer daemon). Arguments should be a subsystem name and a command to execute upon subsystem request. The command sftp-server implements the "sftp" file transfer subsystem.
Example:
SubSystemList {
backups=/bin/tar c /home
}
Type: comma-separated strings
Values: {<name>=<command>, <name>=<command>...}
{<name>=<command>, <name>=<command>...}
Default: none
- SyslogFacility
-
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:
syslogserver.domainname.com:514
Type: string
Values: syslog server address
Default: empty
- SyslogSetting
-
Specifies the socket type that the syslog server is using. Traditionally, syslog servers use a UDP socket. Syslog-ng (new generation) servers use a TCP socket.
Type: string
Values: udp, tcp
Default: udp
- UploadCommand
-
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>
Valid values for replacement parameter:
Parameter Replacement Value
$B bytes read or written
$C error code: 0 indicates
success, any other number is
an operating system error
code
$D date
$I IP address
$P path to filename
$R protocol of connection
$T time
$U user
Default: empty
- UseW3CLogging
-
Specifies whether
vshelld
uses W3C format for log files.
Type: Boolean
Values: true or false
Default: true
- X11AllowForwarding
-
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:
X11ListenAddresses { 192.168.0.2, 10.0.0.2 }
Type: comma-separated string
Values: IP addresses
Default: 0.0.0.0
- XAuthLocation
-
Specifies the full pathname of the
xauth
program.
Type: string
Values: location of the
xauth
program
Default: {{XAUTH_PATH}}
TIME FIELDS
The time field format is one or more <integer><unit code> pairs.
Unit of Time Unit Code
Seconds s
Minutes m
Days d
Hours h
Weeks w
Examples: 600s, 30m, 1w, 1m30s, 2d6h30m.
SAMPLE CONFIGURATION FILE
PublicKeyFolder $HOME/.vshell/publickey
Port 22
LogTopicError true
LogTopicWarning true
LogTopicInfo true
LogTopicConnection true
LogTopicAuthentication true
LogTopicSFTP true
LogTopicForward true
LogTopicDebug true
KeyExchangeMethods { diffie-hellman-group1-sha1 }
Ciphers { aes128-cbc,
aes192-cbc,
aes256-cbc,
twofish-cbc,
blowfish-cbc }
MACs { hmac-md5,
hmac-sha1,
hmac-sha1-96,
hmac-md5-96 }
Compressions { none,zlib }
CompressionLevel 5
ConnectionFilterTableV2 {
{ netmask 0.0.0.0/0.0.0.0, access allow, comment "allow
everyone access" }
}
PortForwardFilterTableV2 {
{ netmask 0.0.0.0/0.0.0.0, access allow, port 0, comment
"allow all hosts/ports" }
}
SEE ALSO
vcp(1),
vkeygen(1),
vpka(1),
vsftp(1),
vsh(1),
vshelld(8)
COPYRIGHT
Copyright (C) 1995 -
VanDyke Software, Inc.
VanDyke Software and VShell are trademarks of VanDyke Software, Inc. All other products and services mentioned are trademarks or registered trademarks of their respective companies.
Index
- NAME
- SYNOPSIS
- DESCRIPTION
- OPTIONS
- TIME FIELDS
- SAMPLE CONFIGURATION FILE
- SEE ALSO
-
- COPYRIGHT
|