Secure Shell Daemon
handles terminal interface for secure connections from ssh

sshd [-deiqtD46] [-b bits] [-f config_file]
            [-g login_grace_seconds] [-h host_key_file] [-k key_gen_seconds] [-o option] [-p port] [-u len]

Daemon service to provide secure encrypted communications between two untrusted hosts over an insecure network.

Started at boot from /etc/rc, forks a new daemon for each incoming connection or by inetd?

  1. SSH version 1

    Hosts have a public key.
    generates a server key. When a client connects the daemon responds with its host and server keys.
    The client:
    1. validates the host key against a previously stored version.
    2. generates a random number, encrypts it using the host and server keys and sends that to the server.
      The same random number is used to encrypt further communications during the session.
    3. selects the encryption algorithm to use from those offered by the server.
    4. authenticates using
      1. .rhosts,
      2. .rhosts combined with RSA host,
      3. RSA challenge-response or
      4. password .

  2. SSH protocol version 2

    The daemon does not generate a server key. Forward security is provided through a Diffie-Hellman key agreement.
    Session integrity is provided through a cryptographic message authentication code .

  3. Authentication methods:
    1. a public key based user (PubkeyAuthentication)
    2. client host (HostbasedAuthentication)
    3. password
    4. challenge response.

Command execution and data forwarding

Once authentiated a dialog for preparing the session is entered. client requests may include allocating a pseudo-tty, forwarding X11 connections, forwarding TCP/IP connections, or forwarding the authentication agent connection over the secure channel.

The client either requests a shell or execution of a command. The sides then enter session mode. In this mode, either side may send data at any time, and such data is forwarded to/from the shell or command on the server side, and the user terminal in the client side.

When the user program terminates and all forwarded X11 and other connections have been closed, the server sends command exit status to the client, and both sides exit.


Command-line options override the configuration file.

The configuration file is re-read on receipt of a hangup signal, (killall --signal SIGHUP --verbose sshd) which disconnects current sessions.

Command line options are for debugging.
-d Debug mode. Sends verbose debug output, does not background, will not fork and will only process one connection.
Multiple -ds increase the debugging level. Maximum is 3.
-e output debugging messages to the standard error instead of the system log.
-q Quiet mode. Nothing is sent to the system log.
Normally the beginning, authentication, and termination of each connection is logged.
-D Does not detach and does not become a daemon.
-f configuration_file Default /etc/ssh/sshd_config.
Must exist.
-t Test the validity of the configuration file and sanity of the keys only.
-i running from inetd.
Not normally because generating the server key before responding to the client, may take tens of seconds and clients may timeout waiting. With small key sizes (e.g., 512) using sshd from inetd may be feasible.
Command line options
-b numbits for protocol version 1 server key, Default 768.
-h host_key_file Must be given if sshd is not run as root .
Default /etc/ssh/ssh_host_key for protocol version 1, and
/etc/ssh/ssh_host_rsa_key and
/etc/ssh/ssh_host_dsa_key for protocol version 2.
Multiple host key files are permitted.
-k key_gen_seconds Persistance of protocol version 1 server key
Default 3600 seconds.
After about an hour, it becomes impossible to recover the key for decrypting intercepted communications even if the machine is cracked into or physically seized.
Zero: key will never be regenerated. Seems unwise ed
-u bytes size of the field in the utmp structure that holds the remote host name. If the resolved host name is longer the dotted decimal value will be used. Allows hosts with very long names to be uniquely identified.
-u0 indicates only dotted decimal addresses should be put into the utmp file and prevents DNS requests unless the authentication mechanism or configuration requires it.
Authentication mechanisms that may DNS include: RhostsAuthentication, RhostsRSAAuthentication, HostbasedAuthentication and using from="pattern-list" in a key file.
Configuration options that require DNS include using a USER@HOST pattern in AllowUsers or DenyUsers.
-p port Default 22. Multiple port options are permitted.
Ports specfied in the configuration file are ignored when a command-line port is specified.
-4 use IPv4 addresses only.
-6 use IPv6 addresses only.
-g login_grace_seconds max authenticate time(default 120 seconds).
If the client fails to authenticate the user within this many seconds, the server disconnects and exits.
Zero : no limit.bad ideaed
-o option give options in the format used in the configuration file.

Configuration File

sshd_config and ssh_conf.

Login Process

Files and Permissions

If this file exists, sshd refuses to let anyone except root log in. The contents of the file are displayed to anyone trying to log in, and non-root connections are refused, world-readable.

Default file that lists the public keys for RSA authentication in protocol version 1 and for PubkeyAuthentication in protocol version 2.
AuthorizedKeysFile may be used to specify an alternative file.
Empty lines and lines starting with a # are ignored as comments.

Each line contains seperated fields.
For RSA public key's fields separated by spaces: options bits exponent modulus comment.
For version 2 public key's : options keytype base64EncodedKey comment.
The options field is not required; its presence is determined by whether the line starts with a number or not since the options never start with a number).
The bits, exponent, modulus and comment fields give the RSA key for protocol version 1; the comment field is not used to identify the key). the keytype is ssh-dss or ssh-rsa.

Lines are usually several hundred bytes long (because of the size of the public key encoding). You don't want to type them in; instead, copy, or and edit it.

Minimum RSA key modulus size is 768 bits.

The case-insensitive options consist of comma-separated option specifications.
No spaces are permitted, except within double quotes.

from="pattern-list" In addition to public key authentication, the canonical name of the remote host must be present in the comma- separated list of patterns (* and ? serve as wildcards).
Negated patterns, prefixed with !, matches cause the key to be not accepted.
This makes using a stolen key more difficult (name servers and/or routers would have to be compromised in addition).
command="command" executed whenever this key is used for authentication. A command supplied by the user is ignored.
Run on a pty if the client requests a pty; otherwise it is run without a tty.
If a 8-bit clean channel is required, one must not request a pty or should specify no-pty.
A quote may be included in the command by escaping it with a back slash.
Useful to restrict certain public keys to perform only a specific operation. An example might be a key that permits only remote backups. Note that the client may specify TCP/IP and/or X11 forwarding unless they are explicitly prohibited. Applies to shell, command or subsystem execution.
no-port-forwarding Forbids TCP/IP forwarding when this key is used for authentication.
This might be used, e.g., in connection with the command option.
environment="NAME=value" Added to the environment when logging in using this key, overrides default environment values.
Environment processing is disabled by default and is controlled via PermitUserEnvironment .
This option is disabled if UseLogin is enabled. Multiple occurances are permitted.
no-X11-forwarding Forbids X11 forwarding when this key is used for authentication. Any X11 forward requests by the client will return an error.
no-agent-forwarding Forbids authentication agent forwarding when this key is used for authentication.
no-pty Prevents tty allocation
permitopen="host:port" Limit local ssh -L port forwarding such that it may only connect to the specified host and port.
IPv6 addresses can be specified with an alternative syntax: host/port.
No pattern matching is performed on the specified hostnames, they must be literal domains or addresses.
Multiple occurances are permitted.

Examples of options

     1024 33 12121...312314325 
     from="*,!" 1024 35 23...2334 ylo@niksula 
     command="dump /home",no-pty,no-port-forwarding 1024 33 23...2323 
     permitopen="",permitopen="" 1024 33 23...2323
  $HOME/.ssh/known_hosts contain host public keys for all known hosts. The global file should be prepared by the administrator (optional), and the per-user file is maintained automatically: whenever the user connects from an unknown host its key is added to the per-user file.

Each line contains fields seperated by spaces: hostnames, bits, exponent, modulus, comment.

Hostnames is a comma-separated list of patterns ('*' and '?' act as wildcards); each pattern in turn is matched against the canonical host name (when authenticating a client) or against the user-supplied name (when authenticating a server). A pattern may also be preceded by ''! to indicate negation: if the host name matches a negated pattern, it is not accepted (by that line) even if it matched another pattern on the line.

Bits, exponent, and modulus are taken directly from the RSA host key; they can be obtained, e.g., from /etc/ssh/

Lines starting with # and empty lines are ignored

When performing host authentication, authentication is accepted if any matching line has the proper key. It is thus permissible (but not recommended) to have several lines or different host keys for the same names. This will inevitably happen when short forms of host names from different domains are put in the file. It is possible that the files contain conflicting information; authentication is accepted if valid information can be found from either file.

The lines are typically hundreds of characters long, and you definitely don't want to type in the host keys by hand. Rather, generate them by a script or by taking /etc/ssh/ and adding the host names at the front. Examples

closenet,..., 1024 37 159...93, ssh-rsa AAAA1234.....=

These contain the private parts of the host keys.
These files should be owned by root, with permissions readable only by owner, and not accessible to others.
sshd does not start if permissions include group/world access.


These contain the public parts of the host keys.
These files should be owned by root, with permissions writable only by owner, world-readable .
Their contents should match the respective private parts.
They are provided for the convenience of users so their contents can be copied to known hosts files. These files are created using ssh-keygen.

Groups used for the "Diffie-Hellman Group Exchange", described in moduli.

chroot(2) directory used by sshd during privilege separation in the pre-authentication phase. The directory should not contain any files and must be owned by root and not group or world- writable.

Lists the public keys (RSA or DSA) that can be used to log into the user's account.
It is recommended that it not be accessible by others.
Must be readable by root (which may require being world-readable if the user's home directory resides on an NFS volume).
Users place the contents of their, and/or files into this file, as described in ssh-keygen


Used with rhosts for RSA host authentication or protocol version 2 hostbased authentication to check the public key of the host. The key must be listed in one of these files to be accepted.
The client uses the same files to verify that it is connecting to the correct remote host.
Permissions:These files should be owned by root and writable only by the owner.
/etc/ssh/ssh_known_hosts should be world-readable, and
$HOME/.ssh/known_hosts can, but need not be world-readable.


Access controls that should be enforced by tcp-wrappers are defined here. See hosts_accessu.

Contains host-username pairs, separated by a space, one per line.
The given user on the corresponding host is permitted to log in without password.
Used by rlogind and rshd.
Permissions:owner Writable ; it is recommended that it not be accessible by others.

It is also possible to use netgroups in the file. host or user name may be of the form +@groupname to specify all hosts or all users in the group.

$HOME/.shosts See $HOME/.rhosts
Not used by rlogind or rshd.

Used during .rhosts authentication.
In the simplest form, contains host names, one per line.
Users from those hosts are permitted to log in without specifying their password, i.e. if they knew how to log in to host1.domain they are OK at host2.domain.
The host name may also be followed by a user name; such users are permitted to log in as any user on this machine (except root).
The syntax +@group can be used to specify netgroups.
Negated entries start with -

If the client host/user is successfully matched in this file, login is automatically permitted provided the client and server user names are the same. Additionally, successful RSA host authentication is normally required.
Permissions: owner root; writable by owner ; it is recommended that it be world-readable.

Warning: It is almost never a good idea to use user names in hosts.equiv. Beware that it really means that the named user(s) can log in as anybody, which includes bin, daemon, adm and other accounts that own critical binaries and directories.
Using a user name practically grants the user root access.
valid use for user names is for negative entries prohibiting particular users from using ssh.

Note that this warning also applies to rsh/rlogin.

Processed as /etc/hosts.equiv.
Useful in environments that run both rsh/rlogin and ssh.

Read into the environment at login
It can only contain empty lines, comment lines (that start with '#'), and assignment lines of the form name=value. Environment processing is disabled by default and is controlled via the PermitUserEnvironment option.
Permissions: owner writable anyone else.

Run with /bin/sh after reading the environment files but before starting the user's shell or command.
It must not produce any output to stdout; stderr is permitted.
If X11 forwarding is in use, it will receive the "proto cookie" pair in its standard input (and DISPLAY in its environment) and must call xauth

The primary purpose of this file is to run any initialization routines which may be needed before the user's home directory becomes accessible; AFS is a particular example of such an environment.

This file will probably contain some initialization code followed by something similar to:

 if read proto cookie && [ -n "$DISPLAY" ]; then
      if [ `echo $DISPLAY | cut -c1-10` = 'localhost:' ]; then
           # X11UseLocalhost=yes
           echo add unix:`echo $DISPLAY |
           cut -c11-` $proto $cookie
           # X11UseLocalhost=no
           echo add $DISPLAY $proto $cookie
      fi | xauth -q -
If this file does not exist, /etc/ssh/sshrc is run, and if that does not exist either, xauth is used to add the cookie.

Permissions:Writable only by the owner

Like $HOME/.ssh/rc. This can be used to specify machine-specific login-time initializations globally.
Permissions:owner root, owner writable and world-readable.
Contains the process ID of the sshd listening for connections (if there are several daemons running concurrently for different ports, contains the process ID of the one started last). The content of this file is not sensitive; it can be world-readable.

Used instead of rlogin and rsh .
Using ssh provides a secure connetion between hosts during a session.
Overall system security is not improved unless rshd, rlogind, and rexecd are disabled.

OpenSSH is a derivative of the original and free ssh 1.2.12

See also

scp, sftp, ssh, ssh-add, ssh-agent, ssh-keygen, login.conf moduli