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?
.rhostscombined with RSA host,
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.
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.|
/etc/nologinexists, outputs it and quits (unless root).
$HOME/.ssh/environmentif users are allowed to change their environment. See
xauth. The rc files are given the X11 authentication protocol and cookie in standard input.
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
Empty lines and lines starting with a
Each line contains seperated fields.
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
Minimum RSA key modulus size is 768 bits.
The case-insensitive options consist of comma-separated option specifications.
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 backup.hut.fi permitopen="10.2.1.55:80",permitopen="10.2.1.56:25" 1024 33 23...2323
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
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
closenet,...,18.104.22.168 1024 37 159...93 closenet.hut.fi
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
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.
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
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).
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.
Warning: It is almost never a good idea to use user names in
Note that this warning also applies to
Useful in environments that run both
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
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 # X11UseLocalhost=yes echo add unix:`echo $DISPLAY | cut -c11-` $proto $cookie else # X11UseLocalhost=no echo add $DISPLAY $proto $cookie fi | xauth -q - fi
Permissions:Writable only by the owner
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.
sshprovides a secure connetion between hosts during a session.
OpenSSH is a derivative of the original and free ssh 1.2.12