diff options
Diffstat (limited to 'ssh.0')
| -rw-r--r-- | ssh.0 | 114 |
1 files changed, 50 insertions, 64 deletions
@@ -8,22 +8,19 @@ SYNOPSIS [-D [bind_address:]port] [-E log_file] [-e escape_char] [-F configfile] [-I pkcs11] [-i identity_file] [-L address] [-l login_name] [-m mac_spec] [-O ctl_cmd] [-o option] [-p port] - [-Q cipher | cipher-auth | mac | kex | key | protocol-version] - [-R address] [-S ctl_path] [-W host:port] [-w local_tun[:remote_tun]] - [user@]hostname [command] + [-Q query_option] [-R address] [-S ctl_path] [-W host:port] + [-w local_tun[:remote_tun]] [user@]hostname [command] DESCRIPTION ssh (SSH client) 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 - untrusted hosts over an insecure network. X11 connections, arbitrary TCP - ports and UNIX-domain sockets can also be forwarded over the secure - channel. + executing commands on a remote machine. It is intended to provide secure + encrypted communications between two untrusted hosts over an insecure + network. X11 connections, arbitrary TCP ports and UNIX-domain sockets + can also be forwarded over the secure channel. ssh connects and logs into the specified hostname (with optional user name). The user must prove his/her identity to the remote machine using - one of several methods depending on the protocol version used (see - below). + one of several methods (see below). If command is specified, it is executed on the remote host instead of a login shell. @@ -144,9 +141,11 @@ DESCRIPTION ~/.ssh/id_ed25519 and ~/.ssh/id_rsa for protocol version 2. 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 configuration files). ssh - will also try to load certificate information from the filename - obtained by appending -cert.pub to identity filenames. + (and multiple identities specified in configuration files). If + no certificates have been explicitly specified by the + CertificateFile directive, ssh will also try to load certificate + information from the filename obtained by appending -cert.pub to + identity filenames. -K Enables GSSAPI-based authentication and forwarding (delegation) of GSSAPI credentials to the server. @@ -190,12 +189,12 @@ DESCRIPTION details. -m mac_spec - Additionally, for protocol version 2 a comma-separated list of - MAC (message authentication code) algorithms can be specified in - order of preference. See the MACs keyword for more information. + A comma-separated list of MAC (message authentication code) + algorithms, specified in order of preference. See the MACs + keyword for more information. -N Do not execute a remote command. This is useful for just - forwarding ports (protocol version 2 only). + forwarding ports. -n Redirects stdin from /dev/null (actually, prevents reading from stdin). This must be used when ssh is run in the background. A @@ -224,6 +223,7 @@ DESCRIPTION of the options listed below, and their possible values, see ssh_config(5). + AddKeysToAgent AddressFamily BatchMode BindAddress @@ -232,6 +232,7 @@ DESCRIPTION CanonicalizeHostname CanonicalizeMaxDots CanonicalizePermittedCNAMEs + CertificateFile ChallengeResponseAuthentication CheckHostIP Cipher @@ -312,13 +313,14 @@ DESCRIPTION Port to connect to on the remote host. This can be specified on a per-host basis in the configuration file. - -Q cipher | cipher-auth | mac | kex | key | protocol-version + -Q query_option Queries ssh for the algorithms supported for the specified version 2. The available features are: cipher (supported symmetric ciphers), cipher-auth (supported symmetric ciphers that support authenticated encryption), mac (supported message - integrity codes), kex (key exchange algorithms), key (key types) - and protocol-version (supported SSH protocol versions). + integrity codes), kex (key exchange algorithms), key (key types), + key-cert (certificate key types), key-plain (non-certificate key + types), and protocol-version (supported SSH protocol versions). -q Quiet mode. Causes most warning and diagnostic messages to be suppressed. @@ -361,10 +363,9 @@ DESCRIPTION ssh_config(5) for details. -s May be used to request invocation of a subsystem on the remote - system. Subsystems are a feature of the SSH2 protocol which - facilitate the use of SSH as a secure transport for other - applications (eg. sftp(1)). The subsystem is specified as the - remote command. + system. Subsystems facilitate the use of SSH as a secure + transport for other applications (e.g. sftp(1)). The subsystem + is specified as the remote command. -T Disable pseudo-terminal allocation. @@ -383,8 +384,7 @@ DESCRIPTION -W host:port Requests that standard input and output on the client be forwarded to host on port over the secure channel. Implies -N, - -T, ExitOnForwardFailure and ClearAllForwardings. Works with - Protocol version 2 only. + -T, ExitOnForwardFailure and ClearAllForwardings. -w local_tun[:remote_tun] Requests tunnel device forwarding with the specified tun(4) @@ -427,20 +427,16 @@ DESCRIPTION AUTHENTICATION The OpenSSH SSH client supports SSH protocols 1 and 2. The default is to use protocol 2 only, though this can be changed via the Protocol option - in ssh_config(5) or the -1 and -2 options (see above). Both protocols - support similar authentication methods, but protocol 2 is the default - since it provides additional mechanisms for confidentiality (the traffic - is encrypted using AES, 3DES, Blowfish, CAST128, or Arcfour) and - integrity (hmac-md5, hmac-sha1, hmac-sha2-256, hmac-sha2-512, umac-64, - umac-128, hmac-ripemd160). Protocol 1 lacks a strong mechanism for - ensuring the integrity of the connection. + in ssh_config(5) or the -1 and -2 options (see above). Protocol 1 should + not be used and is only offered to support legacy devices. It suffers + from a number of cryptographic weaknesses and doesn't support many of the + advanced features available for protocol 2. The methods available for authentication are: GSSAPI-based authentication, host-based authentication, public key authentication, challenge-response authentication, and password authentication. Authentication methods are tried in the order specified above, though - protocol 2 has a configuration option to change the default order: - PreferredAuthentications. + PreferredAuthentications can be used to change the default order. Host-based authentication works as follows: If the machine the user logs in from is listed in /etc/hosts.equiv or /etc/shosts.equiv on the remote @@ -463,10 +459,8 @@ AUTHENTICATION creates a public/private key pair for authentication purposes. The server knows the public key, and only the user knows the private key. ssh implements public key authentication protocol automatically, using - one of the DSA, ECDSA, Ed25519 or RSA algorithms. Protocol 1 is - restricted to using only RSA keys, but protocol 2 may use any. The - HISTORY section of ssl(8) contains a brief discussion of the DSA and RSA - algorithms. + one of the DSA, ECDSA, Ed25519 or RSA algorithms. The HISTORY section of + ssl(8) contains a brief discussion of the DSA and RSA algorithms. The file ~/.ssh/authorized_keys lists the public keys that are permitted for logging in. When the user logs in, the ssh program tells the server @@ -475,13 +469,12 @@ AUTHENTICATION the corresponding public key is authorized to accept the account. The user creates his/her key pair by running ssh-keygen(1). This stores - the private key in ~/.ssh/identity (protocol 1), ~/.ssh/id_dsa (protocol - 2 DSA), ~/.ssh/id_ecdsa (protocol 2 ECDSA), ~/.ssh/id_ed25519 (protocol 2 - Ed25519), or ~/.ssh/id_rsa (protocol 2 RSA) and stores the public key in - ~/.ssh/identity.pub (protocol 1), ~/.ssh/id_dsa.pub (protocol 2 DSA), - ~/.ssh/id_ecdsa.pub (protocol 2 ECDSA), ~/.ssh/id_ed25519.pub (protocol 2 - Ed25519), or ~/.ssh/id_rsa.pub (protocol 2 RSA) in the user's home - directory. The user should then copy the public key to + the private key in ~/.ssh/identity (protocol 1), ~/.ssh/id_dsa (DSA), + ~/.ssh/id_ecdsa (ECDSA), ~/.ssh/id_ed25519 (Ed25519), or ~/.ssh/id_rsa + (RSA) and stores the public key in ~/.ssh/identity.pub (protocol 1), + ~/.ssh/id_dsa.pub (DSA), ~/.ssh/id_ecdsa.pub (ECDSA), + ~/.ssh/id_ed25519.pub (Ed25519), or ~/.ssh/id_rsa.pub (RSA) in the user's + home directory. The user should then copy the public key to ~/.ssh/authorized_keys in his/her home directory on the remote machine. The authorized_keys file corresponds to the conventional ~/.rhosts file, and has one key per line, though the lines can be very long. After this, @@ -495,15 +488,13 @@ AUTHENTICATION more information. The most convenient way to use public key or certificate authentication - may be with an authentication agent. See ssh-agent(1) for more - information. + may be with an authentication agent. See ssh-agent(1) and (optionally) + the AddKeysToAgent directive in ssh_config(5) for more information. Challenge-response authentication works as follows: The server sends an - arbitrary "challenge" text, and prompts for a response. Protocol 2 - allows multiple challenges and responses; protocol 1 is restricted to - just one challenge/response. Examples of challenge-response - authentication include BSD Authentication (see login.conf(5)) and PAM - (some non-OpenBSD systems). + arbitrary "challenge" text, and prompts for a response. Examples of + challenge-response authentication include BSD Authentication (see + login.conf(5)) and PAM (some non-OpenBSD systems). Finally, if other authentication methods fail, ssh prompts the user for a password. The password is sent to the remote host for checking; however, @@ -565,8 +556,8 @@ ESCAPE CHARACTERS ~? Display a list of escape characters. - ~B Send a BREAK to the remote system (only useful for SSH protocol - version 2 and if the peer supports it). + ~B Send a BREAK to the remote system (only useful if the peer + supports it). ~C Open command line. Currently this allows the addition of port forwardings using the -L, -R and -D options (see above). It also @@ -577,8 +568,8 @@ ESCAPE CHARACTERS PermitLocalCommand option is enabled in ssh_config(5). Basic help is available, using the -h option. - ~R Request rekeying of the connection (only useful for SSH protocol - version 2 and if the peer supports it). + ~R Request rekeying of the connection (only useful if the peer + supports it). ~V Decrease the verbosity (LogLevel) when errors are being written to stderr. @@ -892,12 +883,7 @@ FILES /etc/ssh/ssh_host_ed25519_key /etc/ssh/ssh_host_rsa_key These files contain the private parts of the host keys and are - used for host-based authentication. If protocol version 1 is - used, ssh must be setuid root, since the host key is readable - only by root. For protocol version 2, ssh uses ssh-keysign(8) to - access the host keys, eliminating the requirement that ssh be - setuid root when host-based authentication is used. By default - ssh is not setuid root. + used for host-based authentication. /etc/ssh/ssh_known_hosts Systemwide list of known host keys. This file should be prepared @@ -969,4 +955,4 @@ AUTHORS created OpenSSH. Markus Friedl contributed the support for SSH protocol versions 1.5 and 2.0. -OpenBSD 5.8 July 20, 2015 OpenBSD 5.8 +OpenBSD 5.9 February 17, 2016 OpenBSD 5.9 |