Content-type: text/html
Manpage of SSHD
SSHD
Section: Maintenance Commands (8)
Index
Return to Main Contents
BSD mandoc
NAME
sshd
- OpenSSH SSH daemon
SYNOPSIS
sshd
[-deiqtD46
]
[-b bits
]
[-f config_file
]
[-g login_grace_time
]
[-h host_key_file
]
[-k key_gen_time
]
[-o option
]
[-p port
]
[-u len
]
DESCRIPTION
sshd
(SSH Daemon) is the daemon program for
ssh(1).
Together these programs replace rlogin and rsh, 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
It forks a new
daemon for each incoming connection.
The forked daemons handle
key exchange, encryption, authentication, command execution,
and data exchange.
This implementation of
sshd
supports both SSH protocol version 1 and 2 simultaneously.
sshd
works as follows.
SSH protocol version 1
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 responds with its public
host and server keys.
The client compares the
RSA 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 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 Blowfish or 3DES, with 3DES
being 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 challenge-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),
and
rexecd(8)
are disabled (thus completely disabling
rlogin(1)
and
rsh(1)
into the machine).
SSH protocol version 2
Version 2 works similarly:
Each host has a host-specific key (RSA or DSA) used to identify the host.
However, when the daemon starts, it does not generate a server key.
Forward security is provided through a Diffie-Hellman key agreement.
This key agreement results in a shared session key.
The rest of the session is encrypted using a symmetric cipher, currently
128 bit AES, Blowfish, 3DES, CAST128, Arcfour, 192 bit AES, or 256 bit AES.
The client selects the encryption algorithm
to use from those offered by the server.
Additionally, session integrity is provided
through a cryptographic message authentication code
(hmac-sha1 or hmac-md5).
Protocol version 2 provides a public key based
user (PubkeyAuthentication) or
client host (HostbasedAuthentication) authentication method,
conventional password authentication and challenge response based methods.
Command execution and data forwarding
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
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.
sshd
can be configured using command-line options or a configuration
file.
Command-line options override values specified in the
configuration file.
sshd
rereads its configuration file when it receives a hangup signal,
SIGHUP
by executing itself with the name it was started as, i.e.,
/usr/sbin/sshd
The options are as follows:
- -b bits
-
Specifies the number of bits in the ephemeral protocol version 1
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.
Multiple -d options increase the debugging level.
Maximum is 3.
- -e
-
When this option is specified,
sshd
will send the output to the standard error instead of the system log.
- -f configuration_file
-
Specifies the name of the configuration file.
The default is
/etc/ssh/sshd_config
sshd
refuses to start if there is no configuration file.
- -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 a file from which a host key is read.
This option must be given if
sshd
is not run as root (as the normal
host key files are normally not readable by anyone but root).
The default is
/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.
It is possible to have multiple host key files for
the different protocol versions and host key algorithms.
- -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 ephemeral protocol version 1 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.
- -o option
-
Can be used to give options in the format used in the configuration file.
This is useful for specifying options for which there is no separate
command-line flag.
- -p port
-
Specifies the port on which the server listens for connections
(default 22).
Multiple port options are permitted.
Ports specified in the configuration file are ignored when a
command-line port is specified.
- -q
-
Quiet mode.
Nothing is sent to the system log.
Normally the beginning,
authentication, and termination of each connection is logged.
- -t
-
Test mode.
Only check the validity of the configuration file and sanity of the keys.
This is useful for updating
sshd
reliably as configuration options may change.
- -u len
-
This option is used to specify the size of the field
in the
utmp
structure that holds the remote host name.
If the resolved host name is longer than
len
the dotted decimal value will be used instead.
This allows hosts with very long host names that
overflow this field to still be uniquely identified.
Specifying
-u0
indicates that only dotted decimal addresses
should be put into the
utmp
file.
-u0
is also be used to prevent
sshd
from making DNS requests unless the authentication
mechanism or configuration requires it.
Authentication mechanisms that may require DNS include
RhostsAuthentication
RhostsRSAAuthentication
HostbasedAuthentication
and using a
from=pattern-list
option in a key file.
Configuration options that require DNS include using a
USER@HOST pattern in
AllowUsers
or
DenyUsers
- -D
-
When this option is specified
sshd
will not detach and does not become a daemon.
This allows easy monitoring of
sshd
- -4
-
Forces
sshd
to use IPv4 addresses only.
- -6
-
Forces
sshd
to use IPv6 addresses only.
CONFIGURATION FILE
sshd
reads configuration data from
/etc/ssh/sshd_config
(or the file specified with
-f
on the command line).
The file contains keyword-argument pairs, one per line.
Lines starting with
`#'
and empty lines are interpreted as comments.
The possible
keywords and their meanings are as follows (note that
keywords are case-insensitive and arguments are case-sensitive):
- AFSTokenPassing
-
Specifies whether an AFS token may be forwarded to the server.
Default is
``yes''
- AllowGroups
-
This keyword can be followed by a list of group name patterns, separated
by spaces.
If specified, login is allowed only for users whose primary
group or supplementary group list matches one of the patterns.
`*'
and
`?'
can be used as
wildcards in the patterns.
Only group names are valid; a numerical group ID is not recognized.
By default, login is allowed for all groups.
- AllowTcpForwarding
-
Specifies whether TCP forwarding is permitted.
The default is
``yes''
Note that disabling TCP forwarding does not improve security unless
users are also denied shell access, as they can always install their
own forwarders.
- AllowUsers
-
This keyword can be followed by a list of user name patterns, separated
by spaces.
If specified, login is allowed only for users names that
match one of the patterns.
`*'
and
`?'
can be used as
wildcards in the patterns.
Only user names are valid; a numerical user ID is not recognized.
By default, login is allowed for all users.
If the pattern takes the form USER@HOST then USER and HOST
are separately checked, restricting logins to particular
users from particular hosts.
- AuthorizedKeysFile
-
Specifies the file that contains the public keys that can be used
for user authentication.
AuthorizedKeysFile
may contain tokens of the form %T which are substituted during connection
set-up. The following tokens are defined: %% is replaced by a literal '%',
%h is replaced by the home directory of the user being authenticated and
%u is replaced by the username of that user.
After expansion,
AuthorizedKeysFile
is taken to be an absolute path or one relative to the user's home
directory.
The default is
``.ssh/authorized_keys''
- Banner
-
In some jurisdictions, sending a warning message before authentication
may be relevant for getting legal protection.
The contents of the specified file are sent to the remote user before
authentication is allowed.
This option is only available for protocol version 2.
- ChallengeResponseAuthentication
-
Specifies whether challenge response authentication is allowed.
All authentication styles from
login.conf5
are supported.
The default is
``yes''
- Ciphers
-
Specifies the ciphers allowed for protocol version 2.
Multiple ciphers must be comma-separated.
The default is
``aes128-cbc,3des-cbc,blowfish-cbc,cast128-cbc,arcfour,
aes192-cbc,aes256-cbc''
- ClientAliveInterval
-
Sets a timeout interval in seconds after which if no data has been received
from the client,
sshd
will send a message through the encrypted
channel to request a response from the client.
The default
is 0, indicating that these messages will not be sent to the client.
This option applies to protocol version 2 only.
- ClientAliveCountMax
-
Sets the number of client alive messages (see above) which may be
sent without
sshd
receiving any messages back from the client. If this threshold is
reached while client alive messages are being sent,
sshd
will disconnect the client, terminating the session. It is important
to note that the use of client alive messages is very different from
KeepAlive
(below). The client alive messages are sent through the
encrypted channel and therefore will not be spoofable. The TCP keepalive
option enabled by
KeepAlive
is spoofable. The client alive mechanism is valuable when the client or
server depend on knowing when a connection has become inactive.
The default value is 3. If
ClientAliveInterval
(above) is set to 15, and
ClientAliveCountMax
is left at the default, unresponsive ssh clients
will be disconnected after approximately 45 seconds.
- DenyGroups
-
This keyword can be followed by a list of group name patterns, separated
by spaces.
Login is disallowed for users whose primary group or supplementary
group list matches one of the patterns.
`*'
and
`?'
can be used as
wildcards in the patterns.
Only group names are valid; a numerical group ID is not recognized.
By default, login is allowed for all groups.
- DenyUsers
-
This keyword can be followed by a list of user name patterns, separated
by spaces.
Login is disallowed for user names that match one of the patterns.
`*'
and
`?'
can be used as wildcards in the patterns.
Only user names are valid; a numerical user ID is not recognized.
By default, login is allowed for all users.
If the pattern takes the form USER@HOST then USER and HOST
are separately checked, restricting logins to particular
users from particular hosts.
- GatewayPorts
-
Specifies whether remote hosts are allowed to connect to ports
forwarded for the client.
By default,
sshd
binds remote port forwardings to the loopback addresss. This
prevents other remote hosts from connecting to forwarded ports.
GatewayPorts
can be used to specify that
sshd
should bind remote port forwardings to the wildcard address,
thus allowing remote hosts to connect to forwarded ports.
The argument must be
``yes''
or
``no''
The default is
``no''
- HostbasedAuthentication
-
Specifies whether rhosts or /etc/hosts.equiv authentication together
with successful public key client host authentication is allowed
(hostbased authentication).
This option is similar to
RhostsRSAAuthentication
and applies to protocol version 2 only.
The default is
``no''
- HostKey
-
Specifies a file containing a private host key
used by SSH.
The default is
/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.
Note that
sshd
will refuse to use a file if it is group/world-accessible.
It is possible to have multiple host key files.
``rsa1''
keys are used for version 1 and
``dsa''
or
``rsa''
are used for version 2 of the SSH protocol.
- IgnoreRhosts
-
Specifies that
.rhosts
and
.shosts
files will not be used in
RhostsAuthentication
RhostsRSAAuthentication
or
HostbasedAuthentication
/etc/hosts.equiv
and
/etc/shosts.equiv
are still used.
The default is
``yes''
- IgnoreUserKnownHosts
-
Specifies whether
sshd
should ignore the user's
$HOME/.ssh/known_hosts
during
RhostsRSAAuthentication
or
HostbasedAuthentication
The default is
``no''
- KeepAlive
-
Specifies whether the system should send TCP 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 temporarily, and some people
find it annoying.
On the other hand, if keepalives are not sent,
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 crashes.
This avoids infinitely hanging sessions.
To disable keepalives, the value should be set to
``no''
- KerberosAuthentication
-
Specifies whether Kerberos authentication is allowed.
This can be in the form of a Kerberos ticket, or if
PasswordAuthentication
is yes, the password provided by the user will be validated through
the Kerberos KDC.
To use this option, the server needs a
Kerberos servtab which allows the verification of the KDC's identity.
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
Default is
``yes''
- KerberosTgtPassing
-
Specifies whether a Kerberos TGT may be forwarded to the server.
Default is
``no''
as this only works when the Kerberos KDC is actually an AFS kaserver.
- KerberosTicketCleanup
-
Specifies whether to automatically destroy the user's ticket cache
file on logout.
Default is
``yes''
- KeyRegenerationInterval
-
In protocol version 1, the ephemeral server key is automatically regenerated
after this many seconds (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 anywhere.
If the value is 0, the key is never regenerated.
The default is 3600 (seconds).
- ListenAddress
-
Specifies the local addresses
sshd
should listen on.
The following forms may be used:
- ListenAddress
-
host | IPv4_addr | IPv6_addr
- ListenAddress
-
host | IPv4_addr : port
- ListenAddress
-
[host | IPv6_addr : port
]
If
port
is not specified,
sshd
will listen on the address and all prior
Port
options specified. The default is to listen on all local
addresses. Multiple
ListenAddress
options are permitted. Additionally, any
Port
options must precede this option for non port qualified addresses.
- LoginGraceTime
-
The server disconnects after this time if the user has not
successfully logged in.
If the value is 0, there is no time limit.
The default is 600 (seconds).
- LogLevel
-
Gives the verbosity level that is used when logging messages from
sshd
The possible values are:
QUIET, FATAL, ERROR, INFO, VERBOSE, DEBUG, DEBUG1, DEBUG2 and DEBUG3.
The default is INFO. DEBUG and DEBUG1 are equivalent. DEBUG2
and DEBUG3 each specify higher levels of debugging output.
Logging with a DEBUG level violates the privacy of users
and is not recommended.
- MACs Specifies the available MAC (message authentication code) algorithms.
-
The MAC algorithm is used in protocol version 2
for data integrity protection.
Multiple algorithms must be comma-separated.
The default is
``hmac-md5,hmac-sha1,hmac-ripemd160,hmac-sha1-96,hmac-md5-96''
- MaxStartups
-
Specifies the maximum number of concurrent unauthenticated connections to the
sshd
daemon.
Additional connections will be dropped until authentication succeeds or the
LoginGraceTime
expires for a connection.
The default is 10.
Alternatively, random early drop can be enabled by specifying
the three colon separated values
``start:rate:full''
(e.g., "10:30:60").
sshd
will refuse connection attempts with a probability of
``rate/100''
(30%)
if there are currently
``start''
(10)
unauthenticated connections.
The probability increases linearly and all connection attempts
are refused if the number of unauthenticated connections reaches
``full''
(60).
- PAMAuthenticationViaKbdInt
-
Specifies whether PAM challenge response authentication is allowed. This
allows the use of most PAM challenge response authentication modules, but
it will allow password authentication regardless of whether
PasswordAuthentication
is disabled.
The default is
``no''
- PasswordAuthentication
-
Specifies whether password authentication is allowed.
The default is
``yes''
- PermitEmptyPasswords
-
When password authentication is allowed, it specifies whether the
server allows login to accounts with empty password strings.
The default is
``no''
- PermitRootLogin
-
Specifies whether root can login using
ssh(1).
The argument must be
``yes''
``without-password''
``forced-commands-only''
or
``no''
The default is
``yes''
If this option is set to
``without-password''
password authentication is disabled for root.
If this option is set to
``forced-commands-only''
root login with public key authentication will be allowed,
but only if the
command
option has been specified
(which may be useful for taking remote backups even if root login is
normally not allowed). All other authentication methods are disabled
for root.
If this option is set to
``no''
root is not allowed to login.
- PidFile
-
Specifies the file that contains the process identifier of the
sshd
daemon.
The default is
/var/run/sshd.pid
- Port
-
Specifies the port number that
sshd
listens on.
The default is 22.
Multiple options of this type are permitted.
See also
ListenAddress
- PrintLastLog
-
Specifies whether
sshd
should print the date and time when the user last logged in.
The default is
``yes''
- 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''
- Protocol
-
Specifies the protocol versions
sshd
should support.
The possible values are
``1''
and
``2''
Multiple versions must be comma-separated.
The default is
``2,1''
- PubkeyAuthentication
-
Specifies whether public key authentication is allowed.
The default is
``yes''
Note that this option applies to protocol version 2 only.
- RhostsAuthentication
-
Specifies whether authentication using rhosts or /etc/hosts.equiv
files is sufficient.
Normally, this method should not be permitted because it is insecure.
RhostsRSAAuthentication
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''
This option applies to protocol version 1 only.
- RhostsRSAAuthentication
-
Specifies whether rhosts or /etc/hosts.equiv authentication together
with successful RSA host authentication is allowed.
The default is
``no''
This option applies to protocol version 1 only.
- RSAAuthentication
-
Specifies whether pure RSA authentication is allowed.
The default is
``yes''
This option applies to protocol version 1 only.
- ServerKeyBits
-
Defines the number of bits in the ephemeral protocol version 1 server key.
The minimum value is 512, and the default is 768.
- StrictModes
-
Specifies whether
sshd
should check file modes and ownership of the
user's files and home directory before accepting login.
This is normally desirable because novices sometimes accidentally leave their
directory or files world-writable.
The default is
``yes''
- Subsystem
-
Configures an external subsystem (e.g., file transfer daemon).
Arguments should be a subsystem name and a command to execute upon subsystem
request.
The command
sftp-server8
implements the
``sftp''
file transfer subsystem.
By default no subsystems are defined.
Note that this option applies to protocol version 2 only.
- 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 AUTH.
- UseLogin
-
Specifies whether
login(1)
is used for interactive login sessions.
The default is
``no''
Note that
login(1)
is never used for remote command execution.
Note also, that if this is enabled,
X11Forwarding
will be disabled because
login(1)
does not know how to handle
xauth(1)
cookies.
- VerifyReverseMapping
-
Specifies whether
sshd
should try to verify the remote host name and check that
the resolved host name for the remote IP address maps back to the
very same IP address.
The default is
``no''
- X11DisplayOffset
-
Specifies the first display number available for
sshd 's
X11 forwarding.
This prevents
sshd
from interfering with real X11 servers.
The default is 10.
- X11Forwarding
-
Specifies whether X11 forwarding is permitted.
The default is
``no''
Note that disabling X11 forwarding does not improve security in any
way, as users can always install their own forwarders.
X11 forwarding is automatically disabled if
UseLogin
is enabled.
- X11UseLocalhost
-
Specifies whether
sshd
should bind the X11 forwarding server to the loopback address or to
the wildcard address. By default,
sshd
binds the forwarding server to the loopback address and sets the
hostname part of the
DISPLAY
environment variable to
``localhost''
This prevents remote hosts from connecting to the fake display.
However, some older X11 clients may not function with this
configuration.
X11UseLocalhost
may be set to
``no''
to specify that the forwarding server should be bound to the wildcard
address.
The argument must be
``yes''
or
``no''
The default is
``yes''
- XAuthLocation
-
Specifies the location of the
xauth(1)
program.
The default is
/usr/X11R6/bin/xauth
Time Formats
sshd
command-line arguments and configuration file options that specify time
may be expressed using a sequence of the form:
time [qualifier ]
where
time
is a positive integer value and
qualifier
is one of the following:
- <none>
-
seconds
- s | S
-
seconds
- m | M
-
minutes
- h | H
-
hours
- d | D
-
days
- w | W
-
weeks
Each member of the sequence is added together to calculate
the total time value.
Time format examples:
- 600
-
600 seconds (10 minutes)
- 10m
-
10 minutes
- 1h30m
-
1 hour 30 minutes (90 minutes)
LOGIN PROCESS
When a user successfully logs in,
sshd
does the following:
-
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
Sx FILES
section).
-
If the login is on a tty, records login time.
-
Checks
/etc/nologin
if it exists, prints contents and quits
(unless root).
-
Changes to run with normal user privileges.
-
Sets up basic environment.
-
Reads
$HOME/.ssh/environment
if it exists.
-
Changes to user's home directory.
-
If
$HOME/.ssh/rc
exists, runs it; else if
/etc/ssh/sshrc
exists, runs
it; otherwise runs xauth.
The
``rc''
files are given the X11
authentication protocol and cookie in standard input.
-
Runs user's shell or command.
AUTHORIZED_KEYS FILE FORMAT
$HOME/.ssh/authorized_keys
is the default file that lists the public keys that are
permitted for RSA authentication in protocol version 1
and for public key authentication (PubkeyAuthentication)
in protocol version 2.
AuthorizedKeysFile
may be used to specify an alternative file.
Each line of the file contains one
key (empty lines and lines starting with a
`#'
are ignored as
comments).
Each RSA public key consists of the following fields, separated by
spaces: options, bits, exponent, modulus, comment.
Each protocol version 2 public key consists of:
options, keytype, base64 encoded key, comment.
The options fields
are 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 for
protocol version 1; the
comment field is not used for anything (but may be convenient for the
user to identify the key).
For protocol version 2 the keytype is
``ssh-dss''
or
``ssh-rsa''
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
id_dsa.pub
or the
id_rsa.pub
file and edit it.
The options (if present) consist of comma-separated option
specifications.
No spaces are permitted, except within double quotes.
The following option specifications are supported (note
that option keywords are case-insensitive):
- 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 network 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 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 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 permits remote backups but nothing else.
Note that the client may specify TCP/IP and/or X11
forwarding unless they are explicitly prohibited.
Note that this option applies to shell, command or subsystem execution.
- 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.
This option is automatically disabled if
UseLogin
is enabled.
- no-port-forwarding
-
Forbids TCP/IP forwarding when this key is used for authentication.
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).
- 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
Multiple
permitopen
options may be applied separated by commas. No pattern matching is
performed on the specified hostnames, they must be literal domains or
addresses.
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
permitopen="10.2.1.55:80",permitopen="10.2.1.56:25" 1024 33 23...2323
SSH_KNOWN_HOSTS FILE FORMAT
The
/etc/ssh/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 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 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 RSA host key; they
can be obtained, e.g., from
/etc/ssh/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
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.
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
or by taking
/etc/ssh/ssh_host_key.pub
and adding the host names at the front.
Examples
closenet,...,130.233.208.41 1024 37 159...93 closenet.hut.fi
cvs.openbsd.org,199.185.137.3 ssh-rsa AAAA1234.....=
FILES
- /etc/ssh/sshd_config
-
Contains configuration data for
sshd
This file should be writable by root only, but it is recommended
(though not necessary) that it be world-readable.
- /etc/ssh/ssh_host_key, /etc/ssh/ssh_host_dsa_key, /etc/ssh/ssh_host_rsa_key
-
These three files contain the private parts of the host keys.
These files should only be owned by root, readable only by root, and not
accessible to others.
Note that
sshd
does not start if this file is group/world-accessible.
- /etc/ssh/ssh_host_key.pub, /etc/ssh/ssh_host_dsa_key.pub, /etc/ssh/ssh_host_rsa_key.pub
-
These three files contain the public parts of the host keys.
These files should be world-readable but writable only by
root.
Their contents should match the respective private parts.
These files are not
really used for anything; they are provided for the convenience of
the user so their contents can be copied to known hosts files.
These files are created using
ssh-keygen1.
- /etc/moduli
-
Contains Diffie-Hellman groups used for the "Diffie-Hellman Group Exchange".
- /var/run/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 content of this file is not sensitive; it can be world-readable.
- $HOME/.ssh/authorized_keys
-
Lists the public keys (RSA or DSA) 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 directory resides on an NFS
volume).
It is recommended that it not be accessible by others.
The format of this file is described above.
Users will place the contents of their
identity.pub
id_dsa.pub
and/or
id_rsa.pub
files into this file, as described in
ssh-keygen1.
- /etc/ssh/ssh_known_hosts and $HOME/.ssh/known_hosts
-
These files are consulted when using rhosts with 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.
These files should be writable only by root/the owner.
/etc/ssh/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.
- /etc/hosts.allow, /etc/hosts.deny
-
Access controls that should be enforced by tcp-wrappers are defined here.
Further details are described in
hosts_access5.
- $HOME/.rhosts
-
This file 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.
The same file is used by rlogind and rshd.
The file must
be writable only by the user; it is recommended that it not be
accessible by others.
If 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 simplest form, this file contains host names, one per line.
Users on
those hosts are permitted to log in without a password, provided they
have the same user name on both machines.
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).
Additionally, 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: - 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.
- $HOME/.ssh/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.
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 /bin/sh after reading 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 environment).
This must call
xauth(1)
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 environment.
This file will probably contain some initialization code followed by
something similar to:
if read proto cookie; then
echo add $DISPLAY $proto $cookie | xauth -q -
fi
If this file does not exist,
/etc/ssh/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/ssh/sshrc
-
Like
$HOME/.ssh/rc
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.
AUTHORS
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.
SEE ALSO
scp(1),
sftp(1),
ssh(1),
ssh-add1,
ssh-agent1,
ssh-keygen1,
login.conf5,
moduli(5),
sftp-server8
-
T. Ylonen
T. Kivinen
M. Saarinen
T. Rinne
S. Lehtinen
"SSH Protocol Architecture"
draft-ietf-secsh-architecture-09.txt
July 2001
work in progress material
-
M. Friedl
N. Provos
W. A. Simpson
"Diffie-Hellman Group Exchange for the SSH Transport Layer Protocol"
draft-ietf-secsh-dh-group-exchange-01.txt
April 2001
work in progress material
Index
- NAME
-
- SYNOPSIS
-
- DESCRIPTION
-
- SSH protocol version 1
-
- SSH protocol version 2
-
- Command execution and data forwarding
-
- CONFIGURATION FILE
-
- Time Formats
-
- LOGIN PROCESS
-
- AUTHORIZED_KEYS FILE FORMAT
-
- Examples
-
- SSH_KNOWN_HOSTS FILE FORMAT
-
- Examples
-
- FILES
-
- AUTHORS
-
- SEE ALSO
-
This document was created by
man2html,
using the manual pages.
Time: GMT, March 07, 2002