-type callbacks_daemon_options() ::
    {failfun, fun((User :: string(), PeerAddress :: inet:ip_address(), Reason :: term()) -> _)} |
    {connectfun,
     fun((User :: string(), PeerAddress :: inet:ip_address(), Method :: string()) -> _)}.

• connectfun - Provides a fun to implement your own logging when a user authenticates to the server.

• failfun - Provides a fun to implement your own logging when a user fails to authenticate.

-type daemon_option() ::
    subsystem_daemon_option() |
    shell_daemon_option() |
    exec_daemon_option() |
    ssh_cli_daemon_option() |
    tcpip_tunnel_out_daemon_option() |
    tcpip_tunnel_in_daemon_option() |
    authentication_daemon_options() |
    diffie_hellman_group_exchange_daemon_option() |
    max_initial_idle_time_daemon_option() |
    negotiation_timeout_daemon_option() |
    hello_timeout_daemon_option() |
    hardening_daemon_options() |
    callbacks_daemon_options() |
    send_ext_info_daemon_option() |
    opaque_daemon_options() |
    gen_tcp:listen_option() |
    common_option().

Options for daemons. The individual options are further explained below or by following the hyperlinks.

Note that not every gen_tcp:listen_option/0 is accepted. See set_sock_opts/2 for a list of prohibited options.

Also note that setting a gen_tcp:listen_option/0 could change the socket in a way that impacts the ssh deamon's behaviour negatively. You use it on your own risk.

-type deprecated_exec_opt() :: fun() | mod_fun_args().

Old-style exec specification that are kept for compatibility, but should not be used in new programs

-type exec_result() :: {ok, Result :: term()} | {error, Reason :: term()}.

This option changes how the daemon executes exec-requests from clients. The term in the return value is formatted to a string if it is a non-string type. No trailing newline is added in the ok-case.

See the User's Guide section on One-Time Execution for examples.

Error texts are returned on channel-type 1 which usually is piped to stderr on e.g Linux systems. Texts from a successful execution are returned on channel-type 0 and will in similar manner be piped to stdout. The exit-status code is set to 0 for success and 255 for errors. The exact results presented on the client side depends on the client and the client's operating system.

In case of the {direct, exec_fun()} variant or no exec-option at all, all reads from standard_input will be from the received data-events of type 0. Those are sent by the client. Similarly all writes to standard_output will be sent as data-events to the client. An OS shell client like the command 'ssh' will usually use stdin and stdout for the user interface.

The option cooperates with the daemon-option shell in the following way:

• 1. If neither the exec-option nor the shell-option is present: - The default Erlang evaluator is used both for exec and shell requests. The result is returned to the client.

• 2. If the exec_spec's value is disabled (the shell-option may or may not be present): - No exec-requests are executed but shell-requests are not affected, they follow the shell_spec's value.

• 3. If the exec-option is present and the exec_spec value =/= disabled (the shell-option may or may not be present): - The exec_spec fun() is called with the same number of parameters as the arity of the fun, and the result is returned to the client. Shell-requests are not affected, they follow the shell_spec's value.

• 4. If the exec-option is absent, and the shell-option is present with the default Erlang shell as the shell_spec's value: - The default Erlang evaluator is used both for exec and shell requests. The result is returned to the client.

• 5. If the exec-option is absent, and the shell-option is present with a value that is neither the default Erlang shell nor the value disabled: - The exec-request is not evaluated and an error message is returned to the client. Shell-requests are executed according to the value of the shell_spec.

• 6. If the exec-option is absent, and the shell_spec's value is disabled: - Exec requests are executed by the default shell, but shell-requests are not executed.

If a custom CLI is installed (see the option ssh_cli) the rules above are replaced by thoose implied by the custom CLI.

Note

The exec-option has existed for a long time but has not previously been documented. The old definition and behaviour are retained but obey the rules 1-6 above if conflicting. The old and undocumented style should not be used in new programs.

-type hardening_daemon_options() ::
    {max_sessions, pos_integer()} |
    {max_channels, pos_integer()} |
    {parallel_login, boolean()} |
    {minimal_remote_max_packet_size, pos_integer()}.

For more information about hardening, see the Hardening section in the User's Guide chapter.

• max_sessions - The maximum number of simultaneous sessions that are accepted at any time for this daemon. This includes sessions that are being authorized. Thus, if set to N, and N clients have connected but not started the login process, connection attempt N+1 is aborted. If N connections are authenticated and still logged in, no more logins are accepted until one of the existing ones log out.

  The counter is per listening port. Thus, if two daemons are started, one with {max_sessions,N} and the other with {max_sessions,M}, in total N+M connections are accepted for the whole ssh application.

  Notice that if parallel_login is false, only one client at a time can be in the authentication phase.

  By default, this option is not set. This means that the number is not limited.

• max_channels - The maximum number of channels with active remote subsystem that are accepted for each connection to this daemon

  By default, this option is not set. This means that the number is not limited.

• parallel_login - If set to false (the default value), only one login is handled at a time. If set to true, an unlimited number of login attempts are allowed simultaneously.

  If the max_sessions option is set to N and parallel_login is set to true, the maximum number of simultaneous login attempts at any time is limited to N-K, where K is the number of authenticated connections present at this daemon.

  Warning

  Do not enable parallel_logins without protecting the server by other means, for example, by the max_sessions option or a firewall configuration. If set to true, there is no protection against DOS attacks.

• minimal_remote_max_packet_size - The least maximum packet size that the daemon will accept in channel open requests from the client. The default value is 0.

-type hello_timeout_daemon_option() :: {hello_timeout, timeout()}.

Maximum time in milliseconds for the first part of the ssh session setup, the hello message exchange. Defaults to 30000 ms (30 seconds). If the client fails to send the first message within this time, the connection is closed.

For more information about timeouts, see the Timeouts section in the User's Guide Hardening chapter.

-type max_initial_idle_time_daemon_option() :: {max_initial_idle_time, timeout()}.

Maximum time in milliseconds for the first channel start after completion of the authentication negotiation. Defaults to infinity.

For more information about timeouts, see the Timeouts section in the User's Guide Hardening chapter.

-type negotiation_timeout_daemon_option() :: {negotiation_timeout, timeout()}.

Maximum time in milliseconds for the authentication negotiation. Defaults to 120000 ms (2 minutes). If the client fails to log in within this time, the connection is closed.

For more information about timeouts, see the Timeouts section in the User's Guide Hardening chapter.

-type pwdfun_4() ::
    fun((User :: string(),
         Password :: string() | pubkey,
         PeerAddress :: ip_port(),
         State :: any()) ->
            boolean() | disconnect | {boolean(), NewState :: any()}).

• auth_method_kb_interactive_data - Sets the text strings that the daemon sends to the client for presentation to the user when using keyboard-interactive authentication.

  If the fun/3 or fun/4 is used, it is called when the actual authentication occurs and may therefore return dynamic data like time, remote ip etc.

  The parameter Echo guides the client about need to hide the password.

  The default value is: {auth_method_kb_interactive_data, {"SSH server", "Enter password for \""++User++"\"", "password: ", false}>

• user_passwords - Provides passwords for password authentication. The passwords are used when someone tries to connect to the server and public key user-authentication fails. The option provides a list of valid usernames and the corresponding passwords.

  Warning

  Note that this is very insecure due to the plain-text passwords; it is intended for test purposes. Use the pwdfun option to handle the password checking instead.

• pk_check_user - Enables checking of the client's user name in the server when doing public key authentication. It is disabled by default.

  The term "user" is used differently in OpenSSH and SSH in Erlang/OTP: see more in the User's Guide.

  If the option is enabled, and no pwdfun is present, the user name must present in the user_passwords for the check to succeed but the value of the password is not checked.

  In case of a pwdfun checking the user, the atom pubkey is put in the password argument.

• password - Provides a global password that authenticates any user.

  Warning

  Intended to facilitate testing.

  From a security perspective this option makes the server very vulnerable.

• pwdfun with pwdfun_4/0 - Provides a function for password validation. This could used for calling an external system or handling passwords stored as hash values.

  This fun can also be used to make delays in authentication tries for example by calling timer:sleep/1.

  To facilitate for instance counting of failed tries, the State variable could be used. This state is per connection only. The first time the pwdfun is called for a connection, the State variable has the value undefined.

  The fun should return:

  • true if the user and password is valid
  • false if the user or password is invalid
  • disconnect if a SSH_MSG_DISCONNECT message should be sent immediately. It will be followed by a close of the underlying tcp connection.
  • {true, NewState:any()} if the user and password is valid
  • {false, NewState:any()} if the user or password is invalid

  A third usage is to block login attempts from a missbehaving peer. The State described above can be used for this. The return value disconnect is useful for this.

  In case of the pk_check_user is set, the atom pubkey is put in the password argument when validating a public key login. The pwdfun is then responsible to check that the user name is valid.

• pwdfun with pwdfun_2/0 - Provides a function for password validation. This function is called with user and password as strings, and returns:

  • true if the user and password is valid
  • false if the user or password is invalid

  In case of the pk_check_user is set, the atom pubkey is put in the password argument when validating a public key login. The pwdfun is then responsible to check that the user name is valid.

  This variant is kept for compatibility.

• no_auth_needed - If true, a client is authenticated without any need of providing any password or key.

  This option is only intended for very special applications due to the high risk of accepting any connecting client.

  The default value is false.

-type send_ext_info_daemon_option() :: {send_ext_info, boolean()}.

Make the server (daemon) tell the client that the server accepts extension negotiation, that is, include ext-info-s in the kexinit message sent. See RFC 8308 for details and ssh(6) for a list of currently implemented extensions.

Default value is true which is compatible with other implementations not supporting ext-info.

-type 'shell_fun/2'() :: fun((User :: string(), PeerAddr :: inet:ip_address()) -> pid()).

Defines the read-eval-print loop used in a daemon when a shell is requested by the client. The default is to use the Erlang shell: {shell, start, []}

See the option exec-option for a description of how the daemon executes shell-requests and exec-requests depending on the shell- and exec-options.

-type ssh_cli_daemon_option() :: {ssh_cli, mod_args() | no_cli}.

Provides your own CLI implementation in a daemon.

It is a channel callback module that implements a shell and command execution. The shell's read-eval-print loop can be customized, using the option shell. This means less work than implementing an own CLI channel. If ssh_cli is set to no_cli, the CLI channels like shell and exec are disabled and only subsystem channels are allowed.

-type ssh_moduli_file() :: {ssh_moduli_file, string()}.

• dh_gex_groups - Defines the groups the server may choose among when diffie-hellman-group-exchange is negotiated. See RFC 4419 for details. The three variants of this option are:

  • {Size=integer(),G=integer(),P=integer()} - The groups are given explicitly in this list. There may be several elements with the same Size. In such a case, the server will choose one randomly in the negotiated Size.

  • {file,filename()} - The file must have one or more three-tuples {Size=integer(),G=integer(),P=integer()} terminated by a dot. The file is read when the daemon starts.

  • {ssh_moduli_file,filename()} - The file must be in ssh-keygen moduli file format. The file is read when the daemon starts.

  The default list is fetched from the public_key application.

• dh_gex_limits - Limits what a client can ask for in diffie-hellman-group-exchange. The limits will be {MaxUsed = min(MaxClient,Max), MinUsed = max(MinClient,Min)} where MaxClient and MinClient are the values proposed by a connecting client.

  The default value is {0,infinity}.

  If MaxUsed < MinUsed in a key exchange, it will fail with a disconnect.

  See RFC 4419 for the function of the Max and Min values.

-type subsystem_spec() :: {Name :: string(), mod_args()}.

Defines a subsystem in the daemon.

The subsystem_name is the name that a client requests to start with for example ssh_connection:subsystem/4.

The channel_callback is the module that implements the ssh_server_channel (replaces ssh_daemon_channel) behaviour in the daemon. See the section Creating a Subsystem in the User's Guide for more information and an example.

If the subsystems option is not present, the value of ssh_sftpd:subsystem_spec([]) is used. This enables the sftp subsystem by default. The option can be set to the empty list if you do not want the daemon to run any subsystems.

-type tcpip_tunnel_in_daemon_option() :: {tcpip_tunnel_in, boolean()}.

Enables (true) or disables (false) the possibility to tunnel a TCP/IP connection in to a server. Disabled per default.

-type tcpip_tunnel_out_daemon_option() :: {tcpip_tunnel_out, boolean()}.

Enables (true) or disables (false) the possibility to tunnel a TCP/IP connection out of a server. Disabled per default.