The OpenSSH SSH daemon supports SSH protocol 2 only. Each host has a host-specific key, used to identify the host. Whenever a client connects, the daemon responds with its public host key. The client compares the host key against its own database to verify that it has not changed. Forward secrecy 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. 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 (MAC).
Finally, the server and the client enter an authentication dialog. The client tries to authenticate itself using host-based authentication, public key authentication, challenge-response authentication, or password authentication.
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 connections, or forwarding the authentication agent connection over the secure channel.
After this, 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.
NAME
Ssh-keygen generates, manages and converts authentication keys for ssh (1). Ssh-keygen can create keys for use by SSH protocol version 2. The type of key to be generated is specified with the -t option. NAME sshd − secure shell daemon. SYNOPSIS sshd -diqQ46 -b bits -f configfile -g logingracetime -h hostkeyfile -k keygentime -p port -u len -V clientprotocolid. DESCRIPTION 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.
Ssh-agent(1)— An authentication agent that can store private keys ssh-add(1)— Tool which adds keys to in the above agent sftp(1)— FTP-like program that works over SSH1 and SSH2 protocol scp(1)— File copy program that acts like rcp. Endlessh: an SSH tarpit. Endlessh is an SSH tarpit that very slowly sends an endless, random SSH banner.It keeps SSH clients locked up for hours or even days at a time. The purpose is to put your real SSH server on another port and then let the script kiddies get stuck in this tarpit instead of bothering a real server.
sshd −secure shell daemon
SYNOPSIS
sshd[-diqQ46] [-bbits] [-fconfig_file] [-glogin_grace_time][-hhost_key_file] [-kkey_gen_time] [-pport] [-ulen] [-Vclient_protocol_id]
DESCRIPTION
The sshd(Secure Shell daemon) is the daemon program forssh(1). Together these programs replace rloginand rsh, and provide secure encrypted communicationsbetween two untrusted hosts over an insecure network. Theprograms are intended to be as easy to install and use aspossible.
sshd isthe daemon that listens for connections from clients. Itforks a new daemon for each incoming connection. The forkeddaemons handle key exchange, encryption, authentication,command execution, and data exchange.
Thisimplementation of sshd supports both SSH protocolversions 1 and 2 simultaneously. Because of securityweaknesses in the v1 protocol, it is recommended that sitesrun only v2, if possible. Support for v1 is provided to helpsites with existing ssh v1 clients and servers totransition to v2. Support for v1 might not be available in afuture release of Solaris.
sshdworks as described in the following subsections.
SSH ProtocolVersion 1
Each host has a host-specific RSA key (normally 1024 bits)used to identify the host. Additionally, when the daemonstarts, it generates a server RSA key (normally 768 bits).This key is normally regenerated every hour if it has beenused, and is never stored on disk.
Whenever aclient connects the daemon responds with its public host andserver keys. The client compares the RSA host key againstits own database to verify that it has not changed. Theclient then generates a 256-bit random number. It encryptsthis random number using both the host key and the serverkey, and sends the encrypted number to the server. Bothsides then use this random number as a session key which isused to encrypt all further communications in the session.The rest of the session is encrypted using a conventionalcipher, currently Blowfish or 3DES, with 3DES being used bydefault. The client selects the encryption algorithm to usefrom those offered by the server.
Man Ssh-copy-id
Next, theserver and the client enter an authentication dialog. Theclient tries to authenticate itself using .rhostsauthentication, .rhosts authentication combined withRSA host authentication, RSA challenge-responseauthentication, or password-based authentication.
Rhostsauthentication is normally disabled because it isfundamentally insecure, but can be enabled in the serverconfiguration file if desired. System security is notimproved unless rshd(1M), rlogind(1M),rexecd(1M), and rexd(1M) are disabled (thuscompletely disabling rlogin(1) and rsh(1) intothe machine).
SSH ProtocolVersion 2
Version 2 works similarly to version 1: Each host has ahost-specific DSA/RSA key. However, when the daemon starts,it does not generate a server key. Forward security isprovided through a Diffie-Hellman key agreement. This keyagreement results in a shared session key. The rest of thesession is encrypted using a symmetric cipher, currentlyBlowfish, 3DES, or AES. The client selects the encryptionalgorithm to use from those offered by the server.Additionally, session integrity is provided through acryptographic message authentication code (hmac-sha1or hmac-md5).
Protocolversion 2 provides a public key based user authenticationmethod (PubKeyAuthentication) and conventional passwordauthentication.
CommandExecution and Data Forwarding
If the client successfully authenticates itself, a dialogfor preparing the session is entered. At this time theclient can request things like allocating a pseudo-tty,forwarding X11 connections, forwarding TCP/IP connections,or forwarding the authentication agent connection over thesecure channel.
Finally, theclient either requests a shell or execution of a command.The sides then enter session mode. In this mode, either sidemay send data at any time, and such data is forwardedto/from the shell or command on the server side, and theuser terminal on the client side.
When the userprogram terminates and all forwarded X11 and otherconnections have been closed, the server sends command exitstatus to the client, and both sides exit.
sshd canbe configured using command-line options or theconfiguration files /etc/ssh/ssh/ssh_config and~/.ssh/config, both described inssh_config(4). Command-line options override valuesspecified in the configuration file.
sshdrereads its configuration file when it receives a hangupsignal, SIGHUP.
Host AccessControl
The sshd daemon uses TCP Wrappers to restrict accessto hosts. It uses the service name of sshd forhosts_access(). For more information on TCP Wrapperssee tcpd(1M) and hosts_access(3) man pages,which are part of the SUNWsfman package (they are notSunOS man pages). TCP wrappers binaries, includinglibwrap, are in SUNWtcpd, a required packagefor SUNWsshdu, the package containingsshd.
OPTIONS
The options forsshd are as follows:
-bbits
Specifies the number of bits inthe server key (the default is 768).
-d | Debug mode. The server sends verbose debug output to thesystem log, and does not put itself in the background. Theserver also will not fork and will only process oneconnection. This option is only intended for debugging forthe server. Multiple -d options increase thedebugging level. Maximum is 3. |
-fconfiguration_file
Specifies the name of theconfiguration file. The default is/etc/ssh/sshd_config. sshd refuses to start ifthere is no configuration file.
-glogin_grace_time
Gives the grace time forclients to authenticate themselves (the default is 300seconds). If the client fails to authenticate the userwithin this number of seconds, the server disconnects andexits. A value of zero indicates no limit.
-hhost_key_file
Specifies the file from whichthe host key is read (the default is/etc/ssh/ssh_host_key). This option must be given ifsshd is not run as root (as the normal host file isnormally not readable by anyone but root).
-i | Specifies that sshd is being run frominetd. sshd is normally not run frominetd because it needs to generate the server keybefore it can respond to the client, and this may take tensof seconds. Clients would have to wait too long if the keywas regenerated every time. However, with small key sizes(for example, 512) using sshd from inetd maybe reasonable. |
-kkey_gen_time
Specifies how often the serverkey is regenerated (the default is 3600 seconds, or onehour). The motivation for regenerating the key fairly oftenis that the key is not stored anywhere, and after about anhour, it becomes impossible to recover the key fordecrypting intercepted communications even if the machine iscracked into or physically seized. A value of zero indicatesthat the key will never be regenerated.
-pport
Specifies the port on which theserver listens for connections (the default is 22).
-q | Quiet mode. Nothing is sent to the system log. Normallythe beginning, authentication, and termination of eachconnection is logged. |
-ulen
Used to specify the size of thefield in the utmp structure that holds the remotehost name. If the resolved host name is longer thanlen, the dotted decimal value will be used instead.This allows hosts with very long host names that overflowthis field to still be uniquely identified. Specifying-u0 indicates that only dotted decimal addressesshould be put into the utmp file.
-4 | Forces sshd to use IPv4 addresses only. |
-6 | Forces sshd to use IPv6 addresses only. |
EXTENDED DESCRIPTION
authorized_keysFile Format
The $HOME/.ssh/authorized_keys file lists the publickeys that are permitted for RSA authentication. Each line ofthe file contains one key (empty lines and lines startingwith a hash mark [#] are ignored as comments). Eachline consists of the following fields, separated by spaces:options, bits, exponent, modulus, comment. The options fieldis optional; its presence is determined by whether the linestarts with a number or not (the option field never startswith a number). The bits, exponent, modulus and commentfields give the RSA key; the comment field is not used foranything (but may be convenient for the user to identify thekey).
Note that linesin this file are usually several hundred bytes long (becauseof the size of the RSA key modulus). You will find it veryinconvenient to type them in; instead, copy theidentity.pub file and edit it.
The options (ifpresent) consist of comma-separated option specifications.No spaces are permitted, except within double quotes. Thefollowing option specifications are supported:
from='pattern-list'
Specifies that in addition toRSA authentication, the canonical name of the remote hostmust be present in the comma-separated list of patterns(* and ? serve as wildcards). The list canalso contain patterns negated by prefixing them with!; if the canonical host name matches a negatedpattern, the key is not accepted. The purpose of this optionis to optionally increase security: RSA authentication byitself does not trust the network or name servers oranything (but the key); however, if somebody somehow stealsthe key, the key permits an intruder to log in from anywherein the world. This additional option makes using a stolenkey more difficult (name servers and/or routers would haveto be compromised in addition to just the key).
command='command'
Specifies that thecommand is executed whenever this key is used forauthentication. The command supplied by the user (if any) isignored. The command is run on a pty if theconnection requests a pty; otherwise it is runwithout a tty. A quote can be included in the commandby quoting it with a backslash. This option might be usefulto restrict certain RSA keys to perform only a specificoperation. An example might be a key that permits remotebackups but nothing else. Note that the client might specifyTCP/IP and/or X11 forwarding unless they are explicitlyprohibited.
environment='NAME=value'
Specifies that the stringNAME=value is to be added to the environmentwhen logging in using this key. Environment variables setthis way override other default environment values. Multipleoptions of this type are permitted.
no-port-forwarding
Forbids TCP/IP forwarding whenthis key is used for authentication. Any port forwardrequests by the client will return an error. This might beused, for example, in connection with the commandoption.
no-X11-forwarding
Forbids X11 forwarding whenthis key is used for authentication. Any X11 forwardrequests by the client will return an error.
no-agent-forwarding
Forbids authentication agentforwarding when this key is used for authentication.
no-pty
Prevents tty allocation(a request to allocate a pty will fail).
ssh_known_hostsFile Format
The /etc/ssh/ssh_known_hosts and$HOME/.ssh/known_hosts files contain host public keysfor all known hosts. The global file should be prepared bythe administrator (optional), and the per-user file ismaintained automatically: whenever the user connects from anunknown host its key is added to the per-user file.
Each line inthese files contains the following fields: hostnames, bits,exponent, modulus, comment. The fields are separated byspaces.
Hostnames is acomma-separated list of patterns (* and ? actas wildcards); each pattern in turn is matched against thecanonical host name (when authenticating a client) oragainst the user-supplied name (when authenticating aserver). A pattern can also be preceded by ! toindicate negation: if the host name matches a negatedpattern, it is not accepted (by that line) even if itmatched another pattern on the line.
Bits, exponent,and modulus are taken directly from the RSA host key; theycan be obtained, for example, from/etc/ssh/ssh_host_rsa_key.pub. The optional commentfield continues to the end of the line, and is not used.
Lines startingwith a hash mark (#) and empty lines are ignored ascomments.
When performinghost authentication, authentication is accepted if anymatching line has the proper key. It is thus permissible(but not recommended) to have several lines or differenthost keys for the same names. This will inevitably happenwhen short forms of host names from different domains areput in the file. It is possible that the files containconflicting information; authentication is accepted if validinformation can be found from either file.
Note that thelines in these files are typically hundreds of characterslong.You should definitely not type in the host keys byhand. Rather, generate them by a script or by taking/etc/ssh/ssh_host_rsa_key.pub and adding the hostnames at the front.
EXAMPLES
Example 1:authorized_key File Entries
The followingare examples of authorized_key file entries.
1024 3312121..312314325 ylo [AT] 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:ssh_known_hosts File Entries
The followingare examples of ssh_known_hosts file entries.
closenet,closenet.hut.fi,..,130.233.208.411024 37 159..93
closenet.hut.fi
EXIT STATUS
The followingexit values are returned:
0 | Successful completion. |
>0 | An error occurred. |
FILES
/etc/ssh/sshd_config
Ssh Command Flags
Contains configuration data forsshd. This file should be writable by root only, butit is recommended (though not necessary) that it beworld-readable.
/etc/ssh/ssh_host_key
Contains the private part ofthe host key. This file should only be owned by root,readable only by root, and not accessible to others. Notethat sshd does not start if this file isgroup/world-accessible.
/etc/ssh/ssh_host_key.pub
Contains the public part of thehost key. This file should be world-readable but writableonly by root. Its contents should match the private part.This file is not used for encryption; it is provided onlyfor the convenience of the user so its contents can becopied to known hosts files. These two files are createdusing ssh-keygen(1).
/var/run/sshd.pid
Contains the process ID of thesshd listening for connections. If there are severaldaemons running concurrently for different ports, thiscontains the pid of the one started last. The content ofthis file is not sensitive; it can be world-readable.
/etc/ssh/ssh_known_hostsand $HOME/.ssh/known_hosts
These files are consulted whenusing rhosts with RSA host authentication to checkthe public key of the host. The key must be listed in one ofthese files to be accepted. The client uses the same filesto verify that the remote host is the one it intended toconnect. These files should be writable only by root or theowner. /etc/ssh/ssh_known_hosts should beworld-readable, and $HOME/.ssh/known_hosts can butneed not be world-readable.
/etc/nologin
If this file exists,sshd refuses to let anyone except root log in. Thecontents of the file are displayed to anyone trying to login, and non-root connections are refused. The file should beworld-readable.
$HOME/.rhosts
This file containshost-username pairs, separated by a space, one per line. Thegiven user on the corresponding host is permitted to log inwithout password. The same file is used by rlogindand rshd. The file must be writable only by the user;it is recommended that it not be accessible by others. It isalso possible to use netgroups in the file. Eitherhost or user name may be of the form+@groupname to specify all hosts or all usersin the group.
$HOME/.shosts
For ssh, this file isexactly the same as for .rhosts. However, this fileis not used by rlogin and rshd, so using thispermits access using SSH only.
/etc/hosts.equiv
This file is used during.rhosts authentication. In its simplest form, thisfile contains host names, one per line. Users on these hostsare permitted to log in without a password, provided theyhave the same user name on both machines. The host name canalso be followed by a user name; such users are permitted tolog in as any user on this machine (except root).Additionally, the syntax +@group can be usedto specify netgroups. Negated entries start with a hyphen(-).
If the clienthost/user is successfully matched in this file, login isautomatically permitted, provided the client and server usernames are the same. Additionally, successful RSA hostauthentication is normally required. This file must bewritable only by root; it is recommended that it beworld-readable.
Warning: It isalmost never a good idea to use user names inhosts.equiv. Beware that it really means that thenamed user(s) can log in as anybody, which includesbin, daemon, adm, and other accountsthat own critical binaries and directories. For practicalpurposes, using a user name grants the user root access.Probably the only valid use for user names is in negativeentries. Note that this warning also applies torsh/rlogin.
/etc/ssh/shosts.equiv
This file is processed exactlyas /etc/hosts.equiv. However, this file might beuseful in environments that want to run bothrsh/rlogin and ssh.
Man Ssh Command
$HOME/.ssh/environment
This file is read into theenvironment at login (if it exists). It can contain onlyempty lines, comment lines (that start with #), andassignment lines of the form name=value. Thefile should be writable only by the user; it need not bereadable by anyone else.
$HOME/.ssh/rc
If this file exists, it is runwith /bin/sh after reading the environment files butbefore starting the user’s shell or command. If X11spoofing is in use, this will receive the 'protocookie' pair in standard input (and DISPLAYin environment). This must call xauth(1) in thatcase.
The primarypurpose of $HOME/.ssh/rc is to run any initializationroutines that might be needed before the user’s homedirectory becomes accessible; AFS is a particular example ofsuch an environment.
This file willprobably contain some initialization code followed bysomething similar to:
if read protocookie;
then echo add $DISPLAY $proto $cookie | xauth -q -;
fi
If this filedoes not exist, /etc/ssh/sshrc is run, and if thatdoes 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
Similar to$HOME/.ssh/rc. This can be used to specifymachine-specific login-time initializations globally. Thisfile should be writable only by root, and should beworld-readable.
ATTRIBUTES
Seeattributes(5) for descriptions of the followingattributes:
SEE ALSO
scp(1),ssh(1), ssh-add(1), ssh-agent(1),ssh-keygen(1), sftp-server(1M),sshd(1M), sshd_config(4),attributes(5)
To view licenseterms, attribution, and copyright for OpenSSH, the defaultpath is /var/sadm/pkg/SUNWsshdr/install/copyright. Ifthe Solaris operating environment has been installedanywhere other than the default, modify the given path toaccess the file at the installed location. Powerbook g4 os download.
AUTHORS
OpenSSH is aderivative of the original and free ssh 1.2.12release by Tatu Ylonen. Aaron Campbell, Bob Beck, MarkusFriedl, Niels Provos, Theo de Raadt and Dug Song removedmany bugs, added newer features and created Open SSH. MarkusFriedl contributed the support for SSH protocol versions 1.4and 2.0.
COMMENTS