d/freebsd-dev
1
0
Fork 0
Code Issues Pull Requests Packages Projects Releases Wiki Activity

Remove a number of generated files which are either out-of-date (because

Browse Source 
they are never regenerated to reflect our changes) or in the way of
freebsd-configure.sh.
This commit is contained in:
Dag-Erling Smørgrav 2016-01-20 23:08:57 +00:00
parent 783c605101
commit 8688f98d23
Notes: svn2git 2020-12-20 02:59:44 +00:00 
svn path=/head/; revision=294466
16 changed files with 0 additions and 27242 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

1729
crypto/openssh/config.h.in
View File

File diff suppressed because it is too large Load Diff

20111
crypto/openssh/configure vendored
View File

File diff suppressed because it is too large Load Diff

74
crypto/openssh/moduli.0
View File

@ -1,74 +0,0 @@
MODULI(5) File Formats Manual MODULI(5)
NAME
moduli M-bM-^@M-^S Diffie-Hellman moduli
DESCRIPTION
The /etc/moduli file contains prime numbers and generators for use by
sshd(8) in the Diffie-Hellman Group Exchange key exchange method.
New moduli may be generated with ssh-keygen(1) using a two-step process.
An initial candidate generation pass, using ssh-keygen -G, calculates
numbers that are likely to be useful. A second primality testing pass,
using ssh-keygen -T, provides a high degree of assurance that the numbers
are prime and are safe for use in Diffie-Hellman operations by sshd(8).
This moduli format is used as the output from each pass.
The file consists of newline-separated records, one per modulus,
containing seven space-separated fields. These fields are as follows:
timestamp The time that the modulus was last processed as
YYYYMMDDHHMMSS.
type Decimal number specifying the internal structure of
the prime modulus. Supported types are:
0 Unknown, not tested.
2 "Safe" prime; (p-1)/2 is also prime.
4 Sophie Germain; 2p+1 is also prime.
Moduli candidates initially produced by ssh-keygen(1)
are Sophie Germain primes (type 4). Further primality
testing with ssh-keygen(1) produces safe prime moduli
(type 2) that are ready for use in sshd(8). Other
types are not used by OpenSSH.
tests Decimal number indicating the type of primality tests
that the number has been subjected to represented as a
bitmask of the following values:
0x00 Not tested.
0x01 Composite number M-bM-^@M-^S not prime.
0x02 Sieve of Eratosthenes.
0x04 Probabilistic Miller-Rabin primality tests.
The ssh-keygen(1) moduli candidate generation uses the
Sieve of Eratosthenes (flag 0x02). Subsequent
ssh-keygen(1) primality tests are Miller-Rabin tests
(flag 0x04).
trials Decimal number indicating the number of primality
trials that have been performed on the modulus.
size Decimal number indicating the size of the prime in
bits.
generator The recommended generator for use with this modulus
(hexadecimal).
modulus The modulus itself in hexadecimal.
When performing Diffie-Hellman Group Exchange, sshd(8) first estimates
the size of the modulus required to produce enough Diffie-Hellman output
to sufficiently key the selected symmetric cipher. sshd(8) then randomly
selects a modulus from /etc/moduli that best meets the size requirement.
SEE ALSO
ssh-keygen(1), sshd(8)
STANDARDS
M. Friedl, N. Provos, and W. Simpson, Diffie-Hellman Group Exchange for
the Secure Shell (SSH) Transport Layer Protocol, RFC 4419, March 2006,
2006.
OpenBSD 5.8 September 26, 2012 OpenBSD 5.8

165
crypto/openssh/scp.0
View File

@ -1,165 +0,0 @@
SCP(1) General Commands Manual SCP(1)
NAME
scp M-bM-^@M-^S secure copy (remote file copy program)
SYNOPSIS
scp [-12346BCpqrv] [-c cipher] [-F ssh_config] [-i identity_file]
[-l limit] [-o ssh_option] [-P port] [-S program]
[[user@]host1:]file1 ... [[user@]host2:]file2
DESCRIPTION
scp copies files between hosts on a network. It uses ssh(1) for data
transfer, and uses the same authentication and provides the same security
as ssh(1). scp will ask for passwords or passphrases if they are needed
for authentication.
File names may contain a user and host specification to indicate that the
file is to be copied to/from that host. Local file names can be made
explicit using absolute or relative pathnames to avoid scp treating file
names containing M-bM-^@M-^X:M-bM-^@M-^Y as host specifiers. Copies between two remote hosts
are also permitted.
The options are as follows:
-1 Forces scp to use protocol 1.
-2 Forces scp to use protocol 2.
-3 Copies between two remote hosts are transferred through the local
host. Without this option the data is copied directly between
the two remote hosts. Note that this option disables the
progress meter.
-4 Forces scp to use IPv4 addresses only.
-6 Forces scp to use IPv6 addresses only.
-B Selects batch mode (prevents asking for passwords or
passphrases).
-C Compression enable. Passes the -C flag to ssh(1) to enable
compression.
-c cipher
Selects the cipher to use for encrypting the data transfer. This
option is directly passed to ssh(1).
-F ssh_config
Specifies an alternative per-user configuration file for ssh.
This option is directly passed to ssh(1).
-i identity_file
Selects the file from which the identity (private key) for public
key authentication is read. This option is directly passed to
ssh(1).
-l limit
Limits the used bandwidth, specified in Kbit/s.
-o ssh_option
Can be used to pass options to ssh in the format used in
ssh_config(5). This is useful for specifying options for which
there is no separate scp command-line flag. For full details of
the options listed below, and their possible values, see
ssh_config(5).
AddressFamily
BatchMode
BindAddress
CanonicalDomains
CanonicalizeFallbackLocal
CanonicalizeHostname
CanonicalizeMaxDots
CanonicalizePermittedCNAMEs
ChallengeResponseAuthentication
CheckHostIP
Cipher
Ciphers
Compression
CompressionLevel
ConnectionAttempts
ConnectTimeout
ControlMaster
ControlPath
ControlPersist
GlobalKnownHostsFile
GSSAPIAuthentication
GSSAPIDelegateCredentials
HashKnownHosts
Host
HostbasedAuthentication
HostbasedKeyTypes
HostKeyAlgorithms
HostKeyAlias
HostName
IdentityFile
IdentitiesOnly
IPQoS
KbdInteractiveAuthentication
KbdInteractiveDevices
KexAlgorithms
LogLevel
MACs
NoHostAuthenticationForLocalhost
NumberOfPasswordPrompts
PasswordAuthentication
PKCS11Provider
Port
PreferredAuthentications
Protocol
ProxyCommand
PubkeyAcceptedKeyTypes
PubkeyAuthentication
RekeyLimit
RhostsRSAAuthentication
RSAAuthentication
SendEnv
ServerAliveInterval
ServerAliveCountMax
StrictHostKeyChecking
TCPKeepAlive
UpdateHostKeys
UsePrivilegedPort
User
UserKnownHostsFile
VerifyHostKeyDNS
-P port
Specifies the port to connect to on the remote host. Note that
this option is written with a capital M-bM-^@M-^XPM-bM-^@M-^Y, because -p is already
reserved for preserving the times and modes of the file.
-p Preserves modification times, access times, and modes from the
original file.
-q Quiet mode: disables the progress meter as well as warning and
diagnostic messages from ssh(1).
-r Recursively copy entire directories. Note that scp follows
symbolic links encountered in the tree traversal.
-S program
Name of program to use for the encrypted connection. The program
must understand ssh(1) options.
-v Verbose mode. Causes scp and ssh(1) to print debugging messages
about their progress. This is helpful in debugging connection,
authentication, and configuration problems.
EXIT STATUS
The scp utility exitsM-BM- 0 on success, andM-BM- >0 if an error occurs.
SEE ALSO
sftp(1), ssh(1), ssh-add(1), ssh-agent(1), ssh-keygen(1), ssh_config(5),
sshd(8)
HISTORY
scp is based on the rcp program in BSD source code from the Regents of
the University of California.
AUTHORS
Timo Rinne <tri@iki.fi>
Tatu Ylonen <ylo@cs.hut.fi>
OpenBSD 5.8 July 10, 2015 OpenBSD 5.8

96
crypto/openssh/sftp-server.0
View File

@ -1,96 +0,0 @@
SFTP-SERVER(8) System Manager's Manual SFTP-SERVER(8)
NAME
sftp-server M-bM-^@M-^S SFTP server subsystem
SYNOPSIS
sftp-server [-ehR] [-d start_directory] [-f log_facility] [-l log_level]
[-P blacklisted_requests] [-p whitelisted_requests]
[-u umask]
sftp-server -Q protocol_feature
DESCRIPTION
sftp-server is a program that speaks the server side of SFTP protocol to
stdout and expects client requests from stdin. sftp-server is not
intended to be called directly, but from sshd(8) using the Subsystem
option.
Command-line flags to sftp-server should be specified in the Subsystem
declaration. See sshd_config(5) for more information.
Valid options are:
-d start_directory
specifies an alternate starting directory for users. The
pathname may contain the following tokens that are expanded at
runtime: %% is replaced by a literal '%', %d is replaced by the
home directory of the user being authenticated, and %u is
replaced by the username of that user. The default is to use the
user's home directory. This option is useful in conjunction with
the sshd_config(5) ChrootDirectory option.
-e Causes sftp-server to print logging information to stderr instead
of syslog for debugging.
-f log_facility
Specifies the facility code that is used when logging messages
from sftp-server. The possible values are: DAEMON, USER, AUTH,
LOCAL0, LOCAL1, LOCAL2, LOCAL3, LOCAL4, LOCAL5, LOCAL6, LOCAL7.
The default is AUTH.
-h Displays sftp-server usage information.
-l log_level
Specifies which messages will be logged by sftp-server. The
possible values are: QUIET, FATAL, ERROR, INFO, VERBOSE, DEBUG,
DEBUG1, DEBUG2, and DEBUG3. INFO and VERBOSE log transactions
that sftp-server performs on behalf of the client. DEBUG and
DEBUG1 are equivalent. DEBUG2 and DEBUG3 each specify higher
levels of debugging output. The default is ERROR.
-P blacklisted_requests
Specify a comma-separated list of SFTP protocol requests that are
banned by the server. sftp-server will reply to any blacklisted
request with a failure. The -Q flag can be used to determine the
supported request types. If both a blacklist and a whitelist are
specified, then the blacklist is applied before the whitelist.
-p whitelisted_requests
Specify a comma-separated list of SFTP protocol requests that are
permitted by the server. All request types that are not on the
whitelist will be logged and replied to with a failure message.
Care must be taken when using this feature to ensure that
requests made implicitly by SFTP clients are permitted.
-Q protocol_feature
Query protocol features supported by sftp-server. At present the
only feature that may be queried is M-bM-^@M-^\requestsM-bM-^@M-^], which may be used
for black or whitelisting (flags -P and -p respectively).
-R Places this instance of sftp-server into a read-only mode.
Attempts to open files for writing, as well as other operations
that change the state of the filesystem, will be denied.
-u umask
Sets an explicit umask(2) to be applied to newly-created files
and directories, instead of the user's default mask.
On some systems, sftp-server must be able to access /dev/log for logging
to work, and use of sftp-server in a chroot configuration therefore
requires that syslogd(8) establish a logging socket inside the chroot
directory.
SEE ALSO
sftp(1), ssh(1), sshd_config(5), sshd(8)
T. Ylonen and S. Lehtinen, SSH File Transfer Protocol, draft-ietf-secsh-
filexfer-02.txt, October 2001, work in progress material.
HISTORY
sftp-server first appeared in OpenBSD 2.8.
AUTHORS
Markus Friedl <markus@openbsd.org>
OpenBSD 5.8 December 11, 2014 OpenBSD 5.8

383
crypto/openssh/sftp.0
View File

@ -1,383 +0,0 @@
SFTP(1) General Commands Manual SFTP(1)
NAME
sftp M-bM-^@M-^S secure file transfer program
SYNOPSIS
sftp [-1246aCfpqrv] [-B buffer_size] [-b batchfile] [-c cipher]
[-D sftp_server_path] [-F ssh_config] [-i identity_file] [-l limit]
[-o ssh_option] [-P port] [-R num_requests] [-S program]
[-s subsystem | sftp_server] host
sftp [user@]host[:file ...]
sftp [user@]host[:dir[/]]
sftp -b batchfile [user@]host
DESCRIPTION
sftp is an interactive file transfer program, similar to ftp(1), which
performs all operations over an encrypted ssh(1) transport. It may also
use many features of ssh, such as public key authentication and
compression. sftp connects and logs into the specified host, then enters
an interactive command mode.
The second usage format will retrieve files automatically if a non-
interactive authentication method is used; otherwise it will do so after
successful interactive authentication.
The third usage format allows sftp to start in a remote directory.
The final usage format allows for automated sessions using the -b option.
In such cases, it is necessary to configure non-interactive
authentication to obviate the need to enter a password at connection time
(see sshd(8) and ssh-keygen(1) for details).
Since some usage formats use colon characters to delimit host names from
path names, IPv6 addresses must be enclosed in square brackets to avoid
ambiguity.
The options are as follows:
-1 Specify the use of protocol version 1.
-2 Specify the use of protocol version 2.
-4 Forces sftp to use IPv4 addresses only.
-6 Forces sftp to use IPv6 addresses only.
-a Attempt to continue interrupted transfers rather than overwriting
existing partial or complete copies of files. If the partial
contents differ from those being transferred, then the resultant
file is likely to be corrupt.
-B buffer_size
Specify the size of the buffer that sftp uses when transferring
files. Larger buffers require fewer round trips at the cost of
higher memory consumption. The default is 32768 bytes.
-b batchfile
Batch mode reads a series of commands from an input batchfile
instead of stdin. Since it lacks user interaction it should be
used in conjunction with non-interactive authentication. A
batchfile of M-bM-^@M-^X-M-bM-^@M-^Y may be used to indicate standard input. sftp
will abort if any of the following commands fail: get, put,
reget, reput, rename, ln, rm, mkdir, chdir, ls, lchdir, chmod,
chown, chgrp, lpwd, df, symlink, and lmkdir. Termination on
error can be suppressed on a command by command basis by
prefixing the command with a M-bM-^@M-^X-M-bM-^@M-^Y character (for example, -rm
/tmp/blah*).
-C Enables compression (via ssh's -C flag).
-c cipher
Selects the cipher to use for encrypting the data transfers.
This option is directly passed to ssh(1).
-D sftp_server_path
Connect directly to a local sftp server (rather than via ssh(1)).
This option may be useful in debugging the client and server.
-F ssh_config
Specifies an alternative per-user configuration file for ssh(1).
This option is directly passed to ssh(1).
-f Requests that files be flushed to disk immediately after
transfer. When uploading files, this feature is only enabled if
the server implements the "fsync@openssh.com" extension.
-i identity_file
Selects the file from which the identity (private key) for public
key authentication is read. This option is directly passed to
ssh(1).
-l limit
Limits the used bandwidth, specified in Kbit/s.
-o ssh_option
Can be used to pass options to ssh in the format used in
ssh_config(5). This is useful for specifying options for which
there is no separate sftp command-line flag. For example, to
specify an alternate port use: sftp -oPort=24. For full details
of the options listed below, and their possible values, see
ssh_config(5).
AddressFamily
BatchMode
BindAddress
CanonicalDomains
CanonicalizeFallbackLocal
CanonicalizeHostname
CanonicalizeMaxDots
CanonicalizePermittedCNAMEs
ChallengeResponseAuthentication
CheckHostIP
Cipher
Ciphers
Compression
CompressionLevel
ConnectionAttempts
ConnectTimeout
ControlMaster
ControlPath
ControlPersist
GlobalKnownHostsFile
GSSAPIAuthentication
GSSAPIDelegateCredentials
HashKnownHosts
Host
HostbasedAuthentication
HostbasedKeyTypes
HostKeyAlgorithms
HostKeyAlias
HostName
IdentityFile
IdentitiesOnly
IPQoS
KbdInteractiveAuthentication
KbdInteractiveDevices
KexAlgorithms
LogLevel
MACs
NoHostAuthenticationForLocalhost
NumberOfPasswordPrompts
PasswordAuthentication
PKCS11Provider
Port
PreferredAuthentications
Protocol
ProxyCommand
PubkeyAuthentication
RekeyLimit
RhostsRSAAuthentication
RSAAuthentication
SendEnv
ServerAliveInterval
ServerAliveCountMax
StrictHostKeyChecking
TCPKeepAlive
UpdateHostKeys
UsePrivilegedPort
User
UserKnownHostsFile
VerifyHostKeyDNS
-P port
Specifies the port to connect to on the remote host.
-p Preserves modification times, access times, and modes from the
original files transferred.
-q Quiet mode: disables the progress meter as well as warning and
diagnostic messages from ssh(1).
-R num_requests
Specify how many requests may be outstanding at any one time.
Increasing this may slightly improve file transfer speed but will
increase memory usage. The default is 64 outstanding requests.
-r Recursively copy entire directories when uploading and
downloading. Note that sftp does not follow symbolic links
encountered in the tree traversal.
-S program
Name of the program to use for the encrypted connection. The
program must understand ssh(1) options.
-s subsystem | sftp_server
Specifies the SSH2 subsystem or the path for an sftp server on
the remote host. A path is useful for using sftp over protocol
version 1, or when the remote sshd(8) does not have an sftp
subsystem configured.
-v Raise logging level. This option is also passed to ssh.
INTERACTIVE COMMANDS
Once in interactive mode, sftp understands a set of commands similar to
those of ftp(1). Commands are case insensitive. Pathnames that contain
spaces must be enclosed in quotes. Any special characters contained
within pathnames that are recognized by glob(3) must be escaped with
backslashes (M-bM-^@M-^X\M-bM-^@M-^Y).
bye Quit sftp.
cd path
Change remote directory to path.
chgrp grp path
Change group of file path to grp. path may contain glob(3)
characters and may match multiple files. grp must be a numeric
GID.
chmod mode path
Change permissions of file path to mode. path may contain
glob(3) characters and may match multiple files.
chown own path
Change owner of file path to own. path may contain glob(3)
characters and may match multiple files. own must be a numeric
UID.
df [-hi] [path]
Display usage information for the filesystem holding the current
directory (or path if specified). If the -h flag is specified,
the capacity information will be displayed using "human-readable"
suffixes. The -i flag requests display of inode information in
addition to capacity information. This command is only supported
on servers that implement the M-bM-^@M-^\statvfs@openssh.comM-bM-^@M-^] extension.
exit Quit sftp.
get [-afPpr] remote-path [local-path]
Retrieve the remote-path and store it on the local machine. If
the local path name is not specified, it is given the same name
it has on the remote machine. remote-path may contain glob(3)
characters and may match multiple files. If it does and
local-path is specified, then local-path must specify a
directory.
If the -a flag is specified, then attempt to resume partial
transfers of existing files. Note that resumption assumes that
any partial copy of the local file matches the remote copy. If
the remote file contents differ from the partial local copy then
the resultant file is likely to be corrupt.
If the -f flag is specified, then fsync(2) will be called after
the file transfer has completed to flush the file to disk.
If either the -P or -p flag is specified, then full file
permissions and access times are copied too.
If the -r flag is specified then directories will be copied
recursively. Note that sftp does not follow symbolic links when
performing recursive transfers.
help Display help text.
lcd path
Change local directory to path.
lls [ls-options [path]]
Display local directory listing of either path or current
directory if path is not specified. ls-options may contain any
flags supported by the local system's ls(1) command. path may
contain glob(3) characters and may match multiple files.
lmkdir path
Create local directory specified by path.
ln [-s] oldpath newpath
Create a link from oldpath to newpath. If the -s flag is
specified the created link is a symbolic link, otherwise it is a
hard link.
lpwd Print local working directory.
ls [-1afhlnrSt] [path]
Display a remote directory listing of either path or the current
directory if path is not specified. path may contain glob(3)
characters and may match multiple files.
The following flags are recognized and alter the behaviour of ls
accordingly:
-1 Produce single columnar output.
-a List files beginning with a dot (M-bM-^@M-^X.M-bM-^@M-^Y).
-f Do not sort the listing. The default sort order is
lexicographical.
-h When used with a long format option, use unit suffixes:
Byte, Kilobyte, Megabyte, Gigabyte, Terabyte, Petabyte,
and Exabyte in order to reduce the number of digits to
four or fewer using powers of 2 for sizes (K=1024,
M=1048576, etc.).
-l Display additional details including permissions and
ownership information.
-n Produce a long listing with user and group information
presented numerically.
-r Reverse the sort order of the listing.
-S Sort the listing by file size.
-t Sort the listing by last modification time.
lumask umask
Set local umask to umask.
mkdir path
Create remote directory specified by path.
progress
Toggle display of progress meter.
put [-afPpr] local-path [remote-path]
Upload local-path and store it on the remote machine. If the
remote path name is not specified, it is given the same name it
has on the local machine. local-path may contain glob(3)
characters and may match multiple files. If it does and
remote-path is specified, then remote-path must specify a
directory.
If the -a flag is specified, then attempt to resume partial
transfers of existing files. Note that resumption assumes that
any partial copy of the remote file matches the local copy. If
the local file contents differ from the remote local copy then
the resultant file is likely to be corrupt.
If the -f flag is specified, then a request will be sent to the
server to call fsync(2) after the file has been transferred.
Note that this is only supported by servers that implement the
"fsync@openssh.com" extension.
If either the -P or -p flag is specified, then full file
permissions and access times are copied too.
If the -r flag is specified then directories will be copied
recursively. Note that sftp does not follow symbolic links when
performing recursive transfers.
pwd Display remote working directory.
quit Quit sftp.
reget [-Ppr] remote-path [local-path]
Resume download of remote-path. Equivalent to get with the -a
flag set.
reput [-Ppr] [local-path] remote-path
Resume upload of [local-path]. Equivalent to put with the -a
flag set.
rename oldpath newpath
Rename remote file from oldpath to newpath.
rm path
Delete remote file specified by path.
rmdir path
Remove remote directory specified by path.
symlink oldpath newpath
Create a symbolic link from oldpath to newpath.
version
Display the sftp protocol version.
!command
Execute command in local shell.
! Escape to local shell.
? Synonym for help.
SEE ALSO
ftp(1), ls(1), scp(1), ssh(1), ssh-add(1), ssh-keygen(1), glob(3),
ssh_config(5), sftp-server(8), sshd(8)
T. Ylonen and S. Lehtinen, SSH File Transfer Protocol, draft-ietf-secsh-
filexfer-00.txt, January 2001, work in progress material.
OpenBSD 5.8 January 30, 2015 OpenBSD 5.8

129
crypto/openssh/ssh-add.0
View File

@ -1,129 +0,0 @@
SSH-ADD(1) General Commands Manual SSH-ADD(1)
NAME
ssh-add M-bM-^@M-^S adds private key identities to the authentication agent
SYNOPSIS
ssh-add [-cDdkLlXx] [-E fingerprint_hash] [-t life] [file ...]
ssh-add -s pkcs11
ssh-add -e pkcs11
DESCRIPTION
ssh-add adds private key identities to the authentication agent,
ssh-agent(1). When run without arguments, it adds the files
~/.ssh/id_rsa, ~/.ssh/id_dsa, ~/.ssh/id_ecdsa, ~/.ssh/id_ed25519 and
~/.ssh/identity. After loading a private key, ssh-add will try to load
corresponding certificate information from the filename obtained by
appending -cert.pub to the name of the private key file. Alternative
file names can be given on the command line.
If any file requires a passphrase, ssh-add asks for the passphrase from
the user. The passphrase is read from the user's tty. ssh-add retries
the last passphrase if multiple identity files are given.
The authentication agent must be running and the SSH_AUTH_SOCK
environment variable must contain the name of its socket for ssh-add to
work.
The options are as follows:
-c Indicates that added identities should be subject to confirmation
before being used for authentication. Confirmation is performed
by ssh-askpass(1). Successful confirmation is signaled by a zero
exit status from ssh-askpass(1), rather than text entered into
the requester.
-D Deletes all identities from the agent.
-d Instead of adding identities, removes identities from the agent.
If ssh-add has been run without arguments, the keys for the
default identities and their corresponding certificates will be
removed. Otherwise, the argument list will be interpreted as a
list of paths to public key files to specify keys and
certificates to be removed from the agent. If no public key is
found at a given path, ssh-add will append .pub and retry.
-E fingerprint_hash
Specifies the hash algorithm used when displaying key
fingerprints. Valid options are: M-bM-^@M-^\md5M-bM-^@M-^] and M-bM-^@M-^\sha256M-bM-^@M-^]. The
default is M-bM-^@M-^\sha256M-bM-^@M-^].
-e pkcs11
Remove keys provided by the PKCS#11 shared library pkcs11.
-k When loading keys into or deleting keys from the agent, process
plain private keys only and skip certificates.
-L Lists public key parameters of all identities currently
represented by the agent.
-l Lists fingerprints of all identities currently represented by the
agent.
-s pkcs11
Add keys provided by the PKCS#11 shared library pkcs11.
-t life
Set a maximum lifetime when adding identities to an agent. The
lifetime may be specified in seconds or in a time format
specified in sshd_config(5).
-X Unlock the agent.
-x Lock the agent with a password.
ENVIRONMENT
DISPLAY and SSH_ASKPASS
If ssh-add needs a passphrase, it will read the passphrase from
the current terminal if it was run from a terminal. If ssh-add
does not have a terminal associated with it but DISPLAY and
SSH_ASKPASS are set, it will execute the program specified by
SSH_ASKPASS (by default M-bM-^@M-^\ssh-askpassM-bM-^@M-^]) and open an X11 window to
read the passphrase. This is particularly useful when calling
ssh-add from a .xsession or related script. (Note that on some
machines it may be necessary to redirect the input from /dev/null
to make this work.)
SSH_AUTH_SOCK
Identifies the path of a UNIX-domain socket used to communicate
with the agent.
FILES
~/.ssh/identity
Contains the protocol version 1 RSA authentication identity of
the user.
~/.ssh/id_dsa
Contains the protocol version 2 DSA authentication identity of
the user.
~/.ssh/id_ecdsa
Contains the protocol version 2 ECDSA authentication identity of
the user.
~/.ssh/id_ed25519
Contains the protocol version 2 Ed25519 authentication identity
of the user.
~/.ssh/id_rsa
Contains the protocol version 2 RSA authentication identity of
the user.
Identity files should not be readable by anyone but the user. Note that
ssh-add ignores identity files if they are accessible by others.
EXIT STATUS
Exit status is 0 on success, 1 if the specified command fails, and 2 if
ssh-add is unable to contact the authentication agent.
SEE ALSO
ssh(1), ssh-agent(1), ssh-askpass(1), ssh-keygen(1), sshd(8)
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.
OpenBSD 5.8 March 30, 2015 OpenBSD 5.8

112
crypto/openssh/ssh-agent.0
View File

@ -1,112 +0,0 @@
SSH-AGENT(1) General Commands Manual SSH-AGENT(1)
NAME
ssh-agent M-bM-^@M-^S authentication agent
SYNOPSIS
ssh-agent [-c | -s] [-Dd] [-a bind_address] [-E fingerprint_hash]
[-t life] [command [arg ...]]
ssh-agent [-c | -s] -k
DESCRIPTION
ssh-agent is a program to hold private keys used for public key
authentication (RSA, DSA, ECDSA, Ed25519). ssh-agent is usually started
in the beginning of an X-session or a login session, and all other
windows or programs are started as clients to the ssh-agent program.
Through use of environment variables the agent can be located and
automatically used for authentication when logging in to other machines
using ssh(1).
The agent initially does not have any private keys. Keys are added using
ssh-add(1). Multiple identities may be stored in ssh-agent concurrently
and ssh(1) will automatically use them if present. ssh-add(1) is also
used to remove keys from ssh-agent and to query the keys that are held in
one.
The options are as follows:
-a bind_address
Bind the agent to the UNIX-domain socket bind_address. The
default is $TMPDIR/ssh-XXXXXXXXXX/agent.<ppid>.
-c Generate C-shell commands on stdout. This is the default if
SHELL looks like it's a csh style of shell.
-D Foreground mode. When this option is specified ssh-agent will
not fork.
-d Debug mode. When this option is specified ssh-agent will not
fork and will write debug information to standard error.
-E fingerprint_hash
Specifies the hash algorithm used when displaying key
fingerprints. Valid options are: M-bM-^@M-^\md5M-bM-^@M-^] and M-bM-^@M-^\sha256M-bM-^@M-^]. The
default is M-bM-^@M-^\sha256M-bM-^@M-^].
-k Kill the current agent (given by the SSH_AGENT_PID environment
variable).
-s Generate Bourne shell commands on stdout. This is the default if
SHELL does not look like it's a csh style of shell.
-t life
Set a default value for the maximum lifetime of identities added
to the agent. The lifetime may be specified in seconds or in a
time format specified in sshd_config(5). A lifetime specified
for an identity with ssh-add(1) overrides this value. Without
this option the default maximum lifetime is forever.
If a commandline is given, this is executed as a subprocess of the agent.
When the command dies, so does the agent.
The idea is that the agent is run in the user's local PC, laptop, or
terminal. Authentication data need not be stored on any other machine,
and authentication passphrases never go over the network. However, the
connection to the agent is forwarded over SSH remote logins, and the user
can thus use the privileges given by the identities anywhere in the
network in a secure way.
There are two main ways to get an agent set up: The first is that the
agent starts a new subcommand into which some environment variables are
exported, eg ssh-agent xterm &. The second is that the agent prints the
needed shell commands (either sh(1) or csh(1) syntax can be generated)
which can be evaluated in the calling shell, eg eval `ssh-agent -s` for
Bourne-type shells such as sh(1) or ksh(1) and eval `ssh-agent -c` for
csh(1) and derivatives.
Later ssh(1) looks at these variables and uses them to establish a
connection to the agent.
The agent will never send a private key over its request channel.
Instead, operations that require a private key will be performed by the
agent, and the result will be returned to the requester. This way,
private keys are not exposed to clients using the agent.
A UNIX-domain socket is created and the name of this socket is stored in
the SSH_AUTH_SOCK environment variable. The socket is made accessible
only to the current user. This method is easily abused by root or
another instance of the same user.
The SSH_AGENT_PID environment variable holds the agent's process ID.
The agent exits automatically when the command given on the command line
terminates.
FILES
$TMPDIR/ssh-XXXXXXXXXX/agent.<ppid>
UNIX-domain sockets used to contain the connection to the
authentication agent. These sockets should only be readable by
the owner. The sockets should get automatically removed when the
agent exits.
SEE ALSO
ssh(1), ssh-add(1), ssh-keygen(1), sshd(8)
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.
OpenBSD 5.8 April 24, 2015 OpenBSD 5.8

566
crypto/openssh/ssh-keygen.0
View File

@ -1,566 +0,0 @@
SSH-KEYGEN(1) General Commands Manual SSH-KEYGEN(1)
NAME
ssh-keygen M-bM-^@M-^S authentication key generation, management and conversion
SYNOPSIS
ssh-keygen [-q] [-b bits] [-t dsa | ecdsa | ed25519 | rsa | rsa1]
[-N new_passphrase] [-C comment] [-f output_keyfile]
ssh-keygen -p [-P old_passphrase] [-N new_passphrase] [-f keyfile]
ssh-keygen -i [-m key_format] [-f input_keyfile]
ssh-keygen -e [-m key_format] [-f input_keyfile]
ssh-keygen -y [-f input_keyfile]
ssh-keygen -c [-P passphrase] [-C comment] [-f keyfile]
ssh-keygen -l [-v] [-E fingerprint_hash] [-f input_keyfile]
ssh-keygen -B [-f input_keyfile]
ssh-keygen -D pkcs11
ssh-keygen -F hostname [-f known_hosts_file] [-l]
ssh-keygen -H [-f known_hosts_file]
ssh-keygen -R hostname [-f known_hosts_file]
ssh-keygen -r hostname [-f input_keyfile] [-g]
ssh-keygen -G output_file [-v] [-b bits] [-M memory] [-S start_point]
ssh-keygen -T output_file -f input_file [-v] [-a rounds] [-J num_lines]
[-j start_line] [-K checkpt] [-W generator]
ssh-keygen -s ca_key -I certificate_identity [-h] [-n principals]
[-O option] [-V validity_interval] [-z serial_number] file ...
ssh-keygen -L [-f input_keyfile]
ssh-keygen -A
ssh-keygen -k -f krl_file [-u] [-s ca_public] [-z version_number]
file ...
ssh-keygen -Q -f krl_file file ...
DESCRIPTION
ssh-keygen generates, manages and converts authentication keys for
ssh(1). ssh-keygen can create RSA keys for use by SSH protocol version 1
and DSA, ECDSA, Ed25519 or RSA keys for use by SSH protocol version 2.
The type of key to be generated is specified with the -t option. If
invoked without any arguments, ssh-keygen will generate an RSA key for
use in SSH protocol 2 connections.
ssh-keygen is also used to generate groups for use in Diffie-Hellman
group exchange (DH-GEX). See the MODULI GENERATION section for details.
Finally, ssh-keygen can be used to generate and update Key Revocation
Lists, and to test whether given keys have been revoked by one. See the
KEY REVOCATION LISTS section for details.
Normally each user wishing to use SSH with public key authentication runs
this once to create the authentication key in ~/.ssh/identity,
~/.ssh/id_dsa, ~/.ssh/id_ecdsa, ~/.ssh/id_ed25519 or ~/.ssh/id_rsa.
Additionally, the system administrator may use this to generate host
keys, as seen in /etc/rc.
Normally this program generates the key and asks for a file in which to
store the private key. The public key is stored in a file with the same
name but M-bM-^@M-^\.pubM-bM-^@M-^] appended. The program also asks for a passphrase. The
passphrase may be empty to indicate no passphrase (host keys must have an
empty passphrase), or it may be a string of arbitrary length. A
passphrase is similar to a password, except it can be a phrase with a
series of words, punctuation, numbers, whitespace, or any string of
characters you want. Good passphrases are 10-30 characters long, are not
simple sentences or otherwise easily guessable (English prose has only
1-2 bits of entropy per character, and provides very bad passphrases),
and contain a mix of upper and lowercase letters, numbers, and non-
alphanumeric characters. The passphrase can be changed later by using
the -p option.
There is no way to recover a lost passphrase. If the passphrase is lost
or forgotten, a new key must be generated and the corresponding public
key copied to other machines.
For RSA1 keys, there is also a comment field in the key file that is only
for convenience to the user to help identify the key. The comment can
tell what the key is for, or whatever is useful. The comment is
initialized to M-bM-^@M-^\user@hostM-bM-^@M-^] when the key is created, but can be changed
using the -c option.
After a key is generated, instructions below detail where the keys should
be placed to be activated.
The options are as follows:
-A For each of the key types (rsa1, rsa, dsa, ecdsa and ed25519) for
which host keys do not exist, generate the host keys with the
default key file path, an empty passphrase, default bits for the
key type, and default comment. This is used by /etc/rc to
generate new host keys.
-a rounds
When saving a new-format private key (i.e. an ed25519 key or any
SSH protocol 2 key when the -o flag is set), this option
specifies the number of KDF (key derivation function) rounds
used. Higher numbers result in slower passphrase verification
and increased resistance to brute-force password cracking (should
the keys be stolen).
When screening DH-GEX candidates ( using the -T command). This
option specifies the number of primality tests to perform.
-B Show the bubblebabble digest of specified private or public key
file.
-b bits
Specifies the number of bits in the key to create. For RSA keys,
the minimum size is 1024 bits and the default is 2048 bits.
Generally, 2048 bits is considered sufficient. DSA keys must be
exactly 1024 bits as specified by FIPS 186-2. For ECDSA keys,
the -b flag determines the key length by selecting from one of
three elliptic curve sizes: 256, 384 or 521 bits. Attempting to
use bit lengths other than these three values for ECDSA keys will
fail. Ed25519 keys have a fixed length and the -b flag will be
ignored.
-C comment
Provides a new comment.
-c Requests changing the comment in the private and public key
files. This operation is only supported for RSA1 keys. The
program will prompt for the file containing the private keys, for
the passphrase if the key has one, and for the new comment.
-D pkcs11
Download the RSA public keys provided by the PKCS#11 shared
library pkcs11. When used in combination with -s, this option
indicates that a CA key resides in a PKCS#11 token (see the
CERTIFICATES section for details).
-E fingerprint_hash
Specifies the hash algorithm used when displaying key
fingerprints. Valid options are: M-bM-^@M-^\md5M-bM-^@M-^] and M-bM-^@M-^\sha256M-bM-^@M-^]. The
default is M-bM-^@M-^\sha256M-bM-^@M-^].
-e This option will read a private or public OpenSSH key file and
print to stdout the key in one of the formats specified by the -m
option. The default export format is M-bM-^@M-^\RFC4716M-bM-^@M-^]. This option
allows exporting OpenSSH keys for use by other programs,
including several commercial SSH implementations.
-F hostname
Search for the specified hostname in a known_hosts file, listing
any occurrences found. This option is useful to find hashed host
names or addresses and may also be used in conjunction with the
-H option to print found keys in a hashed format.
-f filename
Specifies the filename of the key file.
-G output_file
Generate candidate primes for DH-GEX. These primes must be
screened for safety (using the -T option) before use.
-g Use generic DNS format when printing fingerprint resource records
using the -r command.
-H Hash a known_hosts file. This replaces all hostnames and
addresses with hashed representations within the specified file;
the original content is moved to a file with a .old suffix.
These hashes may be used normally by ssh and sshd, but they do
not reveal identifying information should the file's contents be
disclosed. This option will not modify existing hashed hostnames
and is therefore safe to use on files that mix hashed and non-
hashed names.
-h When signing a key, create a host certificate instead of a user
certificate. Please see the CERTIFICATES section for details.
-I certificate_identity
Specify the key identity when signing a public key. Please see
the CERTIFICATES section for details.
-i This option will read an unencrypted private (or public) key file
in the format specified by the -m option and print an OpenSSH
compatible private (or public) key to stdout. This option allows
importing keys from other software, including several commercial
SSH implementations. The default import format is M-bM-^@M-^\RFC4716M-bM-^@M-^].
-J num_lines
Exit after screening the specified number of lines while
performing DH candidate screening using the -T option.
-j start_line
Start screening at the specified line number while performing DH
candidate screening using the -T option.
-K checkpt
Write the last line processed to the file checkpt while
performing DH candidate screening using the -T option. This will
be used to skip lines in the input file that have already been
processed if the job is restarted.
-k Generate a KRL file. In this mode, ssh-keygen will generate a
KRL file at the location specified via the -f flag that revokes
every key or certificate presented on the command line.
Keys/certificates to be revoked may be specified by public key
file or using the format described in the KEY REVOCATION LISTS
section.
-L Prints the contents of a certificate.
-l Show fingerprint of specified public key file. Private RSA1 keys
are also supported. For RSA and DSA keys ssh-keygen tries to
find the matching public key file and prints its fingerprint. If
combined with -v, an ASCII art representation of the key is
supplied with the fingerprint.
-M memory
Specify the amount of memory to use (in megabytes) when
generating candidate moduli for DH-GEX.
-m key_format
Specify a key format for the -i (import) or -e (export)
conversion options. The supported key formats are: M-bM-^@M-^\RFC4716M-bM-^@M-^]
(RFC 4716/SSH2 public or private key), M-bM-^@M-^\PKCS8M-bM-^@M-^] (PEM PKCS8 public
key) or M-bM-^@M-^\PEMM-bM-^@M-^] (PEM public key). The default conversion format is
M-bM-^@M-^\RFC4716M-bM-^@M-^].
-N new_passphrase
Provides the new passphrase.
-n principals
Specify one or more principals (user or host names) to be
included in a certificate when signing a key. Multiple
principals may be specified, separated by commas. Please see the
CERTIFICATES section for details.
-O option
Specify a certificate option when signing a key. This option may
be specified multiple times. Please see the CERTIFICATES section
for details. The options that are valid for user certificates
are:
clear Clear all enabled permissions. This is useful for
clearing the default set of permissions so permissions
may be added individually.
force-command=command
Forces the execution of command instead of any shell or
command specified by the user when the certificate is
used for authentication.
no-agent-forwarding
Disable ssh-agent(1) forwarding (permitted by default).
no-port-forwarding
Disable port forwarding (permitted by default).
no-pty Disable PTY allocation (permitted by default).
no-user-rc
Disable execution of ~/.ssh/rc by sshd(8) (permitted by
default).
no-x11-forwarding
Disable X11 forwarding (permitted by default).
permit-agent-forwarding
Allows ssh-agent(1) forwarding.
permit-port-forwarding
Allows port forwarding.
permit-pty
Allows PTY allocation.
permit-user-rc
Allows execution of ~/.ssh/rc by sshd(8).
permit-x11-forwarding
Allows X11 forwarding.
source-address=address_list
Restrict the source addresses from which the certificate
is considered valid. The address_list is a comma-
separated list of one or more address/netmask pairs in
CIDR format.
At present, no options are valid for host keys.
-o Causes ssh-keygen to save SSH protocol 2 private keys using the
new OpenSSH format rather than the more compatible PEM format.
The new format has increased resistance to brute-force password
cracking but is not supported by versions of OpenSSH prior to
6.5. Ed25519 keys always use the new private key format.
-P passphrase
Provides the (old) passphrase.
-p Requests changing the passphrase of a private key file instead of
creating a new private key. The program will prompt for the file
containing the private key, for the old passphrase, and twice for
the new passphrase.
-Q Test whether keys have been revoked in a KRL.
-q Silence ssh-keygen.
-R hostname
Removes all keys belonging to hostname from a known_hosts file.
This option is useful to delete hashed hosts (see the -H option
above).
-r hostname
Print the SSHFP fingerprint resource record named hostname for
the specified public key file.
-S start
Specify start point (in hex) when generating candidate moduli for
DH-GEX.
-s ca_key
Certify (sign) a public key using the specified CA key. Please
see the CERTIFICATES section for details.
When generating a KRL, -s specifies a path to a CA public key
file used to revoke certificates directly by key ID or serial
number. See the KEY REVOCATION LISTS section for details.
-T output_file
Test DH group exchange candidate primes (generated using the -G
option) for safety.
-t dsa | ecdsa | ed25519 | rsa | rsa1
Specifies the type of key to create. The possible values are
M-bM-^@M-^\rsa1M-bM-^@M-^] for protocol version 1 and M-bM-^@M-^\dsaM-bM-^@M-^], M-bM-^@M-^\ecdsaM-bM-^@M-^], M-bM-^@M-^\ed25519M-bM-^@M-^], or
M-bM-^@M-^\rsaM-bM-^@M-^] for protocol version 2.
-u Update a KRL. When specified with -k, keys listed via the
command line are added to the existing KRL rather than a new KRL
being created.
-V validity_interval
Specify a validity interval when signing a certificate. A
validity interval may consist of a single time, indicating that
the certificate is valid beginning now and expiring at that time,
or may consist of two times separated by a colon to indicate an
explicit time interval. The start time may be specified as a
date in YYYYMMDD format, a time in YYYYMMDDHHMMSS format or a
relative time (to the current time) consisting of a minus sign
followed by a relative time in the format described in the TIME
FORMATS section of sshd_config(5). The end time may be specified
as a YYYYMMDD date, a YYYYMMDDHHMMSS time or a relative time
starting with a plus character.
For example: M-bM-^@M-^\+52w1dM-bM-^@M-^] (valid from now to 52 weeks and one day
from now), M-bM-^@M-^\-4w:+4wM-bM-^@M-^] (valid from four weeks ago to four weeks
from now), M-bM-^@M-^\20100101123000:20110101123000M-bM-^@M-^] (valid from 12:30 PM,
January 1st, 2010 to 12:30 PM, January 1st, 2011), M-bM-^@M-^\-1d:20110101M-bM-^@M-^]
(valid from yesterday to midnight, January 1st, 2011).
-v Verbose mode. Causes ssh-keygen to print debugging messages
about its progress. This is helpful for debugging moduli
generation. Multiple -v options increase the verbosity. The
maximum is 3.
-W generator
Specify desired generator when testing candidate moduli for DH-
GEX.
-y This option will read a private OpenSSH format file and print an
OpenSSH public key to stdout.
-z serial_number
Specifies a serial number to be embedded in the certificate to
distinguish this certificate from others from the same CA. The
default serial number is zero.
When generating a KRL, the -z flag is used to specify a KRL
version number.
MODULI GENERATION
ssh-keygen may be used to generate groups for the Diffie-Hellman Group
Exchange (DH-GEX) protocol. Generating these groups is a two-step
process: first, candidate primes are generated using a fast, but memory
intensive process. These candidate primes are then tested for
suitability (a CPU-intensive process).
Generation of primes is performed using the -G option. The desired
length of the primes may be specified by the -b option. For example:
# ssh-keygen -G moduli-2048.candidates -b 2048
By default, the search for primes begins at a random point in the desired
length range. This may be overridden using the -S option, which
specifies a different start point (in hex).
Once a set of candidates have been generated, they must be screened for
suitability. This may be performed using the -T option. In this mode
ssh-keygen will read candidates from standard input (or a file specified
using the -f option). For example:
# ssh-keygen -T moduli-2048 -f moduli-2048.candidates
By default, each candidate will be subjected to 100 primality tests.
This may be overridden using the -a option. The DH generator value will
be chosen automatically for the prime under consideration. If a specific
generator is desired, it may be requested using the -W option. Valid
generator values are 2, 3, and 5.
Screened DH groups may be installed in /etc/moduli. It is important that
this file contains moduli of a range of bit lengths and that both ends of
a connection share common moduli.
CERTIFICATES
ssh-keygen supports signing of keys to produce certificates that may be
used for user or host authentication. Certificates consist of a public
key, some identity information, zero or more principal (user or host)
names and a set of options that are signed by a Certification Authority
(CA) key. Clients or servers may then trust only the CA key and verify
its signature on a certificate rather than trusting many user/host keys.
Note that OpenSSH certificates are a different, and much simpler, format
to the X.509 certificates used in ssl(8).
ssh-keygen supports two types of certificates: user and host. User
certificates authenticate users to servers, whereas host certificates
authenticate server hosts to users. To generate a user certificate:
$ ssh-keygen -s /path/to/ca_key -I key_id /path/to/user_key.pub
The resultant certificate will be placed in /path/to/user_key-cert.pub.
A host certificate requires the -h option:
$ ssh-keygen -s /path/to/ca_key -I key_id -h /path/to/host_key.pub
The host certificate will be output to /path/to/host_key-cert.pub.
It is possible to sign using a CA key stored in a PKCS#11 token by
providing the token library using -D and identifying the CA key by
providing its public half as an argument to -s:
$ ssh-keygen -s ca_key.pub -D libpkcs11.so -I key_id host_key.pub
In all cases, key_id is a "key identifier" that is logged by the server
when the certificate is used for authentication.
Certificates may be limited to be valid for a set of principal
(user/host) names. By default, generated certificates are valid for all
users or hosts. To generate a certificate for a specified set of
principals:
$ ssh-keygen -s ca_key -I key_id -n user1,user2 user_key.pub
$ ssh-keygen -s ca_key -I key_id -h -n host.domain user_key.pub
Additional limitations on the validity and use of user certificates may
be specified through certificate options. A certificate option may
disable features of the SSH session, may be valid only when presented
from particular source addresses or may force the use of a specific
command. For a list of valid certificate options, see the documentation
for the -O option above.
Finally, certificates may be defined with a validity lifetime. The -V
option allows specification of certificate start and end times. A
certificate that is presented at a time outside this range will not be
considered valid. By default, certificates are valid from UNIX Epoch to
the distant future.
For certificates to be used for user or host authentication, the CA
public key must be trusted by sshd(8) or ssh(1). Please refer to those
manual pages for details.
KEY REVOCATION LISTS
ssh-keygen is able to manage OpenSSH format Key Revocation Lists (KRLs).
These binary files specify keys or certificates to be revoked using a
compact format, taking as little as one bit per certificate if they are
being revoked by serial number.
KRLs may be generated using the -k flag. This option reads one or more
files from the command line and generates a new KRL. The files may
either contain a KRL specification (see below) or public keys, listed one
per line. Plain public keys are revoked by listing their hash or
contents in the KRL and certificates revoked by serial number or key ID
(if the serial is zero or not available).
Revoking keys using a KRL specification offers explicit control over the
types of record used to revoke keys and may be used to directly revoke
certificates by serial number or key ID without having the complete
original certificate on hand. A KRL specification consists of lines
containing one of the following directives followed by a colon and some
directive-specific information.
serial: serial_number[-serial_number]
Revokes a certificate with the specified serial number. Serial
numbers are 64-bit values, not including zero and may be
expressed in decimal, hex or octal. If two serial numbers are
specified separated by a hyphen, then the range of serial numbers
including and between each is revoked. The CA key must have been
specified on the ssh-keygen command line using the -s option.
id: key_id
Revokes a certificate with the specified key ID string. The CA
key must have been specified on the ssh-keygen command line using
the -s option.
key: public_key
Revokes the specified key. If a certificate is listed, then it
is revoked as a plain public key.
sha1: public_key
Revokes the specified key by its SHA1 hash.
KRLs may be updated using the -u flag in addition to -k. When this
option is specified, keys listed via the command line are merged into the
KRL, adding to those already there.
It is also possible, given a KRL, to test whether it revokes a particular
key (or keys). The -Q flag will query an existing KRL, testing each key
specified on the commandline. If any key listed on the command line has
been revoked (or an error encountered) then ssh-keygen will exit with a
non-zero exit status. A zero exit status will only be returned if no key
was revoked.
FILES
~/.ssh/identity
Contains the protocol version 1 RSA authentication identity of
the user. This file should not be readable by anyone but the
user. It is possible to specify a passphrase when generating the
key; that passphrase will be used to encrypt the private part of
this file using 3DES. This file is not automatically accessed by
ssh-keygen but it is offered as the default file for the private
key. ssh(1) will read this file when a login attempt is made.
~/.ssh/identity.pub
Contains the protocol version 1 RSA public key for
authentication. The contents of this file should be added to
~/.ssh/authorized_keys on all machines where the user wishes to
log in using RSA authentication. There is no need to keep the
contents of this file secret.
~/.ssh/id_dsa
~/.ssh/id_ecdsa
~/.ssh/id_ed25519
~/.ssh/id_rsa
Contains the protocol version 2 DSA, ECDSA, Ed25519 or RSA
authentication identity of the user. This file should not be
readable by anyone but the user. It is possible to specify a
passphrase when generating the key; that passphrase will be used
to encrypt the private part of this file using 128-bit AES. This
file is not automatically accessed by ssh-keygen but it is
offered as the default file for the private key. ssh(1) will
read this file when a login attempt is made.
~/.ssh/id_dsa.pub
~/.ssh/id_ecdsa.pub
~/.ssh/id_ed25519.pub
~/.ssh/id_rsa.pub
Contains the protocol version 2 DSA, ECDSA, Ed25519 or RSA public
key for authentication. The contents of this file should be
added to ~/.ssh/authorized_keys on all machines where the user
wishes to log in using public key authentication. There is no
need to keep the contents of this file secret.
/etc/moduli
Contains Diffie-Hellman groups used for DH-GEX. The file format
is described in moduli(5).
SEE ALSO
ssh(1), ssh-add(1), ssh-agent(1), moduli(5), sshd(8)
The Secure Shell (SSH) Public Key File Format, RFC 4716, 2006.
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.
OpenBSD 5.8 July 3, 2015 OpenBSD 5.8

109
crypto/openssh/ssh-keyscan.0
View File

@ -1,109 +0,0 @@
SSH-KEYSCAN(1) General Commands Manual SSH-KEYSCAN(1)
NAME
ssh-keyscan M-bM-^@M-^S gather ssh public keys
SYNOPSIS
ssh-keyscan [-46Hv] [-f file] [-p port] [-T timeout] [-t type]
[host | addrlist namelist] ...
DESCRIPTION
ssh-keyscan is a utility for gathering the public ssh host keys of a
number of hosts. It was designed to aid in building and verifying
ssh_known_hosts files. ssh-keyscan provides a minimal interface suitable
for use by shell and perl scripts.
ssh-keyscan uses non-blocking socket I/O to contact as many hosts as
possible in parallel, so it is very efficient. The keys from a domain of
1,000 hosts can be collected in tens of seconds, even when some of those
hosts are down or do not run ssh. For scanning, one does not need login
access to the machines that are being scanned, nor does the scanning
process involve any encryption.
The options are as follows:
-4 Forces ssh-keyscan to use IPv4 addresses only.
-6 Forces ssh-keyscan to use IPv6 addresses only.
-f file
Read hosts or M-bM-^@M-^\addrlist namelistM-bM-^@M-^] pairs from file, one per line.
If - is supplied instead of a filename, ssh-keyscan will read
hosts or M-bM-^@M-^\addrlist namelistM-bM-^@M-^] pairs from the standard input.
-H Hash all hostnames and addresses in the output. Hashed names may
be used normally by ssh and sshd, but they do not reveal
identifying information should the file's contents be disclosed.
-p port
Port to connect to on the remote host.
-T timeout
Set the timeout for connection attempts. If timeout seconds have
elapsed since a connection was initiated to a host or since the
last time anything was read from that host, then the connection
is closed and the host in question considered unavailable.
Default is 5 seconds.
-t type
Specifies the type of the key to fetch from the scanned hosts.
The possible values are M-bM-^@M-^\rsa1M-bM-^@M-^] for protocol version 1 and M-bM-^@M-^\dsaM-bM-^@M-^],
M-bM-^@M-^\ecdsaM-bM-^@M-^], M-bM-^@M-^\ed25519M-bM-^@M-^], or M-bM-^@M-^\rsaM-bM-^@M-^] for protocol version 2. Multiple
values may be specified by separating them with commas. The
default is to fetch M-bM-^@M-^\rsaM-bM-^@M-^], M-bM-^@M-^\ecdsaM-bM-^@M-^], and M-bM-^@M-^\ed25519M-bM-^@M-^] keys.
-v Verbose mode. Causes ssh-keyscan to print debugging messages
about its progress.
SECURITY
If an ssh_known_hosts file is constructed using ssh-keyscan without
verifying the keys, users will be vulnerable to man in the middle
attacks. On the other hand, if the security model allows such a risk,
ssh-keyscan can help in the detection of tampered keyfiles or man in the
middle attacks which have begun after the ssh_known_hosts file was
created.
FILES
Input format:
1.2.3.4,1.2.4.4 name.my.domain,name,n.my.domain,n,1.2.3.4,1.2.4.4
Output format for RSA1 keys:
host-or-namelist bits exponent modulus
Output format for RSA, DSA, ECDSA, and Ed25519 keys:
host-or-namelist keytype base64-encoded-key
Where keytype is either M-bM-^@M-^\ecdsa-sha2-nistp256M-bM-^@M-^], M-bM-^@M-^\ecdsa-sha2-nistp384M-bM-^@M-^],
M-bM-^@M-^\ecdsa-sha2-nistp521M-bM-^@M-^], M-bM-^@M-^\ssh-ed25519M-bM-^@M-^], M-bM-^@M-^\ssh-dssM-bM-^@M-^] or M-bM-^@M-^\ssh-rsaM-bM-^@M-^].
/etc/ssh/ssh_known_hosts
EXAMPLES
Print the rsa host key for machine hostname:
$ ssh-keyscan hostname
Find all hosts from the file ssh_hosts which have new or different keys
from those in the sorted file ssh_known_hosts:
$ ssh-keyscan -t rsa,dsa,ecdsa,ed25519 -f ssh_hosts | \
sort -u - ssh_known_hosts | diff ssh_known_hosts -
SEE ALSO
ssh(1), sshd(8)
AUTHORS
David Mazieres <dm@lcs.mit.edu> wrote the initial version, and Wayne
Davison <wayned@users.sourceforge.net> added support for protocol version
2.
BUGS
It generates "Connection closed by remote host" messages on the consoles
of all the machines it scans if the server is older than version 2.9.
This is because it opens a connection to the ssh port, reads the public
key, and drops the connection as soon as it gets the key.
OpenBSD 5.8 August 30, 2014 OpenBSD 5.8

53
crypto/openssh/ssh-keysign.0
View File

@ -1,53 +0,0 @@
SSH-KEYSIGN(8) System Manager's Manual SSH-KEYSIGN(8)
NAME
ssh-keysign M-bM-^@M-^S ssh helper program for host-based authentication
SYNOPSIS
ssh-keysign
DESCRIPTION
ssh-keysign is used by ssh(1) to access the local host keys and generate
the digital signature required during host-based authentication with SSH
protocol version 2.
ssh-keysign is disabled by default and can only be enabled in the global
client configuration file /etc/ssh/ssh_config by setting EnableSSHKeysign
to M-bM-^@M-^\yesM-bM-^@M-^].
ssh-keysign is not intended to be invoked by the user, but from ssh(1).
See ssh(1) and sshd(8) for more information about host-based
authentication.
FILES
/etc/ssh/ssh_config
Controls whether ssh-keysign is enabled.
/etc/ssh/ssh_host_dsa_key
/etc/ssh/ssh_host_ecdsa_key
/etc/ssh/ssh_host_ed25519_key
/etc/ssh/ssh_host_rsa_key
These files contain the private parts of the host keys used to
generate the digital signature. They should be owned by root,
readable only by root, and not accessible to others. Since they
are readable only by root, ssh-keysign must be set-uid root if
host-based authentication is used.
/etc/ssh/ssh_host_dsa_key-cert.pub
/etc/ssh/ssh_host_ecdsa_key-cert.pub
/etc/ssh/ssh_host_ed25519_key-cert.pub
/etc/ssh/ssh_host_rsa_key-cert.pub
If these files exist they are assumed to contain public
certificate information corresponding with the private keys
above.
SEE ALSO
ssh(1), ssh-keygen(1), ssh_config(5), sshd(8)
HISTORY
ssh-keysign first appeared in OpenBSD 3.2.
AUTHORS
Markus Friedl <markus@openbsd.org>
OpenBSD 5.8 December 7, 2013 OpenBSD 5.8

25
crypto/openssh/ssh-pkcs11-helper.0
View File

@ -1,25 +0,0 @@
SSH-PKCS11-HELPER(8) System Manager's Manual SSH-PKCS11-HELPER(8)
NAME
ssh-pkcs11-helper M-bM-^@M-^S ssh-agent helper program for PKCS#11 support
SYNOPSIS
ssh-pkcs11-helper
DESCRIPTION
ssh-pkcs11-helper is used by ssh-agent(1) to access keys provided by a
PKCS#11 token.
ssh-pkcs11-helper is not intended to be invoked by the user, but from
ssh-agent(1).
SEE ALSO
ssh(1), ssh-add(1), ssh-agent(1)
HISTORY
ssh-pkcs11-helper first appeared in OpenBSD 4.7.
AUTHORS
Markus Friedl <markus@openbsd.org>
OpenBSD 5.8 July 16, 2013 OpenBSD 5.8

972
crypto/openssh/ssh.0
View File

@ -1,972 +0,0 @@
SSH(1) General Commands Manual SSH(1)
NAME
ssh M-bM-^@M-^S OpenSSH SSH client (remote login program)
SYNOPSIS
ssh [-1246AaCfGgKkMNnqsTtVvXxYy] [-b bind_address] [-c cipher_spec]
[-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]
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.
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).
If command is specified, it is executed on the remote host instead of a
login shell.
The options are as follows:
-1 Forces ssh to try protocol version 1 only.
-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.
-A Enables forwarding of the authentication agent connection. This
can also be specified on a per-host basis in a configuration
file.
Agent forwarding should be enabled with caution. Users with the
ability to bypass file permissions on the remote host (for the
agent's UNIX-domain socket) can access the local agent through
the forwarded connection. An attacker cannot obtain key material
from the agent, however they can perform operations on the keys
that enable them to authenticate using the identities loaded into
the agent.
-a Disables forwarding of the authentication agent connection.
-b bind_address
Use bind_address on the local machine as the source address of
the connection. Only useful on systems with more than one
address.
-C Requests compression of all data (including stdin, stdout,
stderr, and data for forwarded X11, TCP and UNIX-domain
connections). The compression algorithm is the same used by
gzip(1), and the M-bM-^@M-^\levelM-bM-^@M-^] can be controlled by the
CompressionLevel option for protocol version 1. 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 configuration files; see the
Compression option.
-c cipher_spec
Selects the cipher specification for encrypting the session.
Protocol version 1 allows specification of a single cipher. The
supported values are M-bM-^@M-^\3desM-bM-^@M-^], M-bM-^@M-^\blowfishM-bM-^@M-^], and M-bM-^@M-^\desM-bM-^@M-^]. For protocol
version 2, cipher_spec is a comma-separated list of ciphers
listed in order of preference. See the Ciphers keyword in
ssh_config(5) for more information.
-D [bind_address:]port
Specifies a local M-bM-^@M-^\dynamicM-bM-^@M-^] application-level port forwarding.
This works by allocating a socket to listen to port on the local
side, optionally bound to the specified bind_address. Whenever a
connection is made to this port, the connection is forwarded over
the secure channel, and the application protocol is then used to
determine where to connect to from the remote machine. Currently
the SOCKS4 and SOCKS5 protocols are supported, and ssh will act
as a SOCKS server. Only root can forward privileged ports.
Dynamic port forwardings can also be specified in the
configuration file.
IPv6 addresses can be specified by enclosing the address in
square brackets. Only the superuser can forward privileged
ports. By default, the local port is bound in accordance with
the GatewayPorts setting. However, an explicit bind_address may
be used to bind the connection to a specific address. The
bind_address of M-bM-^@M-^\localhostM-bM-^@M-^] indicates that the listening port be
bound for local use only, while an empty address or M-bM-^@M-^X*M-bM-^@M-^Y indicates
that the port should be available from all interfaces.
-E log_file
Append debug logs to log_file instead of standard error.
-e escape_char
Sets the escape character for sessions with a pty (default: M-bM-^@M-^X~M-bM-^@M-^Y).
The escape character is only recognized at the beginning of a
line. The escape character followed by a dot (M-bM-^@M-^X.M-bM-^@M-^Y) closes the
connection; followed by control-Z suspends the connection; and
followed by itself sends the escape character once. Setting the
character to M-bM-^@M-^\noneM-bM-^@M-^] disables any escapes and makes the session
fully transparent.
-F configfile
Specifies an alternative per-user configuration file. If a
configuration file is given on the command line, the system-wide
configuration file (/etc/ssh/ssh_config) will be ignored. The
default for the per-user configuration file is ~/.ssh/config.
-f Requests ssh to go to background just before command execution.
This is useful if ssh is going to ask for passwords or
passphrases, 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.
If the ExitOnForwardFailure configuration option is set to M-bM-^@M-^\yesM-bM-^@M-^],
then a client started with -f will wait for all remote port
forwards to be successfully established before placing itself in
the background.
-G Causes ssh to print its configuration after evaluating Host and
Match blocks and exit.
-g Allows remote hosts to connect to local forwarded ports. If used
on a multiplexed connection, then this option must be specified
on the master process.
-I pkcs11
Specify the PKCS#11 shared library ssh should use to communicate
with a PKCS#11 token providing the user's private RSA key.
-i identity_file
Selects a file from which the identity (private key) for public
key authentication is read. The default is ~/.ssh/identity for
protocol version 1, and ~/.ssh/id_dsa, ~/.ssh/id_ecdsa,
~/.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.
-K Enables GSSAPI-based authentication and forwarding (delegation)
of GSSAPI credentials to the server.
-k Disables forwarding (delegation) of GSSAPI credentials to the
server.
-L [bind_address:]port:host:hostport
-L [bind_address:]port:remote_socket
-L local_socket:host:hostport
-L local_socket:remote_socket
Specifies that connections to the given TCP port or Unix socket
on the local (client) host are to be forwarded to the given host
and port, or Unix socket, on the remote side. This works by
allocating a socket to listen to either a TCP port on the local
side, optionally bound to the specified bind_address, or to a
Unix socket. Whenever a connection is made to the local port or
socket, the connection is forwarded over the secure channel, and
a connection is made to either host port hostport, or the Unix
socket remote_socket, from the remote machine.
Port forwardings can also be specified in the configuration file.
Only the superuser can forward privileged ports. IPv6 addresses
can be specified by enclosing the address in square brackets.
By default, the local port is bound in accordance with the
GatewayPorts setting. However, an explicit bind_address may be
used to bind the connection to a specific address. The
bind_address of M-bM-^@M-^\localhostM-bM-^@M-^] indicates that the listening port be
bound for local use only, while an empty address or M-bM-^@M-^X*M-bM-^@M-^Y indicates
that the port should be available from all interfaces.
-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.
-M Places the ssh client into M-bM-^@M-^\masterM-bM-^@M-^] mode for connection sharing.
Multiple -M options places ssh into M-bM-^@M-^\masterM-bM-^@M-^] mode with
confirmation required before slave connections are accepted.
Refer to the description of ControlMaster in ssh_config(5) for
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.
-N Do not execute a remote command. This is useful for just
forwarding ports (protocol version 2 only).
-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
machine. For example, ssh -n shadows.cs.hut.fi emacs & will
start an emacs on shadows.cs.hut.fi, and the X11 connection will
be automatically 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.)
-O ctl_cmd
Control an active connection multiplexing master process. When
the -O option is specified, the ctl_cmd argument is interpreted
and passed to the master process. Valid commands are: M-bM-^@M-^\checkM-bM-^@M-^]
(check that the master process is running), M-bM-^@M-^\forwardM-bM-^@M-^] (request
forwardings without command execution), M-bM-^@M-^\cancelM-bM-^@M-^] (cancel
forwardings), M-bM-^@M-^\exitM-bM-^@M-^] (request the master to exit), and M-bM-^@M-^\stopM-bM-^@M-^]
(request the master to stop accepting further multiplexing
requests).
-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. For full details
of the options listed below, and their possible values, see
ssh_config(5).
AddressFamily
BatchMode
BindAddress
CanonicalDomains
CanonicalizeFallbackLocal
CanonicalizeHostname
CanonicalizeMaxDots
CanonicalizePermittedCNAMEs
ChallengeResponseAuthentication
CheckHostIP
Cipher
Ciphers
ClearAllForwardings
Compression
CompressionLevel
ConnectionAttempts
ConnectTimeout
ControlMaster
ControlPath
ControlPersist
DynamicForward
EscapeChar
ExitOnForwardFailure
FingerprintHash
ForwardAgent
ForwardX11
ForwardX11Timeout
ForwardX11Trusted
GatewayPorts
GlobalKnownHostsFile
GSSAPIAuthentication
GSSAPIDelegateCredentials
HashKnownHosts
Host
HostbasedAuthentication
HostbasedKeyTypes
HostKeyAlgorithms
HostKeyAlias
HostName
IdentityFile
IdentitiesOnly
IPQoS
KbdInteractiveAuthentication
KbdInteractiveDevices
KexAlgorithms
LocalCommand
LocalForward
LogLevel
MACs
Match
NoHostAuthenticationForLocalhost
NumberOfPasswordPrompts
PasswordAuthentication
PermitLocalCommand
PKCS11Provider
Port
PreferredAuthentications
Protocol
ProxyCommand
ProxyUseFdpass
PubkeyAcceptedKeyTypes
PubkeyAuthentication
RekeyLimit
RemoteForward
RequestTTY
RhostsRSAAuthentication
RSAAuthentication
SendEnv
ServerAliveInterval
ServerAliveCountMax
StreamLocalBindMask
StreamLocalBindUnlink
StrictHostKeyChecking
TCPKeepAlive
Tunnel
TunnelDevice
UpdateHostKeys
UsePrivilegedPort
User
UserKnownHostsFile
VerifyHostKeyDNS
VisualHostKey
XAuthLocation
-p port
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
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).
-q Quiet mode. Causes most warning and diagnostic messages to be
suppressed.
-R [bind_address:]port:host:hostport
-R [bind_address:]port:local_socket
-R remote_socket:host:hostport
-R remote_socket:local_socket
Specifies that connections to the given TCP port or Unix socket
on the remote (server) host are to be forwarded to the given host
and port, or Unix socket, on the local side. This works by
allocating a socket to listen to either a TCP port or to a Unix
socket on the remote side. Whenever a connection is made to this
port or Unix socket, the connection is forwarded over the secure
channel, and a connection is made to either host port hostport,
or local_socket, from the local machine.
Port forwardings can also be specified in the configuration file.
Privileged ports can be forwarded only when logging in as root on
the remote machine. IPv6 addresses can be specified by enclosing
the address in square brackets.
By default, TCP listening sockets on the server will be bound to
the loopback interface only. This may be overridden by
specifying a bind_address. An empty bind_address, or the address
M-bM-^@M-^X*M-bM-^@M-^Y, indicates that the remote socket should listen on all
interfaces. Specifying a remote bind_address will only succeed
if the server's GatewayPorts option is enabled (see
sshd_config(5)).
If the port argument is M-bM-^@M-^X0M-bM-^@M-^Y, the listen port will be dynamically
allocated on the server and reported to the client at run time.
When used together with -O forward the allocated port will be
printed to the standard output.
-S ctl_path
Specifies the location of a control socket for connection
sharing, or the string M-bM-^@M-^\noneM-bM-^@M-^] to disable connection sharing.
Refer to the description of ControlPath and ControlMaster in
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.
-T Disable pseudo-terminal allocation.
-t Force pseudo-terminal allocation. This can be used to execute
arbitrary screen-based programs on a remote machine, which can be
very useful, e.g. when implementing menu services. Multiple -t
options force tty allocation, even if ssh has no local tty.
-V Display the version number and exit.
-v Verbose mode. Causes ssh to print debugging messages about its
progress. This is helpful in debugging connection,
authentication, and configuration problems. Multiple -v options
increase the verbosity. The maximum is 3.
-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.
-w local_tun[:remote_tun]
Requests tunnel device forwarding with the specified tun(4)
devices between the client (local_tun) and the server
(remote_tun).
The devices may be specified by numerical ID or the keyword
M-bM-^@M-^\anyM-bM-^@M-^], which uses the next available tunnel device. If
remote_tun is not specified, it defaults to M-bM-^@M-^\anyM-bM-^@M-^]. See also the
Tunnel and TunnelDevice directives in ssh_config(5). If the
Tunnel directive is unset, it is set to the default tunnel mode,
which is M-bM-^@M-^\point-to-pointM-bM-^@M-^].
-X Enables X11 forwarding. This can also be specified on a per-host
basis in a configuration file.
X11 forwarding should be enabled with caution. Users with the
ability to bypass file permissions on the remote host (for the
user's X authorization database) can access the local X11 display
through the forwarded connection. An attacker may then be able
to perform activities such as keystroke monitoring.
For this reason, X11 forwarding is subjected to X11 SECURITY
extension restrictions by default. Please refer to the ssh -Y
option and the ForwardX11Trusted directive in ssh_config(5) for
more information.
-x Disables X11 forwarding.
-Y Enables trusted X11 forwarding. Trusted X11 forwardings are not
subjected to the X11 SECURITY extension controls.
-y Send log information using the syslog(3) system module. By
default this information is sent to stderr.
ssh may additionally obtain configuration data from a per-user
configuration file and a system-wide configuration file. The file format
and configuration options are described in ssh_config(5).
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.
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.
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
machine, and the user names are the same on both sides, or if the files
~/.rhosts or ~/.shosts exist in the user's home directory on the remote
machine and contain a line containing the name of the client machine and
the name of the user on that machine, the user is considered for login.
Additionally, the server must be able to verify the client's host key
(see the description of /etc/ssh/ssh_known_hosts and ~/.ssh/known_hosts,
below) for login to be permitted. This authentication method closes
security holes due to IP spoofing, DNS spoofing, and routing spoofing.
[Note to the administrator: /etc/hosts.equiv, ~/.rhosts, and the
rlogin/rsh protocol in general, are inherently insecure and should be
disabled if security is desired.]
Public key authentication works as follows: The scheme is based on
public-key cryptography, using cryptosystems where encryption and
decryption are done using separate keys, and it is unfeasible to derive
the decryption key from the encryption key. 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.
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.
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
which key pair it would like to use for authentication. The client
proves that it has access to the private key and the server checks that
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
~/.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,
the user can log in without giving the password.
A variation on public key authentication is available in the form of
certificate authentication: instead of a set of public/private keys,
signed certificates are used. This has the advantage that a single
trusted certification authority can be used in place of many
public/private keys. See the CERTIFICATES section of ssh-keygen(1) for
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.
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).
Finally, if other authentication methods fail, ssh prompts the user for a
password. 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 automatically maintains and checks a database containing
identification for all hosts it has ever been used with. Host keys are
stored in ~/.ssh/known_hosts in the user's home directory. Additionally,
the file /etc/ssh/ssh_known_hosts is 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 server spoofing or man-in-the-middle
attacks, which could otherwise be used to circumvent the encryption. The
StrictHostKeyChecking option can be used to control logins to machines
whose host key is not known or has changed.
When the user's identity has been accepted by the server, the server
either executes the given command in a non-interactive session or, if no
command has been specified, logs into the machine and gives the user a
normal shell as an interactive session. All communication with the
remote command or shell will be automatically encrypted.
If an interactive session is requested ssh by default will only request a
pseudo-terminal (pty) for interactive sessions when the client has one.
The flags -T and -t can be used to override this behaviour.
If a pseudo-terminal has been allocated the user may use the escape
characters noted below.
If no pseudo-terminal has been allocated, the session is transparent and
can be used to reliably transfer binary data. On most systems, setting
the escape character to M-bM-^@M-^\noneM-bM-^@M-^] will also make the session transparent
even if a tty is used.
The session terminates when the command or shell on the remote machine
exits and all X11 and TCP connections have been closed.
ESCAPE CHARACTERS
When a pseudo-terminal has been requested, ssh supports a number of
functions through the use of an escape character.
A single tilde character can be sent as ~~ or by following the tilde by a
character other than those described below. The escape character must
always follow a newline to be interpreted as special. The escape
character can be changed in configuration files using the EscapeChar
configuration directive or on the command line by the -e option.
The supported escapes (assuming the default M-bM-^@M-^X~M-bM-^@M-^Y) are:
~. Disconnect.
~^Z Background ssh.
~# List forwarded connections.
~& Background ssh at logout when waiting for forwarded connection /
X11 sessions to terminate.
~? 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).
~C Open command line. Currently this allows the addition of port
forwardings using the -L, -R and -D options (see above). It also
allows the cancellation of existing port-forwardings with
-KL[bind_address:]port for local, -KR[bind_address:]port for
remote and -KD[bind_address:]port for dynamic port-forwardings.
!command allows the user to execute a local command if the
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).
~V Decrease the verbosity (LogLevel) when errors are being written
to stderr.
~v Increase the verbosity (LogLevel) when errors are being written
to stderr.
TCP FORWARDING
Forwarding of arbitrary TCP connections over the secure channel can be
specified either on the command line or in a configuration file. One
possible application of TCP forwarding is a secure connection to a mail
server; another is going through firewalls.
In the example below, we look at encrypting communication between an IRC
client and server, even though the IRC server does not directly support
encrypted communications. This works as follows: the user connects to
the remote host using ssh, specifying a port to be used to forward
connections to the remote server. After that it is possible to start the
service which is to be encrypted on the client machine, connecting to the
same local port, and ssh will encrypt and forward the connection.
The following example tunnels an IRC session from client machine
M-bM-^@M-^\127.0.0.1M-bM-^@M-^] (localhost) to remote server M-bM-^@M-^\server.example.comM-bM-^@M-^]:
$ ssh -f -L 1234:localhost:6667 server.example.com sleep 10
$ irc -c '#users' -p 1234 pinky 127.0.0.1
This tunnels a connection to IRC server M-bM-^@M-^\server.example.comM-bM-^@M-^], joining
channel M-bM-^@M-^\#usersM-bM-^@M-^], nickname M-bM-^@M-^\pinkyM-bM-^@M-^], using port 1234. It doesn't matter
which port is used, as long as it's greater than 1023 (remember, only
root can open sockets on privileged ports) and doesn't conflict with any
ports already in use. The connection is forwarded to port 6667 on the
remote server, since that's the standard port for IRC services.
The -f option backgrounds ssh and the remote command M-bM-^@M-^\sleep 10M-bM-^@M-^] is
specified to allow an amount of time (10 seconds, in the example) to
start the service which is to be tunnelled. If no connections are made
within the time specified, ssh will exit.
X11 FORWARDING
If the ForwardX11 variable is set to M-bM-^@M-^\yesM-bM-^@M-^] (or see the description of the
-X, -x, and -Y options above) and 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 command) 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 M-bM-^@M-^\proxyM-bM-^@M-^] 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 ForwardAgent variable is set to M-bM-^@M-^\yesM-bM-^@M-^] (or see the description of
the -A and -a options above) and the user is using an authentication
agent, the connection to the agent is automatically forwarded to the
remote side.
VERIFYING HOST KEYS
When connecting to a server for the first time, a fingerprint of the
server's public key is presented to the user (unless the option
StrictHostKeyChecking has been disabled). Fingerprints can be determined
using ssh-keygen(1):
$ ssh-keygen -l -f /etc/ssh/ssh_host_rsa_key
If the fingerprint is already known, it can be matched and the key can be
accepted or rejected. If only legacy (MD5) fingerprints for the server
are available, the ssh-keygen(1) -E option may be used to downgrade the
fingerprint algorithm to match.
Because of the difficulty of comparing host keys just by looking at
fingerprint strings, there is also support to compare host keys visually,
using random art. By setting the VisualHostKey option to M-bM-^@M-^\yesM-bM-^@M-^], a small
ASCII graphic gets displayed on every login to a server, no matter if the
session itself is interactive or not. By learning the pattern a known
server produces, a user can easily find out that the host key has changed
when a completely different pattern is displayed. Because these patterns
are not unambiguous however, a pattern that looks similar to the pattern
remembered only gives a good probability that the host key is the same,
not guaranteed proof.
To get a listing of the fingerprints along with their random art for all
known hosts, the following command line can be used:
$ ssh-keygen -lv -f ~/.ssh/known_hosts
If the fingerprint is unknown, an alternative method of verification is
available: SSH fingerprints verified by DNS. An additional resource
record (RR), SSHFP, is added to a zonefile and the connecting client is
able to match the fingerprint with that of the key presented.
In this example, we are connecting a client to a server,
M-bM-^@M-^\host.example.comM-bM-^@M-^]. The SSHFP resource records should first be added to
the zonefile for host.example.com:
$ ssh-keygen -r host.example.com.
The output lines will have to be added to the zonefile. To check that
the zone is answering fingerprint queries:
$ dig -t SSHFP host.example.com
Finally the client connects:
$ ssh -o "VerifyHostKeyDNS ask" host.example.com
[...]
Matching host key fingerprint found in DNS.
Are you sure you want to continue connecting (yes/no)?
See the VerifyHostKeyDNS option in ssh_config(5) for more information.
SSH-BASED VIRTUAL PRIVATE NETWORKS
ssh contains support for Virtual Private Network (VPN) tunnelling using
the tun(4) network pseudo-device, allowing two networks to be joined
securely. The sshd_config(5) configuration option PermitTunnel controls
whether the server supports this, and at what level (layer 2 or 3
traffic).
The following example would connect client network 10.0.50.0/24 with
remote network 10.0.99.0/24 using a point-to-point connection from
10.1.1.1 to 10.1.1.2, provided that the SSH server running on the gateway
to the remote network, at 192.168.1.15, allows it.
On the client:
# ssh -f -w 0:1 192.168.1.15 true
# ifconfig tun0 10.1.1.1 10.1.1.2 netmask 255.255.255.252
# route add 10.0.99.0/24 10.1.1.2
On the server:
# ifconfig tun1 10.1.1.2 10.1.1.1 netmask 255.255.255.252
# route add 10.0.50.0/24 10.1.1.1
Client access may be more finely tuned via the /root/.ssh/authorized_keys
file (see below) and the PermitRootLogin server option. The following
entry would permit connections on tun(4) device 1 from user M-bM-^@M-^\janeM-bM-^@M-^] and on
tun device 2 from user M-bM-^@M-^\johnM-bM-^@M-^], if PermitRootLogin is set to
M-bM-^@M-^\forced-commands-onlyM-bM-^@M-^]:
tunnel="1",command="sh /etc/netstart tun1" ssh-rsa ... jane
tunnel="2",command="sh /etc/netstart tun2" ssh-rsa ... john
Since an SSH-based setup entails a fair amount of overhead, it may be
more suited to temporary setups, such as for wireless VPNs. More
permanent VPNs are better provided by tools such as ipsecctl(8) and
isakmpd(8).
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 M-bM-^@M-^\hostname:nM-bM-^@M-^], where
M-bM-^@M-^\hostnameM-bM-^@M-^] indicates the host where the shell runs,
and M-bM-^@M-^XnM-bM-^@M-^Y is an integer M-bM-^IM-% 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 the path of the user's mailbox.
PATH Set to the default PATH, as specified when
compiling ssh.
SSH_ASKPASS If ssh needs a passphrase, it will read the
passphrase from the current terminal if it was run
from a terminal. If ssh does not have a terminal
associated with it but DISPLAY and SSH_ASKPASS are
set, it will execute the program specified by
SSH_ASKPASS and open an X11 window to read the
passphrase. This is particularly useful when
calling ssh from a .xsession or related script.
(Note that on some machines it may be necessary to
redirect the input from /dev/null to make this
work.)
SSH_AUTH_SOCK Identifies the path of a UNIX-domain socket used to
communicate with the agent.
SSH_CONNECTION Identifies the client and server ends of the
connection. The variable contains four space-
separated values: client IP address, client port
number, server IP address, and server port number.
SSH_ORIGINAL_COMMAND This variable contains the original command line if
a forced command is executed. It can be used to
extract the original arguments.
SSH_TTY This is set to the name of the tty (path to the
device) associated with the current shell or
command. If the current session has no tty, this
variable is not set.
TZ This variable is set to indicate the present time
zone if it was set when the daemon was started
(i.e. the daemon passes the value on to new
connections).
USER Set to the name of the user logging in.
Additionally, ssh reads ~/.ssh/environment, and adds lines of the format
M-bM-^@M-^\VARNAME=valueM-bM-^@M-^] to the environment if the file exists and users are
allowed to change their environment. For more information, see the
PermitUserEnvironment option in sshd_config(5).
FILES
~/.rhosts
This file is used for host-based authentication (see above). On
some machines this file may need to be world-readable if the
user's home directory is on an NFS partition, 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.
~/.shosts
This file is used in exactly the same way as .rhosts, but allows
host-based authentication without permitting login with
rlogin/rsh.
~/.ssh/
This directory is the default location for all user-specific
configuration and authentication information. There is no
general requirement to keep the entire contents of this directory
secret, but the recommended permissions are read/write/execute
for the user, and not accessible by others.
~/.ssh/authorized_keys
Lists the public keys (DSA, ECDSA, Ed25519, RSA) that can be used
for logging in as this user. The format of this file is
described in the sshd(8) manual page. This file is not highly
sensitive, but the recommended permissions are read/write for the
user, and not accessible by others.
~/.ssh/config
This is the per-user configuration file. The file format and
configuration options are described in ssh_config(5). Because of
the potential for abuse, this file must have strict permissions:
read/write for the user, and not writable by others.
~/.ssh/environment
Contains additional definitions for environment variables; see
ENVIRONMENT, above.
~/.ssh/identity
~/.ssh/id_dsa
~/.ssh/id_ecdsa
~/.ssh/id_ed25519
~/.ssh/id_rsa
Contains the private key for authentication. These files contain
sensitive data and should be readable by the user but not
accessible by others (read/write/execute). ssh will simply
ignore a private key file if it is accessible by others. It is
possible to specify a passphrase when generating the key which
will be used to encrypt the sensitive part of this file using
3DES.
~/.ssh/identity.pub
~/.ssh/id_dsa.pub
~/.ssh/id_ecdsa.pub
~/.ssh/id_ed25519.pub
~/.ssh/id_rsa.pub
Contains the public key for authentication. These files are not
sensitive and can (but need not) be readable by anyone.
~/.ssh/known_hosts
Contains a list of host keys for all hosts the user has logged
into that are not already in the systemwide list of known host
keys. See sshd(8) for further details of the format of this
file.
~/.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.
/etc/hosts.equiv
This file is for host-based authentication (see above). It
should only be writable by root.
/etc/shosts.equiv
This file is used in exactly the same way as hosts.equiv, but
allows host-based authentication without permitting login with
rlogin/rsh.
/etc/ssh/ssh_config
Systemwide configuration file. The file format and configuration
options are described in ssh_config(5).
/etc/ssh/ssh_host_key
/etc/ssh/ssh_host_dsa_key
/etc/ssh/ssh_host_ecdsa_key
/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.
/etc/ssh/ssh_known_hosts
Systemwide list of known host keys. This file should be prepared
by the system administrator to contain the public host keys of
all machines in the organization. It should be world-readable.
See sshd(8) for further details of the format of this file.
/etc/ssh/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.
EXIT STATUS
ssh exits with the exit status of the remote command or with 255 if an
error occurred.
SEE ALSO
scp(1), sftp(1), ssh-add(1), ssh-agent(1), ssh-keygen(1), ssh-keyscan(1),
tun(4), ssh_config(5), ssh-keysign(8), sshd(8)
STANDARDS
S. Lehtinen and C. Lonvick, The Secure Shell (SSH) Protocol Assigned
Numbers, RFC 4250, January 2006.
T. Ylonen and C. Lonvick, The Secure Shell (SSH) Protocol Architecture,
RFC 4251, January 2006.
T. Ylonen and C. Lonvick, The Secure Shell (SSH) Authentication Protocol,
RFC 4252, January 2006.
T. Ylonen and C. Lonvick, The Secure Shell (SSH) Transport Layer
Protocol, RFC 4253, January 2006.
T. Ylonen and C. Lonvick, The Secure Shell (SSH) Connection Protocol, RFC
4254, January 2006.
J. Schlyter and W. Griffin, Using DNS to Securely Publish Secure Shell
(SSH) Key Fingerprints, RFC 4255, January 2006.
F. Cusack and M. Forssen, Generic Message Exchange Authentication for the
Secure Shell Protocol (SSH), RFC 4256, January 2006.
J. Galbraith and P. Remaker, The Secure Shell (SSH) Session Channel Break
Extension, RFC 4335, January 2006.
M. Bellare, T. Kohno, and C. Namprempre, The Secure Shell (SSH) Transport
Layer Encryption Modes, RFC 4344, January 2006.
B. Harris, Improved Arcfour Modes for the Secure Shell (SSH) Transport
Layer Protocol, RFC 4345, January 2006.
M. Friedl, N. Provos, and W. Simpson, Diffie-Hellman Group Exchange for
the Secure Shell (SSH) Transport Layer Protocol, RFC 4419, March 2006.
J. Galbraith and R. Thayer, The Secure Shell (SSH) Public Key File
Format, RFC 4716, November 2006.
D. Stebila and J. Green, Elliptic Curve Algorithm Integration in the
Secure Shell Transport Layer, RFC 5656, December 2009.
A. Perrig and D. Song, Hash Visualization: a New Technique to improve
Real-World Security, 1999, International Workshop on Cryptographic
Techniques and E-Commerce (CrypTEC '99).
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.
OpenBSD 5.8 July 20, 2015 OpenBSD 5.8

1026
crypto/openssh/ssh_config.0
View File

File diff suppressed because it is too large Load Diff

640
crypto/openssh/sshd.0
View File

@ -1,640 +0,0 @@
SSHD(8) System Manager's Manual SSHD(8)
NAME
sshd M-bM-^@M-^S OpenSSH SSH daemon
SYNOPSIS
sshd [-46DdeiqTt] [-b bits] [-C connection_spec]
[-c host_certificate_file] [-E log_file] [-f config_file]
[-g login_grace_time] [-h host_key_file] [-k key_gen_time]
[-o option] [-p port] [-u len]
DESCRIPTION
sshd (OpenSSH 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.
sshd 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.
sshd can be configured using command-line options or a configuration file
(by default sshd_config(5)); 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 and options it was started with, e.g. /usr/sbin/sshd.
The options are as follows:
-4 Forces sshd to use IPv4 addresses only.
-6 Forces sshd to use IPv6 addresses only.
-b bits
Specifies the number of bits in the ephemeral protocol version 1
server key (default 1024).
-C connection_spec
Specify the connection parameters to use for the -T extended test
mode. If provided, any Match directives in the configuration
file that would apply to the specified user, host, and address
will be set before the configuration is written to standard
output. The connection parameters are supplied as keyword=value
pairs. The keywords are M-bM-^@M-^\userM-bM-^@M-^], M-bM-^@M-^\hostM-bM-^@M-^], M-bM-^@M-^\laddrM-bM-^@M-^], M-bM-^@M-^\lportM-bM-^@M-^], and
M-bM-^@M-^\addrM-bM-^@M-^]. All are required and may be supplied in any order,
either with multiple -C options or as a comma-separated list.
-c host_certificate_file
Specifies a path to a certificate file to identify sshd during
key exchange. The certificate file must match a host key file
specified using the -h option or the HostKey configuration
directive.
-D When this option is specified, sshd will not detach and does not
become a daemon. This allows easy monitoring of sshd.
-d Debug mode. The server sends verbose debug output to standard
error, 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 log_file
Append debug logs to log_file instead of the system log.
-e Write debug logs to standard error instead of the system log.
-f config_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 120 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_dsa_key, /etc/ssh/ssh_host_ecdsa_key.
/etc/ssh/ssh_host_ed25519_key and /etc/ssh/ssh_host_rsa_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(8). If SSH protocol
1 is enabled, sshd should not normally be run from inetd because
it needs to generate the server key before it can respond to the
client, and this may take some time. Clients may have to wait
too long if the key was regenerated every time.
-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. For full details
of the options, and their values, see sshd_config(5).
-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 with the Port option are
ignored when a command-line port is specified. Ports specified
using the ListenAddress option override command-line ports.
-q Quiet mode. Nothing is sent to the system log. Normally the
beginning, authentication, and termination of each connection is
logged.
-T Extended test mode. Check the validity of the configuration
file, output the effective configuration to stdout and then exit.
Optionally, Match rules may be applied by specifying the
connection parameters using one or more -C options.
-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 may 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 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.
AUTHENTICATION
The OpenSSH SSH daemon supports SSH protocols 1 and 2. The default is to
use protocol 2 only, though this can be changed via the Protocol option
in sshd_config(5). Protocol 2 supports DSA, ECDSA, Ed25519 and RSA keys;
protocol 1 only supports RSA keys. For both protocols, each host has a
host-specific key, normally 2048 bits, used to identify the host.
Forward security for protocol 1 is provided through an additional server
key, normally 1024 bits, generated when the server starts. 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.
For protocol 2, 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-md5, hmac-sha1, umac-64,
umac-128, hmac-ripemd160, hmac-sha2-256 or hmac-sha2-512).
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.
Regardless of the authentication type, the account is checked to ensure
that it is accessible. An account is not accessible if it is locked,
listed in DenyUsers or its group is listed in DenyGroups . The
definition of a locked account is system dependant. Some platforms have
their own account database (eg AIX) and some modify the passwd field (
M-bM-^@M-^X*LK*M-bM-^@M-^Y on Solaris and UnixWare, M-bM-^@M-^X*M-bM-^@M-^Y on HP-UX, containing M-bM-^@M-^XNologinM-bM-^@M-^Y on
Tru64, a leading M-bM-^@M-^X*LOCKED*M-bM-^@M-^Y on FreeBSD and a leading M-bM-^@M-^X!M-bM-^@M-^Y on most
Linuxes). If there is a requirement to disable password authentication
for the account while allowing still public-key, then the passwd field
should be set to something other than these values (eg M-bM-^@M-^XNPM-bM-^@M-^Y or M-bM-^@M-^X*NP*M-bM-^@M-^Y ).
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.
LOGIN PROCESS
When a user successfully logs in, sshd does the following:
1. 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 ~/.hushlogin; see the FILES section).
2. If the login is on a tty, records login time.
3. Checks /etc/nologin; if it exists, prints contents and quits
(unless root).
4. Changes to run with normal user privileges.
5. Sets up basic environment.
6. Reads the file ~/.ssh/environment, if it exists, and users are
allowed to change their environment. See the
PermitUserEnvironment option in sshd_config(5).
7. Changes to user's home directory.
8. If ~/.ssh/rc exists and the sshd_config(5) PermitUserRC option
is set, runs it; else if /etc/ssh/sshrc exists, runs it;
otherwise runs xauth. The M-bM-^@M-^\rcM-bM-^@M-^] files are given the X11
authentication protocol and cookie in standard input. See
SSHRC, below.
9. Runs user's shell or command. All commands are run under the
user's login shell as specified in the system password
database.
SSHRC
If the file ~/.ssh/rc exists, sh(1) runs it 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(1) because sshd will not run xauth automatically to add X11
cookies.
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 && [ -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 either, xauth is used to add the cookie.
AUTHORIZED_KEYS FILE FORMAT
AuthorizedKeysFile specifies the files containing public keys for public
key authentication; if none is specified, the default is
~/.ssh/authorized_keys and ~/.ssh/authorized_keys2. Each line of the
file contains one key (empty lines and lines starting with a M-bM-^@M-^X#M-bM-^@M-^Y are
ignored as comments). Protocol 1 public keys consist of the following
space-separated fields: options, bits, exponent, modulus, comment.
Protocol 2 public key consist of: options, keytype, base64-encoded key,
comment. The options field is optional; its presence is determined by
whether the line starts with a number or not (the options 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 M-bM-^@M-^\ecdsa-sha2-nistp256M-bM-^@M-^],
M-bM-^@M-^\ecdsa-sha2-nistp384M-bM-^@M-^], M-bM-^@M-^\ecdsa-sha2-nistp521M-bM-^@M-^], M-bM-^@M-^\ssh-ed25519M-bM-^@M-^], M-bM-^@M-^\ssh-dssM-bM-^@M-^] or
M-bM-^@M-^\ssh-rsaM-bM-^@M-^].
Note that lines in this file are usually several hundred bytes long
(because of the size of the public key encoding) up to a limit of 8
kilobytes, which permits DSA keys up to 8 kilobits and RSA keys up to 16
kilobits. You don't want to type them in; instead, copy the
identity.pub, id_dsa.pub, id_ecdsa.pub, id_ed25519.pub, or the id_rsa.pub
file and edit it.
sshd enforces a minimum RSA key modulus size for protocol 1 and protocol
2 keys of 768 bits.
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):
cert-authority
Specifies that the listed key is a certification authority (CA)
that is trusted to validate signed certificates for user
authentication.
Certificates may encode access restrictions similar to these key
options. If both certificate restrictions and key options are
present, the most restrictive union of the two is applied.
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 an 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 public 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 and/or X11 forwarding
unless they are explicitly prohibited. The command originally
supplied by the client is available in the SSH_ORIGINAL_COMMAND
environment variable. Note that this option applies to shell,
command or subsystem execution. Also note that this command may
be superseded by either a sshd_config(5) ForceCommand directive
or a command embedded in a certificate.
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. Environment processing is disabled by
default and is controlled via the PermitUserEnvironment option.
This option is automatically disabled if UseLogin is enabled.
from="pattern-list"
Specifies that in addition to public key authentication, either
the canonical name of the remote host or its IP address must be
present in the comma-separated list of patterns. See PATTERNS in
ssh_config(5) for more information on patterns.
In addition to the wildcard matching that may be applied to
hostnames or addresses, a from stanza may match IP addresses
using CIDR address/masklen notation.
The purpose of this option is to optionally increase security:
public key 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).
no-agent-forwarding
Forbids authentication agent forwarding when this key is used for
authentication.
no-port-forwarding
Forbids TCP 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-pty Prevents tty allocation (a request to allocate a pty will fail).
no-user-rc
Disables execution of ~/.ssh/rc.
no-X11-forwarding
Forbids X11 forwarding when this key is used for authentication.
Any X11 forward requests by the client will return an error.
permitopen="host:port"
Limit local port forwarding with ssh(1) -L such that it may only
connect to the specified host and port. IPv6 addresses can be
specified by enclosing the address in square brackets. 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. A port specification of *
matches any port.
principals="principals"
On a cert-authority line, specifies allowed principals for
certificate authentication as a comma-separated list. At least
one name from the list must appear in the certificate's list of
principals for the certificate to be accepted. This option is
ignored for keys that are not marked as trusted certificate
signers using the cert-authority option.
tunnel="n"
Force a tun(4) device on the server. Without this option, the
next available device will be used if the client requests a
tunnel.
An example authorized_keys file:
# Comments allowed at start of line
ssh-rsa AAAAB3Nza...LiPk== user@example.net
from="*.sales.example.net,!pc.sales.example.net" ssh-rsa
AAAAB2...19Q== john@example.net
command="dump /home",no-pty,no-port-forwarding ssh-dss
AAAAC3...51R== example.net
permitopen="192.0.2.1:80",permitopen="192.0.2.2:25" ssh-dss
AAAAB5...21S==
tunnel="0",command="sh /etc/netstart tun0" ssh-rsa AAAA...==
jane@example.net
SSH_KNOWN_HOSTS FILE FORMAT
The /etc/ssh/ssh_known_hosts and ~/.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: markers
(optional), hostnames, bits, exponent, modulus, comment. The fields are
separated by spaces.
The marker is optional, but if it is present then it must be one of
M-bM-^@M-^\@cert-authorityM-bM-^@M-^], to indicate that the line contains a certification
authority (CA) key, or M-bM-^@M-^\@revokedM-bM-^@M-^], to indicate that the key contained on
the line is revoked and must not ever be accepted. Only one marker
should be used on a key line.
Hostnames is a comma-separated list of patterns (M-bM-^@M-^X*M-bM-^@M-^Y and M-bM-^@M-^X?M-bM-^@M-^Y 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 M-bM-^@M-^X!M-bM-^@M-^Y 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.
A hostname or address may optionally be enclosed within M-bM-^@M-^X[M-bM-^@M-^Y and M-bM-^@M-^X]M-bM-^@M-^Y
brackets then followed by M-bM-^@M-^X:M-bM-^@M-^Y and a non-standard port number.
Alternately, hostnames may be stored in a hashed form which hides host
names and addresses should the file's contents be disclosed. Hashed
hostnames start with a M-bM-^@M-^X|M-bM-^@M-^Y character. Only one hashed hostname may
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_key.pub. The
optional comment field continues to the end of the line, and is not used.
Lines starting with M-bM-^@M-^X#M-bM-^@M-^Y and empty lines are ignored as comments.
When performing host authentication, authentication is accepted if any
matching line has the proper key; either one that matches exactly or, if
the server has presented a certificate for authentication, the key of the
certification authority that signed the certificate. For a key to be
trusted as a certification authority, it must use the M-bM-^@M-^\@cert-authorityM-bM-^@M-^]
marker described above.
The known hosts file also provides a facility to mark keys as revoked,
for example when it is known that the associated private key has been
stolen. Revoked keys are specified by including the M-bM-^@M-^\@revokedM-bM-^@M-^] marker at
the beginning of the key line, and are never accepted for authentication
or as certification authorities, but instead will produce a warning from
ssh(1) when they are encountered.
It is 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, ssh-keyscan(1) or by taking
/etc/ssh/ssh_host_key.pub and adding the host names at the front.
ssh-keygen(1) also offers some basic automated editing for
~/.ssh/known_hosts including removing hosts matching a host name and
converting all host names to their hashed representations.
An example ssh_known_hosts file:
# Comments allowed at start of line
closenet,...,192.0.2.53 1024 37 159...93 closenet.example.net
cvs.example.net,192.0.2.10 ssh-rsa AAAA1234.....=
# A hashed hostname
|1|JfKTdBh7rNbXkVAQCRp4OQoPfmI=|USECr3SWf1JUPsms5AqfD5QfxkM= ssh-rsa
AAAA1234.....=
# A revoked key
@revoked * ssh-rsa AAAAB5W...
# A CA key, accepted for any host in *.mydomain.com or *.mydomain.org
@cert-authority *.mydomain.org,*.mydomain.com ssh-rsa AAAAB5W...
FILES
~/.hushlogin
This file is used to suppress printing the last login time and
/etc/motd, if PrintLastLog and PrintMotd, respectively, are
enabled. It does not suppress printing of the banner specified
by Banner.
~/.rhosts
This file is used for host-based authentication (see ssh(1) for
more information). On some machines this file may need to be
world-readable if the user's home directory is on an NFS
partition, because sshd 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.
~/.shosts
This file is used in exactly the same way as .rhosts, but allows
host-based authentication without permitting login with
rlogin/rsh.
~/.ssh/
This directory is the default location for all user-specific
configuration and authentication information. There is no
general requirement to keep the entire contents of this directory
secret, but the recommended permissions are read/write/execute
for the user, and not accessible by others.
~/.ssh/authorized_keys
Lists the public keys (DSA, ECDSA, Ed25519, RSA) that can be used
for logging in as this user. The format of this file is
described above. The content of the file is not highly
sensitive, but the recommended permissions are read/write for the
user, and not accessible by others.
If this file, the ~/.ssh directory, or the user's home directory
are writable by other users, then the file could be modified or
replaced by unauthorized users. In this case, sshd will not
allow it to be used unless the StrictModes option has been set to
M-bM-^@M-^\noM-bM-^@M-^].
~/.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
M-bM-^@M-^X#M-bM-^@M-^Y), 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. Environment processing is disabled by default and
is controlled via the PermitUserEnvironment option.
~/.ssh/known_hosts
Contains a list of host keys for all hosts the user has logged
into that are not already in the systemwide list of known host
keys. The format of this file is described above. This file
should be writable only by root/the owner and can, but need not
be, world-readable.
~/.ssh/rc
Contains initialization routines to be run before the user's home
directory becomes accessible. This file should be writable only
by the user, and need not be readable by anyone else.
/etc/hosts.allow
/etc/hosts.deny
Access controls that should be enforced by tcp-wrappers are
defined here. Further details are described in hosts_access(5).
/etc/hosts.equiv
This file is for host-based authentication (see ssh(1)). It
should only be writable by root.
/etc/moduli
Contains Diffie-Hellman groups used for the "Diffie-Hellman Group
Exchange". The file format is described in moduli(5).
/etc/motd
See motd(5).
/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/shosts.equiv
This file is used in exactly the same way as hosts.equiv, but
allows host-based authentication without permitting login with
rlogin/rsh.
/etc/ssh/ssh_host_key
/etc/ssh/ssh_host_dsa_key
/etc/ssh/ssh_host_ecdsa_key
/etc/ssh/ssh_host_ed25519_key
/etc/ssh/ssh_host_rsa_key
These 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 these
files are group/world-accessible.
/etc/ssh/ssh_host_key.pub
/etc/ssh/ssh_host_dsa_key.pub
/etc/ssh/ssh_host_ecdsa_key.pub
/etc/ssh/ssh_host_ed25519_key.pub
/etc/ssh/ssh_host_rsa_key.pub
These 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-keygen(1).
/etc/ssh/ssh_known_hosts
Systemwide list of known host keys. This file should be prepared
by the system administrator to contain the public host keys of
all machines in the organization. The format of this file is
described above. This file should be writable only by root/the
owner and should be world-readable.
/etc/ssh/sshd_config
Contains configuration data for sshd. The file format and
configuration options are described in sshd_config(5).
/etc/ssh/sshrc
Similar to ~/.ssh/rc, it can be used to specify machine-specific
login-time initializations globally. This file should be
writable only by root, and should be world-readable.
/var/empty
chroot(2) directory used by sshd during privilege separation in
the pre-authentication phase. The directory should not contain
any files and must be owned by root and not group or world-
writable.
/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 process ID of the one started last).
The content of this file is not sensitive; it can be world-
readable.
SEE ALSO
scp(1), sftp(1), ssh(1), ssh-add(1), ssh-agent(1), ssh-keygen(1),
ssh-keyscan(1), chroot(2), hosts_access(5), login.conf(5), moduli(5),
sshd_config(5), inetd(8), sftp-server(8)
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. Niels Provos and Markus Friedl contributed support
for privilege separation.
OpenBSD 5.8 July 3, 2015 OpenBSD 5.8

1052
crypto/openssh/sshd_config.0
View File

File diff suppressed because it is too large Load Diff