Партнёры:
Хостинг:
sshd - secure shell daemon
sshd [-deiqtD46] [-b bits] [-f config_file]
[-g login_grace_time] [-h host_key_file]
[-k key_gen_time] [-p port] [-V client_protocol_id]
The sshd (Secure Shell 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 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 versions 1 and 2 simultaneously. Because of security weaknesses in the v1 protocol, sites should run only v2, if possible. In the default configuration, only protocol v2 is enabled for the server. To enable v1 and v2 simultaneously, see the instructions in sshd_config(4).
Support for v1 is provided to help sites with existing ssh v1 clients and servers to transition to v2. v1 might not be supported in a future release.
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(1M), rlogind(1M), rexecd(1M), and rexd(1M) are disabled (thus completely disabling rlogin(1) and rsh(1) into the machine).
Version 2 works similarly to version 1: Each host has a host-specific DSA/RSA key. 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, or 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 authentication method (PubKeyAuthentication) GSS-API based user authentication, conventional password authentication, and a generic prompt/reply protocol for password-based authentication.
If the client successfully authenticates itself, a dialog for preparing the session is entered. At this time the client can 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 on 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 the configuration file /etc/ssh/ssh_config, described in ssh_config(4). 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, that is, /usr/lib/ssh/sshd.
The sshd daemon uses TCP Wrappers to restrict access to hosts. It uses the service name of sshd for hosts_access(). For more information on TCP Wrappers see tcpd(1M) and hosts_access(3) man pages, which are part of the SUNWsfman package (they are not SunOS man pages). TCP wrappers binaries, including libwrap, are in SUNWtcpd, a required package for SUNWsshdu, the package containing sshd.
The options for sshd are as follows:
-b bits
-d
-e
-f configuration_file
-g login_grace_time
-h host_key_file
-i
-k key_gen_time
-o option
-p port
-q
-t
-D
-4
-6
The $HOME/.ssh/authorized_keys file lists the public keys that are permitted for RSA authentication in protocol version 1 and for public key authentication (PubkeyAuthentication) in protocol version 2. The AuthorizedKeysFile configuration option can be used to specify an alternative file.
Each line of the file contains one key (empty lines and lines starting with a hash mark [#] are ignored as comments).
For each RSA key for protocol version 1, the file consists of the following space-separated fields:
options bits exponent modulus comment
For the public key for protocol version 2, the file consists of the following space-separated fields:
options key-type base64-encoding-key comment
For protocol version 2, key-type is one of ssh-rsa or ssh-dsa.
The options field is optional; its presence is determined by whether the line starts with a number. (The option field never starts with a number.) The bits, exponent, and modulus fields give the RSA key; the comment field is a convenient place for you to identify the key.
Lines in this file are usually several hundred bytes long (because of the size of the key modulus). You will find it very inconvenient to type them in; instead, copy the public key file and edit it.
Permissions of this file must be set so that it is not world or group writable. See the StrictModes option of sshd_config(4).
The options (if present) consist of comma-separated option specifications. No spaces are permitted, except within double quotes. The following option specifications are supported:
from="pattern-list"
The purpose of this option is to give you the option of increasing security: public key authentication by itself does not trust the network or name servers or anything but the key. However, if someone manages to steal the key, possession of the key would permit the intruder to log in from anywhere in the world. This option makes using a stolen key more difficult, because name servers and routers would have to be compromised, in addition to just the key.
command="command"
environment="NAME=value"
no-port-forwarding
no-X11-forwarding
no-agent-forwarding
no-pty
permitopen="host:port"
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.
For the RSA key for protocol version 1, these files consist of the following space-separated fields:
hostnames bits exponent modulus comment
For the public key for protocol version 2, these files consist of the following space-separated fields:
hostnames key-type base64-encoding-key comment
For protocol version 2, key-type is one of ssh-rsa or ssh-dsa.
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 can 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.
Alternately, hostnames can be stored in a hashed form, which hides host names and addresses should the file's contents be disclosed. Hashed hostnames start with a vertical bar (|) character. Only one hashed hostname can appear on a single line and none of the above negation or wildcard operators may be applied.
Bits, exponent, and modulus are taken directly from the RSA host key; they can be obtained, for example, from /etc/ssh/ssh_host_rsa_key.pub. The optional comment field continues to the end of the line, and is not used.
Lines starting with a hash mark (#) 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.
The lines in these files are typically hundreds of characters long. You should definitely not type in the host keys by hand. Rather, generate them by a script or by taking /etc/ssh/ssh_host_rsa_key.pub and adding the host names at the front.
sshd sets the following environment variables for commands executed by ssh users:
DISPLAY
HOME
LANG, LC_ALL, LC_COLLATE, LC_CTYPE, LC_MESSAGES, LC_MONETARY, LC_NUMERIC, LC_TIME
Following initial key exchange, each of the variables can be overriden in the following sequence:
LOGNAME
SSH_AUTH_SOCK
SSH_CONNECTION
SSH_CLIENT
SSH_TTY
TZ
HZ
SHELL
PATH
USER
Additionally, sshd reads $HOME/.ssh/environment and adds lines of the format VARNAME=value to the environment.
In the following examples, certain lines might wrap due to line length limits in your display. You should nevertheless consider the wrapped line as a single line.
Example 1 authorized_key File Entries
The following are examples of authorized_key file entries for protocol 1:
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
Example 2 authorized_key File Entries for Protocol 2
The following are examples of authorized_key file entries for protocol 2:
ssh-rsa AAAAB3NzaC1y.....EU88ovYKg4GfclWGCFYTuw8= ylo@foo.bar from="*.niksula.hut.fi" ssh-rsa AAAAB3NzaC...uw8= ylo@niksula command="dump /home",no-pty,no-port-forwarding ssh-rsa AA..8= backup.hut.fi
Example 3 ssh_known_hosts File Entries for Protocol 1
The following are examples of ssh_known_hosts file entries for protocol 1:
closenet,closenet.hut.fi,...,130.233.208.41 1024 37 159...93 closenet.hut.fi
Example 4 ssh_known_hosts File Entries for Protocol 2
The following are examples of ssh_known_hosts file entries for protocol 2:
closenet,closenet.hut.fi,...,130.233.208.41 ssh-rsa AA..8= closenet.hut.fi
The following exit values are returned:
0
>0
/etc/default/login
The following parameters affect environment variables (see login(1) and descriptions of these variables, above):
Finally, two /etc/default/login parameters affect the maximum allowed login attempts per-connection using interactive user authentication methods (for example, keyboard-interactive but not publickey), as per login(1):
/etc/ssh/sshd_config
/etc/ssh/ssh_host_key
/etc/ssh/ssh_host_dsa_key
/etc/ssh/ssh_host_rsa_key
/etc/ssh/ssh_host_key.pub
/etc/ssh/ssh_host_dsa_key.pub
/etc/ssh/ssh_host_rsa_key.pub
/var/run/sshd.pid
/etc/ssh/ssh_known_hosts and $HOME/.ssh/known_hosts
/etc/nologin
$HOME/.ssh/authorized_keys
$HOME/.rhosts
$HOME/.shosts
/etc/hosts.equiv
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. For practical purposes, using a user name grants the user root access. Probably the only valid use for user names is in negative entries. This warning also applies to rsh/rlogin.
/etc/ssh/moduli
/etc/ssh/shosts.equiv
$HOME/.ssh/environment
$HOME/.ssh/rc
The primary purpose of $HOME/.ssh/rc is to run any initialization routines that might be needed before the user's home directory becomes accessible; AFS is a particular example of such an environment. If this file exists, it is run with /bin/sh after reading the environment files, but before starting the user's shell or command. It must not produce any output on stdout; stderr must be used instead. If X11 forwarding is in use, it will receive the proto cookie pair in its standard input and DISPLAY in its environment. The script must call xauth because sshd will not run xauth automatically to add X11 cookies.
This file will probably contain some initialization code followed by something similar to:
if read proto cookie && [ -n "$DISPLAY" ] then if [ `echo $DISPLAY | cut -c1-10` = 'localhost:' ] then # X11UseLocalhost=yes echo add unix:`echo $DISPLAY | cut -c11-` $proto $cookie else # X11UseLocalhost=no echo add $DISPLAY $proto $cookie fi | xauth -q - fi
If this file does not exist, /etc/ssh/sshrc is run, and if that does not exist, xauth is used to store the cookie. $HOME/.ssh/rc should be writable only by the user, and need not be readable by anyone else.
/etc/ssh/sshrc
sshd supports the use of several user authentication mechanisms: a public key system where keys are associated with users (through users' authorized_keys files), a public key system where keys are associated with hosts (see the HostbasedAuthentication configuration parameter), a GSS-API based method (see the GssAuthentication and GssKeyEx configuration parameters) and three initial authentication methods: none, password, and a generic prompt/reply protocol, keyboard-interactive.
sshd negotiates the use of the GSS-API with clients only if it has a GSS-API acceptor credential for the "host" service. This means that, for GSS-API based authentication, the server must have a Kerberos V keytab entry (see below) or the equivalent for any other GSS-API mechanism that might be installed.
In order for Kerberos authentication to work, a host/<FQDN> Kerberos principal must exist for each Fully Qualified Domain Name associated with the in.sshd server. Each of these host/<FQDN> principals must have a keytab entry in the /etc/krb5/krb5.keytab file on the in.sshd server. An example principal might be:
host/bigmachine.eng.example.com
See kadmin(1M) or gkadmin(1M) for instructions on adding a principal to a krb5.keytab file. See for a discussion of Kerberos authentication.
GSS-API authorization is covered in gss_auth_rules(5).
sshd uses pam(3PAM) for the three initial authentication methods as well as for account management, session management, and password management for all authentication methods.
Specifically, sshd calls pam_authenticate() for the "none," "password" and "keyboard-interactive" SSHv2 userauth types, as well as for for the null and password authentication methods for SSHv1. Other SSHv2 authentication methods do not call pam_authenticate(). pam_acct_mgmt() is called for each authentication method that succeeds.
pam_setcred() and pam_open_session() are called when authentication succeeds and pam_close_session() is called when connections are closed.
pam_open_session() and pam_close_session() are also called when SSHv2 channels with ptys are opened and closed.
Each SSHv2 userauth type has its own PAM service name:
| ||||||||||||||||||||||||
For SSHv1, sshd-v1 is always used.
If pam_acct_mgmt() returns PAM_NEW_AUTHTOK_REQD (indicating that the user's authentication tokens have expired), then sshd forces the use of "keyboard-interactive" userauth, if version 2 of the protocol is in use. The "keyboard-interactive" userauth will call pam_chauthtok() if pam_acct_mgmt() once again returns PAM_NEW_AUTHTOK_REQD. By this means, administrators are able to control what authentication methods are allowed for SSHv2 on a per-user basis.
To establish host-based authentication, you must perform the following steps:
These steps are expanded in the following paragraphs.
HostbasedAuthentication yes
See ssh_config(4) and ssh-keysign(1M).
HostbasedAuthentication yes
If per-user .shost files are to be allowed (see last step), in the same file, you must have:
IgnoreRhosts no
See sshd_config(4) for a description of these keywords.
For the vast majority of network environments, .shosts is preferred over .rhosts.
See attributes(5) for descriptions of the following attributes:
| |||||||||
The interface stability of /etc/ssh/moduli is Private.
login(1), scp(1), ssh(1), ssh-add(1), ssh-agent(1), ssh-keygen(1), svcs(1), gkadmin(1M), kadmin(1M), sftp-server(1M), ssh-keysign(1M), svcadm(1M), pam(3PAM), rhosts(4), ssh_config(4), sshd_config(4), attributes(5), gss_auth_rules(5), kerberos(5), pam_roles(5), smf(5)
The sshd service is managed by the service management facility, smf(5), under the service identifier:
svc:/network/ssh:default
Administrative actions on this service, such as enabling, disabling, or requesting restart, can be performed using svcadm(1M). The service's status can be queried using the svcs(1) command.
sshd always sets PAM_RHOST and sets PAM_AUSER in the case of host-based userauth. This behavior allows for remote logins to roles using host-based authentication. See pam_roles(5).
|
Закладки на сайте Проследить за страницей |
Created 1996-2024 by Maxim Chirkov Добавить, Поддержать, Вебмастеру |