Secure Shell Daemon
handles terminal interface for secure connections from ssh
sshd [-deiqtD46] [-b bits] [-f config_file]
[-h host_key_file] [-k key_gen_seconds] [-o option] [-p port] [-u len]
Used instead of
rsh to provide secure encrypted communications
between two untrusted hosts over an insecure network.
ssh provides a secure connetion between hosts during a session.
Overall system security is not improved unless
rexecd are disabled.
Normally started at boot from
/etc/rc, forks a new daemon for each
incoming connection, which handle key exchange, encryption,
authentication, command execution, and data exchange.
SSH protocol version 1
Hosts have a public key.
When the daemon starts, it generates a server key.
SSH version 1
When a client connects the daemon responds with its host and server keys.
- validates the host key against a previously stored version.
- generates a random number, encrypts it using the host and server keys and sends that to the
The same random number is used to encrypt further communications during the session.
- selects the encryption algorithm to use from those offered by the server.
- authenticates using
.rhosts combined with RSA host,
- RSA challenge-response or
- password .
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 .
- a public key based user (PubkeyAuthentication)
- client host (HostbasedAuthentication)
- 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 values specified in the configuration file.
The configuration file is re-read on receipt of a hangup signal,
SIGHUP, by executing itself with the name it was started as, i.e.,
| Command line options are for debugging.
| Debug mode. Sends verbose debug output,
does not background, will not fork and will only process one connection.|
-ds increase the debugging level. Maximum is 3.
| output debugging messages to the standard error instead of the system log.
|Quiet mode. Nothing is sent to the system log. |
Normally the beginning, authentication, and termination of each connection is logged.
| Does not detach and does not become a daemon.
| Default |
| Test the validity of the configuration file and sanity of the keys only.
| running from
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
| for protocol version 1 server key, Default 768.
| Must be given if sshd is not run as root .|
/etc/ssh/ssh_host_key for protocol version 1, and
/etc/ssh/ssh_host_dsa_key for protocol version 2.
Multiple host key files are permitted.
| 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
|size of the field in the |
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:
HostbasedAuthentication and using
from="pattern-list" in a key file.
Configuration options that require DNS include using a
USER@HOST pattern in
| Default 22. Multiple port options are permitted. |
Ports specfied in the configuration file are ignored when a command-line port is specified.
| use IPv4 addresses only.
|use IPv6 addresses only.
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
| give options in the format used in the configuration file.
see sshd_config and ssh_conf.
- When a user successfully logs in:
- If the login is on a tty, and no command has been specified,
output last login and
- Records login time (for lastlogin), if the login is on a tty,
/etc/nologin exists, outputs it and quits (unless root).
- Changes to normal user privileges.
- Sets up basic environment. (meaning??) ed
$HOME/.ssh/environment if users are
allowed to change their environment. See
xauth. The rc files are
given the X11 authentication protocol and cookie in standard input.
- Runs user's shell or command from
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.
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
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
identity.pub, id_dsa.pub or
id_rsa.pub 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.
| In addition to public key authentication, the
canonical name of the remote host must be present in the comma-
separated list of patterns (|
? 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).
| 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.
Forbids TCP/IP forwarding when this key is used for authentication. |
This might be used, e.g., in connection with the command option.
Added to the environment when logging in using this key, overrides default environment values. |
Environment processing is disabled by default and is controlled via
This option is disabled if
UseLogin is enabled.
Multiple occurances are permitted.
Forbids X11 forwarding when this key is used for authentication.
Any X11 forward requests by the client will return an error.
Forbids authentication agent forwarding when this key is used for authentication.
|Prevents tty allocation
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 email@example.com
from="*.niksula.hut.fi,!pc.niksula.hut.fi" 1024 35 23...2334 ylo@niksula
command="dump /home",no-pty,no-port-forwarding 1024 33 23...2323
permitopen="10.2.1.55:80",permitopen="10.2.1.56:25" 1024 33 23...2323
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
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
and adding the host names at the front.
closenet,...,184.108.40.206 1024 37 159...93 closenet.hut.fi
cvs.openbsd.org,220.127.116.11 ssh-rsa AAAA1234.....=
Described in sshd_config.
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
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
id_rsa.pub files into this file,
as described in ssh-keygen
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.
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.
Not used by
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).
+@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.
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
Useful in environments that run both
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
/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
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 this file does not exist,
if read proto cookie && [ -n "$DISPLAY" ]; then
if [ `echo $DISPLAY | cut -c1-10` = 'localhost:' ]; then
echo add unix:`echo $DISPLAY |
cut -c11-` $proto $cookie
echo add $DISPLAY $proto $cookie
fi | xauth -q -
/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
$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.
OpenSSH is a derivative of the original and free ssh 1.2.12 release by
Tatu Ylonen. Aaron Campbell, Bob Beck, Markus Friedl, Niels Provos, Theo
de Raadt and Dug Song removed many bugs, re-added newer features and created OpenSSH. Markus Friedl contributed the support for SSH protocol
versions 1.5 and 2.0. Niels Provos and Markus Friedl contributed support
for privilege separation.
scp, sftp, ssh,
ssh-add, ssh-agent, ssh-keygen,
T. Ylonen, T. Kivinen, M. Saarinen, T. Rinne, and S. Lehtinen, SSH
Protocol Architecture, draft-ietf-secsh-architecture-12.txt, January
2002, work in progress material.
M. Friedl, N. Provos, and W. A. Simpson, Diffie-Hellman Group Exchange
for the SSH Transport Layer Protocol, draft-ietf-secsh-dh-group-
exchange-02.txt, January 2002, work in progress material.
BSD September 25, 1999 BSD