From 5d3573ef7a109ee70416fe94db098fe6a769a798 Mon Sep 17 00:00:00 2001 From: SkyperTHC Date: Tue, 3 Mar 2026 06:28:55 +0000 Subject: packetstorm sync --- other/openssh-reverse/ssh.0 | 811 ++++++++++++++++++++++++++++++++++++++++++++ 1 file changed, 811 insertions(+) create mode 100644 other/openssh-reverse/ssh.0 (limited to 'other/openssh-reverse/ssh.0') diff --git a/other/openssh-reverse/ssh.0 b/other/openssh-reverse/ssh.0 new file mode 100644 index 0000000..b62d1db --- /dev/null +++ b/other/openssh-reverse/ssh.0 @@ -0,0 +1,811 @@ + +SSH(1) System Reference Manual SSH(1) + +NAME + ssh - OpenSSH secure shell client (remote login program) + +SYNOPSIS + ssh [-l login_name] [hostname | user@hostname] [command] + + ssh [-afgknqtvxACNPTX246] [-c cipher_spec] [-e escape_char] [-i + identity_file] [-l login_name] [-o option] [-p port] [-L + port:host:hostport] [-R port:host:hostport] [hostname | + user@hostname] [command] + +DESCRIPTION + ssh (Secure Shell) is a program for logging into a remote machine and for + executing commands on a remote machine. It is intended to replace rlogin + and rsh, and provide secure encrypted communications between two untrust- + ed hosts over an insecure network. X11 connections and arbitrary TCP/IP + ports can also be forwarded over the secure channel. + + ssh connects and logs into the specified hostname. The user must prove + his/her identity to the remote machine using one of several methods de- + pending on the protocol version used: + + SSH protocol version 1 + + First, if the machine the user logs in from is listed in /etc/hosts.equiv + or /etc/shosts.equiv on the remote machine, and the user names are the + same on both sides, the user is immediately permitted to log in. Second, + if .rhosts or .shosts exists in the user's home directory on the remote + machine and contains a line containing the name of the client machine and + the name of the user on that machine, the user is permitted to log in. + This form of authentication alone is normally not allowed by the server + because it is not secure. + + The second (and primary) authentication method is the rhosts or + hosts.equiv method combined with RSA-based host authentication. It means + that if the login would be permitted by $HOME/.rhosts, $HOME/.shosts, + /etc/hosts.equiv, or /etc/shosts.equiv, and if additionally the server + can verify the client's host key (see /etc/ssh_known_hosts and + $HOME/.ssh/known_hosts in the FILES section), only then login is permit- + ted. This authentication method closes security holes due to IP spoof- + ing, DNS spoofing and routing spoofing. [Note to the administrator: + /etc/hosts.equiv, $HOME/.rhosts, and the rlogin/rsh protocol in general, + are inherently insecure and should be disabled if security is desired.] + + As a third authentication method, ssh supports RSA based authentication. + The scheme is based on public-key cryptography: there are cryptosystems + where encryption and decryption are done using separate keys, and it is + not possible to derive the decryption key from the encryption key. RSA + is one such system. The idea is that each user creates a public/private + key pair for authentication purposes. The server knows the public key, + and only the user knows the private key. The file + $HOME/.ssh/authorized_keys lists the public keys that are permitted for + logging in. When the user logs in, the ssh program tells the server + which key pair it would like to use for authentication. The server + checks if this key is permitted, and if so, sends the user (actually the + ssh program running on behalf of the user) a challenge, a random number, + encrypted by the user's public key. The challenge can only be decrypted + using the proper private key. The user's client then decrypts the chal- + lenge using the private key, proving that he/she knows the private key + but without disclosing it to the server. + + + ssh implements the RSA authentication protocol automatically. The user + creates his/her RSA key pair by running ssh-keygen(1). This stores the + private key in $HOME/.ssh/identity and the public key in + $HOME/.ssh/identity.pub in the user's home directory. The user should + then copy the identity.pub to $HOME/.ssh/authorized_keys in his/her home + directory on the remote machine (the authorized_keys file corresponds to + the conventional $HOME/.rhosts file, and has one key per line, though the + lines can be very long). After this, the user can log in without giving + the password. RSA authentication is much more secure than rhosts authen- + tication. + + The most convenient way to use RSA authentication may be with an authen- + tication agent. See ssh-agent(1) for more information. + + If other authentication methods fail, ssh prompts the user for a pass- + word. The password is sent to the remote host for checking; however, + since all communications are encrypted, the password cannot be seen by + someone listening on the network. + + SSH protocol version 2 + + When a user connects using the protocol version 2 different authentica- + tion methods are available: At first, the client attempts to authenticate + using the public key method. If this method fails password authentica- + tion is tried. + + The public key method is similar to RSA authentication described in the + previous section except that the DSA algorithm is used instead of the + patented RSA algorithm. The client uses his private DSA key + $HOME/.ssh/id_dsa to sign the session identifier and sends the result to + the server. The server checks whether the matching public key is listed + in $HOME/.ssh/authorized_keys2 and grants access if both the key is found + and the signature is correct. The session identifier is derived from a + shared Diffie-Hellman value and is only known to the client and the serv- + er. + + If public key authentication fails or is not available a password can be + sent encrypted to the remote host for proving the user's identity. This + protocol 2 implementation does not yet support Kerberos or S/Key authen- + tication. + + Protocol 2 provides additional mechanisms for confidentiality (the traf- + fic is encrypted using 3DES, Blowfish, CAST128 or Arcfour) and integrity + (hmac-sha1, hmac-md5). Note that protocol 1 lacks a strong mechanism for + ensuring the integrity of the connection. + + Login session and remote execution + + When the user's identity has been accepted by the server, the server ei- + ther executes the given command, or logs into the machine and gives the + user a normal shell on the remote machine. All communication with the + remote command or shell will be automatically encrypted. + + If a pseudo-terminal has been allocated (normal login session), the user + can disconnect with ~., and suspend ssh with ~^Z. All forwarded connec- + tions can be listed with ~# and if the session blocks waiting for for- + warded X11 or TCP/IP connections to terminate, it can be backgrounded + with ~& (this should not be used while the user shell is active, as it + can cause the shell to hang). All available escapes can be listed with + ~?. + + A single tilde character can be sent as ~~ (or by following the tilde by + a character other than those described above). The escape character must + always follow a newline to be interpreted as special. The escape charac- + ter can be changed in configuration files or on the command line. + + + If no pseudo tty has been allocated, the session is transparent and can + be used to reliably transfer binary data. On most systems, setting the + escape character to ``none'' will also make the session transparent even + if a tty is used. + + The session terminates when the command or shell in on the remote machine + exists and all X11 and TCP/IP connections have been closed. The exit + status of the remote program is returned as the exit status of ssh. + + X11 and TCP forwarding + + If the user is using X11 (the DISPLAY environment variable is set), the + connection to the X11 display is automatically forwarded to the remote + side in such a way that any X11 programs started from the shell (or com- + mand) will go through the encrypted channel, and the connection to the + real X server will be made from the local machine. The user should not + manually set DISPLAY. Forwarding of X11 connections can be configured on + the command line or in configuration files. + + The DISPLAY value set by ssh will point to the server machine, but with a + display number greater than zero. This is normal, and happens because + ssh creates a ``proxy'' X server on the server machine for forwarding the + connections over the encrypted channel. + + ssh will also automatically set up Xauthority data on the server machine. + For this purpose, it will generate a random authorization cookie, store + it in Xauthority on the server, and verify that any forwarded connections + carry this cookie and replace it by the real cookie when the connection + is opened. The real authentication cookie is never sent to the server + machine (and no cookies are sent in the plain). + + If the user is using an authentication agent, the connection to the agent + is automatically forwarded to the remote side unless disabled on command + line or in a configuration file. + + Forwarding of arbitrary TCP/IP connections over the secure channel can be + specified either on command line or in a configuration file. One possi- + ble application of TCP/IP forwarding is a secure connection to an elec- + tronic purse; another is going trough firewalls. + + Server authentication + + ssh automatically maintains and checks a database containing identifica- + tions for all hosts it has ever been used with. RSA host keys are stored + in $HOME/.ssh/known_hosts and DSA host keys are stored in + $HOME/.ssh/known_hosts2 in the user's home directory. Additionally, the + files /etc/ssh_known_hosts and /etc/ssh_known_hosts2 are automatically + checked for known hosts. Any new hosts are automatically added to the + user's file. If a host's identification ever changes, ssh warns about + this and disables password authentication to prevent a trojan horse from + getting the user's password. Another purpose of this mechanism is to + prevent man-in-the-middle attacks which could otherwise be used to cir- + cumvent the encryption. The StrictHostKeyChecking option (see below) can + be used to prevent logins to machines whose host key is not known or has + changed. + +OPTIONS + -a Disables forwarding of the authentication agent connection. + + -A Enables forwarding of the authentication agent connection. This + can also be specified on a per-host basis in a configuration + file. + + -c blowfish|3des + Selects the cipher to use for encrypting the session. 3des is + used by default. It is believed to be secure. 3des (triple-des) + is an encrypt-decrypt-encrypt triple with three different keys. + It is presumably more secure than the des cipher which is no + longer supported in ssh. blowfish is a fast block cipher, it ap- + pears very secure and is much faster than 3des. + + -c 3des-cbc,blowfish-cbc,arcfour,cast128-cbc + Additionally, for protocol version 2 a comma-separated list of + ciphers can be specified in order of preference. Protocol version + 2 supports 3DES, Blowfish and CAST128 in CBC mode and Arcfour. + + -e ch|^ch|none + Sets the escape character for sessions with a pty (default: `~'). + The escape character is only recognized at the beginning of a + line. The escape character followed by a dot (`.') closes the + connection, followed by control-Z suspends the connection, and + followed by itself sends the escape character once. Setting the + character to ``none'' disables any escapes and makes the session + fully transparent. + + -f Requests ssh to go to background just before command execution. + This is useful if ssh is going to ask for passwords or passphras- + es, but the user wants it in the background. This implies -n. + The recommended way to start X11 programs at a remote site is + with something like ssh -f host xterm. + + -g Allows remote hosts to connect to local forwarded ports. + + -i identity_file + Selects the file from which the identity (private key) for RSA + authentication is read. Default is $HOME/.ssh/identity in the + user's home directory. Identity files may also be specified on a + per-host basis in the configuration file. It is possible to have + multiple -i options (and multiple identities specified in config- + uration files). + + -k Disables forwarding of Kerberos tickets and AFS tokens. This may + also be specified on a per-host basis in the configuration file. + + -l login_name + Specifies the user to log in as on the remote machine. This also + may be specified on a per-host basis in the configuration file. + + -n Redirects stdin from /dev/null (actually, prevents reading from + stdin). This must be used when ssh is run in the background. A + common trick is to use this to run X11 programs on a remote ma- + chine. For example, ssh -n shadows.cs.hut.fi emacs & will start + an emacs on shadows.cs.hut.fi, and the X11 connection will be au- + tomatically forwarded over an encrypted channel. The ssh program + will be put in the background. (This does not work if ssh needs + to ask for a password or passphrase; see also the -f option.) + + -N Do not execute a remote command. This is usefull if you just + want to forward ports (protocol version 2 only). + + -o option + Can be used to give options in the format used in the config + file. This is useful for specifying options for which there is + no separate command-line flag. The option has the same format as + a line in the configuration file. + + -p port + Port to connect to on the remote host. This can be specified on + a per-host basis in the configuration file. + + -P Use a non-privileged port for outgoing connections. This can be + used if your firewall does not permit connections from privileged + ports. Note that this option turns off RhostsAuthentication and + RhostsRSAAuthentication. + + -q Quiet mode. Causes all warning and diagnostic messages to be + suppressed. Only fatal errors are displayed. + + -t Force pseudo-tty allocation. This can be used to execute arbi- + trary screen-based programs on a remote machine, which can be + very useful, e.g., when implementing menu services. + + -T Disable pseudo-tty allocation (protocol version 2 only). + + -v Verbose mode. Causes ssh to print debugging messages about its + progress. This is helpful in debugging connection, authentica- + tion, and configuration problems. The verbose mode is also used + to display skey(1) challenges, if the user entered "s/key" as + password. + + -x Disables X11 forwarding. + + -X Enables X11 forwarding. This can also be specified on a per-host + basis in a configuration file. + + -C Requests compression of all data (including stdin, stdout, + stderr, and data for forwarded X11 and TCP/IP connections). The + compression algorithm is the same used by gzip(1), and the + ``level'' can be controlled by the CompressionLevel option (see + below). Compression is desirable on modem lines and other slow + connections, but will only slow down things on fast networks. + The default value can be set on a host-by-host basis in the con- + figuration files; see the Compress option below. + + -L port:host:hostport + Specifies that the given port on the local (client) host is to be + forwarded to the given host and port on the remote side. This + works by allocating a socket to listen to port on the local side, + and whenever a connection is made to this port, the connection is + forwarded over the secure channel, and a connection is made to + host port hostport from the remote machine. Port forwardings can + also be specified in the configuration file. Only root can for- + ward privileged ports. IPv6 addresses can be specified with an + alternative syntax: port/host/hostport + + -R port:host:hostport + Specifies that the given port on the remote (server) host is to + be forwarded to the given host and port on the local side. This + works by allocating a socket to listen to port on the remote + side, and whenever a connection is made to this port, the connec- + tion is forwarded over the secure channel, and a connection is + made to host port hostport from the local machine. Port forward- + ings can also be specified in the configuration file. Privileged + ports can be forwarded only when logging in as root on the remote + machine. + + -2 Forces ssh to try protocol version 2 only. + + -4 Forces ssh to use IPv4 addresses only. + + -6 Forces ssh to use IPv6 addresses only. + +CONFIGURATION FILES + ssh obtains configuration data from the following sources (in this or- + der): command line options, user's configuration file + ($HOME/.ssh/config), and system-wide configuration file + (/etc/ssh_config). For each parameter, the first obtained value will be + used. The configuration files contain sections bracketed by ``Host'' + specifications, and that section is only applied for hosts that match one + of the patterns given in the specification. The matched host name is the + one given on the command line. + + Since the first obtained value for each parameter is used, more host-spe- + cific declarations should be given near the beginning of the file, and + general defaults at the end. + + The configuration file has the following format: + + Empty lines and lines starting with `#' are comments. + + Otherwise a line is of the format ``keyword arguments''. The possible + keywords and their meanings are as follows (note that the configuration + files are case-sensitive): + + Host Restricts the following declarations (up to the next Host key- + word) to be only for those hosts that match one of the patterns + given after the keyword. `*' and `?' can be used as wildcards in + the patterns. A single `*' as a pattern can be used to provide + global defaults for all hosts. The host is the hostname argument + given on the command line (i.e., the name is not converted to a + canonicalized host name before matching). + + AFSTokenPassing + Specifies whether to pass AFS tokens to remote host. The argu- + ment to this keyword must be ``yes'' or ``no''. + + BatchMode + If set to ``yes'', passphrase/password querying will be disabled. + This option is useful in scripts and other batch jobs where you + have no user to supply the password. The argument must be + ``yes'' or ``no''. + + CheckHostIP + If this flag is set to ``yes'', ssh will additionally check the + host ip address in the known_hosts file. This allows ssh to de- + tect if a host key changed due to DNS spoofing. If the option is + set to ``no'', the check will not be executed. + + Cipher Specifies the cipher to use for encrypting the session. Current- + ly, ``blowfish'', and ``3des'' are supported. The default is + ``3des''. + + Ciphers + Specifies the ciphers allowed for protocol version 2 in order of + preference. Multiple ciphers must be comma-separated. The de- + fault is ``3des-cbc,blowfish-cbc,arcfour,cast128-cbc''. + + Compression + Specifies whether to use compression. The argument must be + ``yes'' or ``no''. + + CompressionLevel + Specifies the compression level to use if compression is enable. + The argument must be an integer from 1 (fast) to 9 (slow, best). + The default level is 6, which is good for most applications. The + meaning of the values is the same as in gzip(1). + + ConnectionAttempts + Specifies the number of tries (one per second) to make before + falling back to rsh or exiting. The argument must be an integer. + This may be useful in scripts if the connection sometimes fails. + + DSAAuthentication + Specifies whether to try DSA authentication. The argument to + this keyword must be ``yes'' or ``no''. DSA authentication will + only be attempted if a DSA identity file exists. Note that this + option applies to protocol version 2 only. + + EscapeChar + Sets the escape character (default: `~'). The escape character + can also be set on the command line. The argument should be a + single character, `^' followed by a letter, or ``none'' to dis- + able the escape character entirely (making the connection trans- + parent for binary data). + + FallBackToRsh + Specifies that if connecting via ssh fails due to a connection + refused error (there is no sshd(8) listening on the remote host), + rsh(1) should automatically be used instead (after a suitable + warning about the session being unencrypted). The argument must + be ``yes'' or ``no''. + + ForwardAgent + Specifies whether the connection to the authentication agent (if + any) will be forwarded to the remote machine. The argument must + be ``yes'' or ``no''. The default is ``no''. + + ForwardX11 + Specifies whether X11 connections will be automatically redirect- + ed over the secure channel and DISPLAY set. The argument must be + ``yes'' or ``no''. The default is ``no''. + + GatewayPorts + Specifies whether remote hosts are allowed to connect to local + forwarded ports. The argument must be ``yes'' or ``no''. The de- + fault is ``no''. + + GlobalKnownHostsFile + Specifies a file to use instead of /etc/ssh_known_hosts. + + HostName + Specifies the real host name to log into. This can be used to + specify nicknames or abbreviations for hosts. Default is the + name given on the command line. Numeric IP addresses are also + permitted (both on the command line and in HostName specifica- + tions). + + IdentityFile + Specifies the file from which the user's RSA authentication iden- + tity is read (default $HOME/.ssh/identity in the user's home di- + rectory). Additionally, any identities represented by the au- + thentication agent will be used for authentication. The file + name may use the tilde syntax to refer to a user's home directo- + ry. It is possible to have multiple identity files specified in + configuration files; all these identities will be tried in se- + quence. + + IdentityFile2 + Specifies the file from which the user's DSA authentication iden- + tity is read (default $HOME/.ssh/id_dsa in the user's home direc- + tory). The file name may use the tilde syntax to refer to a us- + er's home directory. It is possible to have multiple identity + files specified in configuration files; all these identities will + be tried in sequence. + + 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 tem- + porarily, and some people find it annoying. + + The default is ``yes'' (to send keepalives), and the client will + notice if the network goes down or the remote host dies. This is + important in scripts, and many users want it too. + + To disable keepalives, the value should be set to ``no'' in both + the server and the client configuration files. + + KerberosAuthentication + Specifies whether Kerberos authentication will be used. The ar- + gument to this keyword must be ``yes'' or ``no''. + + KerberosTgtPassing + Specifies whether a Kerberos TGT will be forwarded to the server. + This will only work if the Kerberos server is actually an AFS + kaserver. The argument to this keyword must be ``yes'' or + ``no''. + + LocalForward + Specifies that a TCP/IP port on the local machine be forwarded + over the secure channel to given host:port from the remote ma- + chine. The first argument must be a port number, and the second + must be host:port. Multiple forwardings may be specified, and + additional forwardings can be given on the command line. Only + the superuser can forward privileged ports. + + LogLevel + Gives the verbosity level that is used when logging messages from + ssh. The possible values are: QUIET, FATAL, ERROR, INFO, VERBOSE + and DEBUG. The default is INFO. + + NumberOfPasswordPrompts + Specifies the number of password prompts before giving up. The + argument to this keyword must be an integer. Default is 3. + + PasswordAuthentication + Specifies whether to use password authentication. The argument + to this keyword must be ``yes'' or ``no''. Note that this option + applies to both protocol version 1 and 2. + + Port Specifies the port number to connect on the remote host. Default + is 22. + + Protocol + Specifies the protocol versions ssh should support in order of + preference. The possible values are ``1'' and ``2''. Multiple + versions must be comma-separated. The default is ``1,2''. This + means that ssh tries version 1 and falls back to version 2 if + version 1 is not available. + + ProxyCommand + Specifies the command to use to connect to the server. The com- + mand string extends to the end of the line, and is executed with + /bin/sh. In the command string, `%h' will be substituted by the + host name to connect and `%p' by the port. The command can be + basically anything, and should read from its standard input and + write to its standard output. It should eventually connect an + sshd(8) server running on some machine, or execute sshd -i some- + where. Host key management will be done using the HostName of + the host being connected (defaulting to the name typed by the us- + er). Note that CheckHostIP is not available for connects with a + proxy command. + + + + + RemoteForward + Specifies that a TCP/IP port on the remote machine be forwarded + over the secure channel to given host:port from the local ma- + chine. The first argument must be a port number, and the second + must be host:port. Multiple forwardings may be specified, and + additional forwardings can be given on the command line. Only + the superuser can forward privileged ports. + + RhostsAuthentication + Specifies whether to try rhosts based authentication. Note that + this declaration only affects the client side and has no effect + whatsoever on security. Disabling rhosts authentication may re- + duce authentication time on slow connections when rhosts authen- + tication is not used. Most servers do not permit RhostsAuthenti- + cation because it is not secure (see RhostsRSAAuthentication). + The argument to this keyword must be ``yes'' or ``no''. + + RhostsRSAAuthentication + Specifies whether to try rhosts based authentication with RSA + host authentication. This is the primary authentication method + for most sites. The argument must be ``yes'' or ``no''. + + RSAAuthentication + Specifies whether to try RSA authentication. The argument to + this keyword must be ``yes'' or ``no''. RSA authentication will + only be attempted if the identity file exists, or an authentica- + tion agent is running. Note that this option applies to protocol + version 1 only. + + SkeyAuthentication + Specifies whether to use skey(1) authentication. The argument to + this keyword must be ``yes'' or ``no''. The default is ``no''. + + StrictHostKeyChecking + If this flag is set to ``yes'', ssh ssh will never automatically + add host keys to the $HOME/.ssh/known_hosts and + $HOME/.ssh/known_hosts2 files, and refuses to connect hosts whose + host key has changed. This provides maximum protection against + trojan horse attacks. However, it can be somewhat annoying if + you don't have good /etc/ssh_known_hosts and + /etc/ssh_known_hosts2 files installed and frequently connect new + hosts. Basically this option forces the user to manually add any + new hosts. Normally this option is disabled, and new hosts will + automatically be added to the known host files. The host keys of + known hosts will be verified automatically in either case. The + argument must be ``yes'' or ``no''. + + UsePrivilegedPort + Specifies whether to use a privileged port for outgoing connec- + tions. The argument must be ``yes'' or ``no''. The default is + ``yes''. Note that setting this option to ``no'' turns off + RhostsAuthentication and RhostsRSAAuthentication. + + User Specifies the user to log in as. This can be useful if you have + a different user name on different machines. This saves the + trouble of having to remember to give the user name on the com- + mand line. + + UserKnownHostsFile + Specifies a file to use instead of $HOME/.ssh/known_hosts. + + UseRsh Specifies that rlogin/rsh should be used for this host. It is + possible that the host does not at all support the ssh protocol. + This causes ssh to immediately execute rsh(1). All other options + (except HostName) are ignored if this has been specified. The + argument must be ``yes'' or ``no''. + + XAuthLocation + Specifies the location of the xauth(1) program. The default is + /usr/X11R6/bin/xauth. + +ENVIRONMENT + ssh will normally set the following environment variables: + + DISPLAY + The DISPLAY variable indicates the location of the X11 server. + It is automatically set by ssh to point to a value of the form + ``hostname:n'' where hostname indicates the host where the shell + runs, and n is an integer >= 1. ssh uses this special value to + forward X11 connections over the secure channel. The user should + normally not set DISPLAY explicitly, as that will render the X11 + connection insecure (and will require the user to manually copy + any required authorization cookies). + + HOME Set to the path of the user's home directory. + + LOGNAME + Synonym for USER; set for compatibility with systems that use + this variable. + + MAIL Set to point the user's mailbox. + + PATH Set to the default PATH, as specified when compiling ssh. + + SSH_AUTH_SOCK + indicates the path of a unix-domain socket used to communicate + with the agent. + + SSH_CLIENT + Identifies the client end of the connection. The variable con- + tains three space-separated values: client ip-address, client + port number, and server port number. + + SSH_TTY + This is set to the name of the tty (path to the device) associat- + ed with the current shell or command. If the current session has + no tty, this variable is not set. + + TZ The timezone variable is set to indicate the present timezone if + it was set when the daemon was started (e.i., the daemon passes + the value on to new connections). + + USER Set to the name of the user logging in. + + Additionally, ssh reads $HOME/.ssh/environment, and adds lines of the + format ``VARNAME=value'' to the environment. + +FILES + $HOME/.ssh/known_hosts + Records host keys for all hosts the user has logged into (that + are not in /etc/ssh_known_hosts). See sshd(8). + + $HOME/.ssh/identity, $HOME/.ssh/id_dsa + Contains the RSA and the DSA authentication identity of the user. + These files contain sensitive data and should be readable by the + user but not accessible by others (read/write/execute). Note + that ssh ignores a private key file if it is accessible by oth- + ers. It is possible to specify a passphrase when generating the + key; the passphrase will be used to encrypt the sensitive part of + + this file using 3DES. + + $HOME/.ssh/identity.pub, $HOME/.ssh/id_dsa.pub + Contains the public key for authentication (public part of the + identity file in human-readable form). The contents of the + $HOME/.ssh/identity.pub file should be added to + $HOME/.ssh/authorized_keys on all machines where you wish to log + in using RSA authentication. The contents of the + $HOME/.ssh/id_dsa.pub file should be added to + $HOME/.ssh/authorized_keys2 on all machines where you wish to log + in using DSA authentication. These files are not sensitive and + can (but need not) be readable by anyone. These files are never + used automatically and are not necessary; they is only provided + for the convenience of the user. + + $HOME/.ssh/config + This is the per-user configuration file. The format of this file + is described above. This file is used by the ssh client. This + file does not usually contain any sensitive information, but the + recommended permissions are read/write for the user, and not ac- + cessible by others. + + $HOME/.ssh/authorized_keys + Lists the RSA keys that can be used for logging in as this user. + The format of this file is described in the sshd(8) manual page. + In the simplest form the format is the same as the .pub identity + files (that is, each line contains the number of bits in modulus, + public exponent, modulus, and comment fields, separated by + spaces). This file is not highly sensitive, but the recommended + permissions are read/write for the user, and not accessible by + others. + + $HOME/.ssh/authorized_keys2 + Lists the DSA keys that can be used for logging in as this user. + This file is not highly sensitive, but the recommended permis- + sions are read/write for the user, and not accessible by others. + + /etc/ssh_known_hosts, /etc/ssh_known_hosts2 + Systemwide list of known host keys. /etc/ssh_known_hosts con- + tains RSA and /etc/ssh_known_hosts2 contains DSA keys. These + files should be prepared by the system administrator to contain + the public host keys of all machines in the organization. This + file should be world-readable. This file contains public keys, + one per line, in the following format (fields separated by + spaces): system name, number of bits in modulus, public exponent, + modulus, and optional comment field. When different names are + used for the same machine, all such names should be listed, sepa- + rated by commas. The format is described on the sshd(8) manual + page. + + The canonical system name (as returned by name servers) is used + by sshd(8) to verify the client host when logging in; other names + are needed because ssh does not convert the user-supplied name to + a canonical name before checking the key, because someone with + access to the name servers would then be able to fool host au- + thentication. + + /etc/ssh_config + Systemwide configuration file. This file provides defaults for + those values that are not specified in the user's configuration + file, and for those users who do not have a configuration file. + This file must be world-readable. + + $HOME/.rhosts + This file is used in .rhosts authentication to list the host/user + pairs that are permitted to log in. (Note that this file is also + used by rlogin and rsh, which makes using this file insecure.) + Each line of the file contains a host name (in the canonical form + returned by name servers), and then a user name on that host, + separated by a space. One some machines this file may need to be + world-readable if the user's home directory is on a NFS parti- + tion, because sshd(8) reads it as root. Additionally, this file + must be owned by the user, and must not have write permissions + for anyone else. The recommended permission for most machines is + read/write for the user, and not accessible by others. + + Note that by default sshd(8) will be installed so that it re- + quires successful RSA host authentication before permitting + .rhosts authentication. If your server machine does not have the + client's host key in /etc/ssh_known_hosts, you can store it in + $HOME/.ssh/known_hosts. The easiest way to do this is to connect + back to the client from the server machine using ssh; this will + automatically add the host key to $HOME/.ssh/known_hosts. + + $HOME/.shosts + This file is used exactly the same way as .rhosts. The purpose + for having this file is to be able to use rhosts authentication + with ssh without permitting login with rlogin(1) or rsh(1). + + /etc/hosts.equiv + This file is used during .rhosts authentication. It contains + canonical hosts names, one per line (the full format is described + on the sshd(8) manual page). If the client host is found in this + file, login is automatically permitted provided client and server + user names are the same. Additionally, successful RSA host au- + thentication is normally required. This file should only be + writable by root. + + /etc/shosts.equiv + This file is processed exactly as /etc/hosts.equiv. This file may + be useful to permit logins using ssh but not using rsh/rlogin. + + /etc/sshrc + Commands in this file are executed by ssh when the user logs in + just before the user's shell (or command) is started. See the + sshd(8) manual page for more information. + + $HOME/.ssh/rc + Commands in this file are executed by ssh when the user logs in + just before the user's shell (or command) is started. See the + sshd(8) manual page for more information. + + $HOME/.ssh/environment + Contains additional definitions for environment variables, see + section ENVIRONMENT above. + + libcrypto.so.X.1 + A version of this library which includes support for the RSA al- + gorithm is required for proper operation. + +AUTHOR + OpenSSH is a derivative of the original (free) ssh 1.2.12 release by Tatu + Ylonen, but with bugs removed and newer features re-added. Rapidly after + the 1.2.12 release, newer versions of the original ssh bore successively + more restrictive licenses, and thus demand for a free version was born. + + This version of OpenSSH + + o has all components of a restrictive nature (i.e., patents) directly + removed from the source code; any licensed or patented components are + + + chosen from external libraries. + + o has been updated to support SSH protocol 1.5 and 2, making it compat- + ible with all other SSH clients and servers. + + o contains added support for kerberos(8) authentication and ticket + passing. + + o supports one-time password authentication with skey(1). + + OpenSSH has been created by Aaron Campbell, Bob Beck, Markus Friedl, + Niels Provos, Theo de Raadt, and Dug Song. + + The support for SSH protocol 2 was written by Markus Friedl. + +SEE ALSO + rlogin(1), rsh(1), scp(1), ssh-add(1), ssh-agent(1), ssh-keygen(1), + telnet(1), sshd(8), + +BSD Experimental September 25, 1999 13 -- cgit v1.3