SSHD(8) SSH SSHD(8)NAMEsshd - secure shell daemon
SYNOPSISsshd [-b bits] [-d ] [-f config_file] [-g login_grace_time]
[-h host_key_file] [-i ] [-k key_gen_time] [-p port] [-q ] [-V version]
DESCRIPTION
Sshd (Secure Shell Daemon) is the daemon program for ssh. Together
these programs replace rlogin and rsh programs, and provide secure
encrypted communications between two untrusted hosts over an insecure
network. The programs are intended to be as easy to install and use as
possible.
Sshd is the daemon that listens for connections from clients. It is
normally started at boot from /etc/rc.local or equivalent. It forks a
new daemon for each incoming connection. The forked daemons handle key
exchange, encryption, authentication, command execution, and data
exchange.
Sshd works as follows. Each host has a host-specific RSA key (normally
1024 bits) used to identify the host. Additionally, when the daemon
starts, it generates a server RSA key (normally 768 bits). This key is
normally regenerated every hour if it has been used, and is never
stored on disk.
Whenever a client connects the daemon, the daemon sends its host and
server public keys to the client. The client compares the host key
against its own database to verify that it has not changed. The client
then generates a 256 bit random number. It encrypts this random number
using both the host key and the server key, and sends the encrypted
number to the server. Both sides then start to use this random number
as a session key which is used to encrypt all further communications in
the session. The rest of the session is encrypted using a conventional
cipher. Currently, IDEA, DES, 3DES, ARCFOUR, and TSS (a fast home-
grown algorithm) are supported. IDEA is used by default. The client
selects the encryption algorithm to use from those offered by the
server.
Next, the server and the client enter an authentication dialog. The
client tries to authenticate itself using .rhosts authentication,
.rhosts authentication combined with RSA host authentication, RSA chal‐
lenge-response authentication, TIS channenge response authentication,
or password based authentication.
Rhosts authentication is normally disabled because it is fundamentally
insecure, but can be enabled in the server configuration file if
desired. System security is not improved unless rshd(8), rlogind(8),
rexecd(8), and rexd (8) are disabled (thus completely disabling
rlogin(1) and rsh(1) into that machine).
If the client successfully authenticates itself, a dialog for preparing
the session is entered. At this time the client may request things
like allocating a pseudo-tty, forwarding X11 connections, forwarding
TCP/IP connections, or forwarding the authentication agent connection
over the secure channel.
Finally, 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 com‐
mand on the server side, and the user terminal in the client side.
When the user program terminates and all forwarded X11 and other con‐
nections have been closed, the server sends command exit status to the
client, and both sides exit.
Sshd can be configured using command-line options or a configuration
file. Command-line options override values specified in the configura‐
tion file.
Sshd rereads its configuration file if it is sent the hangup signal,
SIGHUP.
OPTIONS-b bits
Specifies the number of bits in the server key (default 768).
-d Debug mode. The server sends verbose debug output to the system
log, and does not put itself in the background. The server also
will not fork and will only process one connection. This option
is only intended for debugging for the server.
-f configuration_file
Specifies the name of the configuration file. The default is
/etc/sshd_config.
-g login_grace_time
Gives the grace time for clients to authenticate themselves
(default 600 seconds). If the client fails to authenticate the
user within this many seconds, the server disconnects and exits.
A value of zero indicates no limit.
-h host_key_file
Specifies the file from which the host key is read (default
/etc/ssh_host_key). This option must be given if sshd is not
run as root (as the normal host file is normally not readable by
anyone but root).
-i Specifies that sshd is being run from inetd. Sshd is normally
not run from inetd because it needs to generate the server key
before it can respond to the client, and this may take tens of
seconds. Clients would have to wait too long if the key was
regenerated every time. However, with small key sizes (e.g.
512) using sshd from inetd may be feasible.
-k key_gen_time
Specifies how often the server key is regenerated (default 3600
seconds, or one hour). The motivation for regenerating the key
fairly often is that the key is not stored anywhere, and 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. A value of zero indicates
that the key will never be regenerated.
-p port
Specifies the port on which the server listens for connections
(default 22).
-q Quiet mode. Nothing is sent to the system log. Normally the
beginning, authentication, and termination of each connection is
logged.
-V SSH version 2 compatibility mode. Server assumes that SSH ver‐
sion 2 daemon has already read the version number string from
the client and this option gives the version string read from
the client.
CONFIGURATION FILE
Sshd reads configuration data from /etc/sshd_config (or the file speci‐
fied with -f on the command line). The file contains keyword-value
pairs, one per line. Lines starting with ´#´ and empty lines are
interpreted as comments.
The following keywords are possible. Keywords are case insensitive.
AllowGroups
This keyword can be followed by any number of group name pat‐
terns, separated by spaces. If specified, login is allowed only
if users primary group name matches one of the patterns. ´*´ and
´?´ can be used as wildcards in the patterns. By default, logins
as all users are allowed.
Note that the all other login authentication steps must still be
sucessfully completed. AllowGroups and DenyGroups are addi‐
tional restrictions.
AllowHosts
This keyword can be followed by any number of host name pat‐
terns, separated by spaces. If specified, login is allowed only
from hosts whose name matches one of the patterns. ´*´ and ´?´
can be used as wildcards in the patterns. Normal name servers
are used to map the client's host into a canonical host name.
If the name cannot be mapped, its IP-address is used as the host
name. By default all hosts are allowed to connect.
Note that sshd can also be configured to use tcp_wrappers using
the --with-libwrap compile-time configuration option.
AccountExpireWarningDays
Specifies when to start print warning messages that the account
is going to expire. The value is number of days before the
account expiration. The default value is 14 days, and if set to
0 the warning messages are disabled.
AllowSHosts
This keyword can be followed by any number of host name pat‐
terns, separated by spaces. If specified, .shosts (and .rhosts
and /etc/hosts.equiv) entries are only honoured for hosts whose
name matches one of the patterns. servers are used to map the
client's host into a canonical host name. If the name cannot be
mapped, its IP-address is used as the host name. By default all
hosts are allowed to connect.
AllowTcpForwarding
Specifies whether tcp forwarding is permitted. The default is
"yes". Note that disabling tcp forwarding does not improve
security in any way, as users can always install their own for‐
warders.
AllowUsers
This keyword can be followed by any number of user name patterns
or user@host patterns, separated by spaces. Host name may be
either the dns name or the ip address. If specified, login is
allowed only as users whose name matches one of the patterns.
´*´ and ´?´ can be used as wildcards in the patterns. By
default, logins as all users are allowed.
Note that the all other login authentication steps must still be
sucessfully completed. AllowUsers and DenyUsers are additional
restrictions.
CheckMail
Specifies whether sshd should print information whether you have
new mail or not when a user logs in interactively. (On some
systems it is also printed by the shell, /etc/profile, or equiv‐
alent.) The default is "yes".
DenyGroups
This keyword can be followed by any number of group name pat‐
terns, separated by spaces. If specified, login is disallowed if
users primary group name name matches any of the patterns.
DenyHosts
This keyword can be followed by any number of host name pat‐
terns, separated by spaces. If specified, login is disallowed
from the hosts whose name matches any of the patterns.
DenySHosts
This keyword can be followed by any number of host name pat‐
terns, separated by spaces. If specified, .shosts (and .rhosts
and /etc/hosts.equiv) entries whose name matches any of the pat‐
terns are ignored.
DenyUsers
This keyword can be followed by any number of user name patterns
or user@host patterns, separated by spaces. Host name may be
either the dns name or the ip address. If specified, login is
disallowed as users whose name matches any of the patterns.
FascistLogging
Specifies whether to use verbose logging. Verbose logging vio‐
lates the privacy of users and is not recommended. The argument
must be "yes" or "no" (without the quotes). The default is
"no".
ForcedEmptyPasswdChange
Specifies whether to force password change if the password is
empty (first login). . The argument must be "yes" or "no" (with‐
out the quotes). The default is "no".
ForcedPasswdChange
Specifies whether to force password change if the password is
expired. The argument must be "yes" or "no" (without the
quotes). The default is "yes".
HostKey
Specifies the file containing the private host key (default
/etc/ssh_host_key).
IdleTimeout time
Sets idle timeout limit to time in seconds (s or nothing after
number), in minutes (m), in hours (h), in days (d), or in weeks
(w). If the connection have been idle (all channels) for that
long time the child process is killed with SIGHUP, and connec‐
tion is closed down.
IgnoreRhosts
Specifies that rhosts and shosts files will not be used in
authentication. /etc/hosts.equiv and /etc/shosts.equiv are
still used. The default is "no".
IgnoreRootRhosts
Specifies that rhosts and shosts files will not be used in
authentication for root. The default is the value of Ignor‐
eRhosts.
KeepAlive
Specifies whether the system should send keepalive messages to
the other side. If they are sent, death of the connection or
crash of one of the machines will be properly noticed. However,
this means that connections will die if the route is down tempo‐
rarily, and some people find it annoying. On the other hand, if
keepalives are not send, sessions may hang indefinitely on the
server, leaving "ghost" users and consuming server resources.
The default is "yes" (to send keepalives), and the server will
notice if the network goes down or the client host reboots.
This avoids infinitely hanging sessions.
To disable keepalives, the value should be set to "no" in both
the server and the client configuration files.
KerberosAuthentication
Specifies whether Kerberos V5 authentication is allowed. This
can be in the form of a Kerberos ticket, or if PasswordAuthenti‐
cation is yes, the password provided by the user will be vali‐
dated through the Kerberos KDC or DCE Security Server. Default
is yes.
KerberosOrLocalPasswd
If set then if password authentication through Kerberos fails
then the password will be validated via any additional local
mechanism such as /etc/passwd or SecurID. Default is no.
KerberosTgtPassing
Specifies whether a Kerberos V5 TGT may be forwarded to the
server. Default is yes.
KeyRegenerationInterval
The server key is automatically regenerated after this many sec‐
onds (if it has been used). The purpose of regeneration is to
prevent decrypting captured sessions by later breaking into the
machine and stealing the keys. The key is never stored any‐
where. If the value is 0, the key is never regenerated. The
default is 3600 (seconds).
ListenAddress
Specifies the ip address of the interface where the sshd server
socket is bind.
LoginGraceTime
The server disconnects after this time if the user has not suc‐
cessfully logged in. If the value is 0, there is no time limit.
The default is 600 (seconds).
PasswordAuthentication
Specifies whether password authentication is allowed. The
default is "yes".
PasswordExpireWarningDays
Specifies when to start print warning messages that the password
is going to expire. The value is number of days before the pass‐
word expiration. The default value is 14 days, and if set to 0
the warning messages are disabled.
PermitEmptyPasswords
When password authentication is allowed, it specifies whether
the server allows login to accounts with empty password strings.
The default is "yes".
PermitRootLogin
Specifies whether the root can log in using ssh. May be set to
"yes", "nopwd", or "no". The default is "yes", allowing root
logins through any of the authentication types allowed for other
users. The "nopwd" value disables password-authenticated root
logins. The "no" value disables root logins through any of the
authentication methods. ("nopwd" and "no" are equivalent unless
you have a .rhosts, .shosts, or .ssh/authorized_keys file in the
root home directory.)
Root login with RSA authentication when the "command" option has
been specified will be allowed regardless of the value of this
setting (which may be useful for taking remote backups even if
root login is normally not allowed).
PidFile
Specifies the location of the file containing the process ID of
the master sshd daemon (default: /etc/sshd.pid or
/var/run/sshd.pid, depending on the system).
Port Specifies the port number that sshd listens on. The default is
22.
PrintMotd
Specifies whether sshd should print /etc/motd when a user logs
in interactively. (On some systems it is also printed by the
shell, /etc/profile, or equivalent.) The default is "yes".
QuietMode
Specifies whether the system runs in quiet mode. In quiet mode,
nothing is logged in the system log, except fatal errors. The
default is "no".
RandomSeed
Specifies the file containing the random seed for the server;
this file is created automatically and updated regularly. The
default is /etc/ssh_random_seed.
RhostsAuthentication
Specifies whether authentication using rhosts or
/etc/hosts.equiv files is sufficient. Normally, this method
should not be permitted because it is insecure. RhostsRSAAu‐
thentication should be used instead, because it performs RSA-
based host authentication in addition to normal rhosts or
/etc/hosts.equiv authentication. The default is "no".
RhostsRSAAuthentication
Specifies whether rhosts or /etc/hosts.equiv authentication
together with successful RSA host authentication is allowed.
The default is "yes".
RSAAuthentication
Specifies whether pure RSA authentication is allowed. The
default is "yes".
ServerKeyBits
Defines the number of bits in the server key. The minimum value
is 512, and the default is 768.
SilentDeny
Specifies wheter denied (or not allowed) connections are denied
silently (just close the connection, no logging etc) or are they
closed cleanly (send error message and log connection attempt).
StrictModes
Specifies whether ssh should check file modes and ownership of
the user's home directory and rhosts files before accepting
login. This is normally desirable because novices sometimes
accidentally leave their directory or files world-writable. The
default is "yes".
SyslogFacility
Gives the facility code that is used when logging messages from
sshd. The possible values are: DAEMON, USER, AUTH, LOCAL0,
LOCAL1, LOCAL2, LOCAL3, LOCAL4, LOCAL5, LOCAL6, LOCAL7. The
default is DAEMON.
TISAuthentication
Specifies wether authentication through TIS authsrv (8) is
allowed. The default is "no".
Umask Sets default umask for sshd and its childs. Remember to add 0 in
front of the number to make it octal. Default is to not set
umask at all.
X11Forwarding
Specifies whether X11 forwarding is permitted. The default is
"yes". Note that disabling X11 forwarding does not improve
security in any way, as users can always install their own for‐
warders.
X11DisplayOffset
Specifies the first display number available for sshd's X11 for‐
warding. This prevents sshd from interfering with real X11
servers.
XAuthLocation
Specifies the default path to xauth program.
LOGIN PROCESS
When a user successfully logs in, sshd does the following:
1. If the login is on a tty, and no command has been specified,
prints last login time and /etc/motd (unless prevented in the
configuration file or by $HOME/.hushlogin; see the FILES sec‐
tion).
2. If the login is on a tty, records login time.
3. Checks /etc/nologin; if it exists, prints contents and quits
(unless root).
4. Changes to run with normal user privileges.
5. Sets up basic environment.
6. Reads /etc/environment if it exists.
7. Reads $HOME/.ssh/environment if it exists.
8. Changes to user's home directory.
9. If $HOME/.ssh/rc exists, runs it (with the user's shell); else
if /etc/sshrc exists, runs it (with /bin/sh); otherwise runs
xauth. The "rc" files are given the X11 authentication protocol
and cookie in standard input.
10. Runs user's shell or command.
AUTHORIZED_KEYS FILE FORMAT
The $HOME/.ssh/authorized_keys file lists the RSA keys that are permit‐
ted for RSA authentication. Each line of the file contains one key
(empty lines and lines starting with a ´#´ are ignored as comments).
Each line consists of the following fields, separated by spaces:
options, bits, exponent, modulus, comment. The options field is
optional; its presence is determined by whether the line starts with a
number or not (the option field never starts with a number). The bits,
exponent, modulus and comment fields give the RSA key; the comment
field is not used for anything (but may be convenient for the user to
identify the key).
Note that lines in this file are usually several hundred bytes long
(because of the size of the RSA key modulus). You don't want to type
them in; instead, copy the identity.pub file and edit it.
The options (if present) consists of comma-separated option specifica‐
tions. No spaces are permitted, except within double quotes. Option
names are case insensitive. The following option specifications are
supported:
from="pattern-list"
Specifies that in addition to RSA authentication, the canonical
name of the remote host must be present in the comma-separated
list of patterns (´*´ and ´?´ serve as wildcards). The list may
also contain patterns negated by prefixing them with ´!´; if the
canonical host name matches a negated pattern, the key is not
accepted. The purpose of this option is to optionally increase
security: RSA authentication by itself does not trust the net‐
work or name servers or anything (but the key); however, if
somebody somehow steals the key, the key permits an intruder to
log in from anywhere in the world. This additional option makes
using a stolen key more difficult (name servers and/or routers
would have to be compromised in addition to just the key).
command="command"
Specifies that the command is executed whenever this key is used
for authentication. The command supplied by the user (if any)
is ignored. The command is run on a pty if the connection
requests a pty; otherwise it is run without a tty. A quote may
be included in the command by quoting it with a backslash. This
option might be useful to restrict certain RSA keys to perform
just a specific operation. An example might be a key that per‐
mits remote backups but nothing else. Notice that the client
may specify TCP/IP and/or X11 forwardings unless they are
explicitly prohibited.
environment="NAME=value"
Specifies that the string is to be added to the environment when
logging in using this key. Environment variables set this way
override other default environment values. Multiple options of
this type are permitted.
idle-timeout=time
Sets idle timeout limit to time in seconds (s or nothing after
number), in minutes (m), in hours (h), in days (d), or in weeks
(w). If the connection have been idle (all channels) for that
long time the child process is killed with SIGHUP, and connec‐
tion is closed down.
no-port-forwarding
Forbids TCP/IP forwarding when this key is used for authentica‐
tion. Any port forward requests by the client will return an
error. This might be used e.g. in connection with the command
option.
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 (a request to allocate a pty will fail).
Examples
1024 33 12121...312314325 ylo@foo.bar
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
SSH WITH TCP WRAPPERS
When sshd is compiled with tcp wrappers libraries, then the
host.allow/deny files also controls who can connect to ports forwarded
by sshd.
The program names in the hosts.allow/deny files are sshdfwd-<portname>,
sshdfwd-<portnumber>, and sshdfwd-X11 for forwarded ports the ssh
client or server is listening.
If the port has name defined then you must use it.
SSH_KNOWN_HOSTS FILE FORMAT
The /etc/ssh_known_hosts and $HOME/.ssh/known_hosts files contain host
public keys for all known hosts. The global file should be prepared by
the admistrator (optional), and the per-user file is maintained auto‐
matically: whenever the user connects an unknown host its key is added
to the per-user file. The recommended way to create
/etc/ssh_known_hosts is to use the make-ssh-known-hosts command.
Each line in these files contains the following fields: hostnames,
bits, exponent, modulus, comment. The fields are separated by spaces.
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 host key; they
can be obtained e.g. from /etc/ssh_host_key.pub. The optional comment
field continues to the end of the line, and is not used.
Lines starting with ´#´ and empty lines are ignored as comments.
When performing host authentication, authentication is accepted if any
matching line has the proper key. It is thus permissible (but not rec‐
ommended) 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.
Note that the lines in these files 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 (see make-ssh-known-hosts(1)) or by
taking /etc/ssh_host_key.pub and adding the host names at the front.
Examples
closenet,closenet.hut.fi,...,130.233.208.41 1024 37 159...93
closenet.hut.fi
FILES
/etc/sshd_config
Contains configuration data for sshd. This file should be
writable by root only, but it is recommended (though not neces‐
sary) that it be world-readable.
/etc/ssh_host_key
Contains the private part of the host key. This file is nor‐
mally created automatically by "make install", but can also be
created manually using ssh-keygen(1). This file should only be
owned by root, readable only by root, and not accessible to oth‐
ers.
/etc/ssh_host_key.pub
Contains the public part of the host key. This file is normally
created automatically by "make install", but can also be created
manually. This file should be world-readable but writable only
by root. Its contents should match the private part. This file
is not really used for anything; it is only provided for the
convenience of the user so its contents can be copied to known
hosts files.
/etc/ssh_random_seed
This file contains a seed for the random number generator. This
file should only be accessible by root.
/etc/sshd.pid
Contains the process id of the sshd listening for connections
(if there are several daemons running concurrently for different
ports, this contains the pid of the one started last). The con‐
tents of this file are not sensitive; it can be world-readable.
$HOME/.ssh/authorized_keys
Lists the RSA keys that can be used to log into the user's
account. This file must be readable by root (which may on some
machines imply it being world-readable if the user's home direc‐
tory resides on an NFS volume). It is recommended that it not
be accessible by others. The format of this file is described
above.
/etc/ssh_known_hosts and $HOME/.ssh/known_hosts
These files are consulted when using rhosts with RSA host
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 the remote host is the
one we intended to connect.) These files should be writable
only by root/the owner. /etc/ssh_known_hosts should be world-
readable, and $HOME/.ssh/known_hosts can but need not be world-
readable.
/etc/nologin
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. The file should
be world-readable.
$HOME/.rhosts
This file contains host-username pairs, separated by a space,
one per line. The given user on the corresponding host is per‐
mitted to log in without password. The same file is used by
rlogind and rshd. Ssh differs from rlogind and rshd in that it
requires RSA host authentication in addition to validating the
host name retrieved from domain name servers (unless compiled
with the --with-rhosts configuration option). The file must be
writable only by the user; it is recommended that it not be
accessible by others.
It is also possible to use netgroups in the file. Either host
or user name may be of the form +@groupname to specify all hosts
or all users in the group.
$HOME/.shosts
For ssh, this file is exactly the same as for .rhosts. However,
this file is not used by rlogin and rshd, so using this permits
access using ssh only.
/etc/hosts.equiv
This file is used during .rhosts authentication. In the sim‐
plest form, this file contains host names, one per line. Users
on those hosts are permitted to log in without a password, pro‐
vided they have the same user name on both machines. The host
name may also be followed by a user name; such users are permit‐
ted to log in as any user on this machine (except root). Addi‐
tionally, 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. This file must be writable
only by root; 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. The
only valid use for user names that I can think of is in negative
entries. Note that this warning also applies to rsh/rlogin.
/etc/shosts.equiv
This is processed exactly as /etc/hosts.equiv. However, this
file may be useful in environments that want to run both
rsh/rlogin and ssh.
/etc/environment
This file is read into the environment at login (if it exists).
It can only contain empty lines, comment lines (that start with
´#´), and assignment lines of the form name=value. This file is
processed in all environments (normal rsh/rlogin only process it
on AIX and potentially some other systems). The file should be
writable only by root, and should be world-readable.
$HOME/.ssh/environment
This file is read into the environment after /etc/environment.
It has the same format. The file should be writable only by the
user; it need not be readable by anyone else.
$HOME/.ssh/rc
If this file exists, it is run with the user's shell after read‐
ing the environment files but before starting the user's shell
or command. If X11 spoofing is in use, this will receive the
"proto cookie" pair in standard input (and DISPLAY in environ‐
ment). This must call xauth in that case.
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 envi‐
ronment.
This file will probably contain some initialization code fol‐
lowed by something similar to: "if read proto cookie; then echo
add $DISPLAY $proto $cookie | xauth -q -; fi".
If this file does not exist, /etc/sshrc is run, and if that does
not exist either, xauth is used to store the cookie.
This file should be writable only by the user, and need not be
readable by anyone else.
/etc/sshrc
Like $HOME/.ssh/rc, but run with /bin/sh. This can be used to
specify machine-specific login-time initializations globally.
This file should be writable only by root, and should be world-
readable.
/etc/sshd_tis.map
Establishes a mapping between a local username and its corre‐
sponding name in the TIS database. Each line contains the local
name followed by a ":" followed by the corresponding name. If
the file does not exist or the user is not found, the corre‐
sponding name in the TIS database is supposed to be the same.
INSTALLATION
Sshd is normally run as root. If it is not run as root, it can only
log in as the user it is running as, and password authentication may
not work if the system uses shadow passwords. An alternative host key
file must also be used.
Sshd is normally started from /etc/rc.local or equivalent at system
boot.
Considerable work has been put to making sshd secure. However, if you
find a security problem, please report it immediately to <ssh-
bugs@cs.hut.fi>.
AUTHOR
Tatu Ylonen <ylo@ssh.fi>
Information about new releases, mailing lists, and other related issues
can be found from the ssh WWW home page at http://www.cs.hut.fi/ssh.
SEE ALSOssh(1), make-ssh-known-hosts(1), ssh-keygen(1), ssh-agent(1), ssh-
add(1), scp(1), rlogin(1), rsh(1)SSH November 8, 1995 SSHD(8)
