tyler.durden
/
openssh-portable
mirror of https://github.com/PowerShell/openssh-portable.git
1
0
Fork 0
Code Issues Packages Projects Releases Wiki Activity

autogenerated files for release

This commit is contained in:
Damien Miller 2024-07-01 14:36:28 +10:00
parent fa41f6592f
commit 6849957945
No known key found for this signature in database
20 changed files with 45291 additions and 6 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

6
.gitignore vendored
View File

@ -33,9 +33,3 @@ sshd
!regress/unittests/sshsig/Makefile !regress/unittests/sshsig/Makefile
tags tags
# Ignored on main branch
config.h.in
configure
aclocal.m4
ChangeLog
**/*.0

8666
ChangeLog Normal file
View File

File diff suppressed because it is too large Load Diff

15
aclocal.m4 vendored Normal file
View File

@ -0,0 +1,15 @@
# generated automatically by aclocal 1.16.5 -*- Autoconf -*-
# Copyright (C) 1996-2021 Free Software Foundation, Inc.
# This file is free software; the Free Software Foundation
# gives unlimited permission to copy and/or distribute it,
# with or without modifications, as long as this notice is preserved.
# This program is distributed in the hope that it will be useful,
# but WITHOUT ANY WARRANTY, to the extent permitted by law; without
# even the implied warranty of MERCHANTABILITY or FITNESS FOR A
# PARTICULAR PURPOSE.
m4_ifndef([AC_CONFIG_MACRO_DIRS], [m4_defun([_AM_CONFIG_MACRO_DIRS], [])m4_defun([AC_CONFIG_MACRO_DIRS], [_AM_CONFIG_MACRO_DIRS($@)])])
m4_include([m4/openssh.m4])

2051
config.h.in Normal file
View File

File diff suppressed because it is too large Load Diff

27691
configure vendored Executable file
View File

File diff suppressed because it is too large Load Diff

74
moduli.0 Normal file
View File

@ -0,0 +1,74 @@
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 -M generate,
calculates numbers that are likely to be useful. A second primality
testing pass, using ssh-keygen -M screen, 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.
OpenBSD 7.5 April 16, 2022 OpenBSD 7.5

232
scp.0 Normal file
View File

@ -0,0 +1,232 @@
SCP(1) General Commands Manual SCP(1)
NAME
scp M-bM-^@M-^S OpenSSH secure file copy
SYNOPSIS
scp [-346ABCOpqRrsTv] [-c cipher] [-D sftp_server_path] [-F ssh_config]
[-i identity_file] [-J destination] [-l limit] [-o ssh_option]
[-P port] [-S program] [-X sftp_option] source ... target
DESCRIPTION
scp copies files between hosts on a network.
scp uses the SFTP protocol over a ssh(1) connection for data transfer,
and uses the same authentication and provides the same security as a
login session.
scp will ask for passwords or passphrases if they are needed for
authentication.
The source and target may be specified as a local pathname, a remote host
with optional path in the form [user@]host:[path], or a URI in the form
scp://[user@]host[:port][/path]. 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.
When copying between two remote hosts, if the URI format is used, a port
cannot be specified on the target if the -R option is used.
The options are as follows:
-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, when using the legacy SCP
protocol (via the -O flag), this option selects batch mode for
the second host as scp cannot ask for passwords or passphrases
for both hosts. This mode is the default.
-4 Forces scp to use IPv4 addresses only.
-6 Forces scp to use IPv6 addresses only.
-A Allows forwarding of ssh-agent(1) to the remote system. The
default is not to forward an authentication agent.
-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).
-D sftp_server_path
Connect directly to a local SFTP server program rather than a
remote one 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.
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).
-J destination
Connect to the target host by first making an scp connection to
the jump host described by destination and then establishing a
TCP forwarding to the ultimate destination from there. Multiple
jump hops may be specified separated by comma characters. This
is a shortcut to specify a ProxyJump configuration directive.
This option is directly passed to ssh(1).
-l limit
Limits the used bandwidth, specified in Kbit/s.
-O Use the legacy SCP protocol for file transfers instead of the
SFTP protocol. Forcing the use of the SCP protocol may be
necessary for servers that do not implement SFTP, for backwards-
compatibility for particular filename wildcard patterns and for
expanding paths with a M-bM-^@M-^X~M-bM-^@M-^Y prefix for older SFTP servers.
-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
BindInterface
CanonicalDomains
CanonicalizeFallbackLocal
CanonicalizeHostname
CanonicalizeMaxDots
CanonicalizePermittedCNAMEs
CASignatureAlgorithms
CertificateFile
CheckHostIP
Ciphers
Compression
ConnectionAttempts
ConnectTimeout
ControlMaster
ControlPath
ControlPersist
GlobalKnownHostsFile
GSSAPIAuthentication
GSSAPIDelegateCredentials
HashKnownHosts
Host
HostbasedAcceptedAlgorithms
HostbasedAuthentication
HostKeyAlgorithms
HostKeyAlias
Hostname
IdentitiesOnly
IdentityAgent
IdentityFile
IPQoS
KbdInteractiveAuthentication
KbdInteractiveDevices
KexAlgorithms
KnownHostsCommand
LogLevel
MACs
NoHostAuthenticationForLocalhost
NumberOfPasswordPrompts
PasswordAuthentication
PKCS11Provider
Port
PreferredAuthentications
ProxyCommand
ProxyJump
PubkeyAcceptedAlgorithms
PubkeyAuthentication
RekeyLimit
RequiredRSASize
SendEnv
ServerAliveInterval
ServerAliveCountMax
SetEnv
StrictHostKeyChecking
TCPKeepAlive
UpdateHostKeys
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 mode bits of the file.
-p Preserves modification times, access times, and file mode bits
from the source file.
-q Quiet mode: disables the progress meter as well as warning and
diagnostic messages from ssh(1).
-R Copies between two remote hosts are performed by connecting to
the origin host and executing scp there. This requires that scp
running on the origin host can authenticate to the destination
host without requiring a password.
-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.
-T Disable strict filename checking. By default when copying files
from a remote host to a local directory scp checks that the
received filenames match those requested on the command-line to
prevent the remote end from sending unexpected or unwanted files.
Because of differences in how various operating systems and
shells interpret filename wildcards, these checks may cause
wanted files to be rejected. This option disables these checks
at the expense of fully trusting that the server will not send
unexpected filenames.
-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.
-X sftp_option
Specify an option that controls aspects of SFTP protocol
behaviour. The valid options are:
nrequests=value
Controls how many concurrent SFTP read or write requests
may be in progress at any point in time during a download
or upload. By default 64 requests may be active
concurrently.
buffer=value
Controls the maximum buffer size for a single SFTP
read/write operation used during download or upload. By
default a 32KB buffer is used.
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),
sftp-server(8), sshd(8)
HISTORY
scp is based on the rcp program in BSD source code from the Regents of
the University of California.
Since OpenSSH 9.0, scp has used the SFTP protocol for transfers by
default.
AUTHORS
Timo Rinne <tri@iki.fi>
Tatu Ylonen <ylo@cs.hut.fi>
CAVEATS
The legacy SCP protocol (selected by the -O flag) requires execution of
the remote user's shell to perform glob(3) pattern matching. This
requires careful quoting of any characters that have special meaning to
the remote shell, such as quote characters.
OpenBSD 7.5 December 16, 2022 OpenBSD 7.5

98
sftp-server.0 Normal file
View File

@ -0,0 +1,98 @@
SFTP-SERVER(8) System Manager's Manual SFTP-SERVER(8)
NAME
sftp-server M-bM-^@M-^S OpenSSH SFTP server subsystem
SYNOPSIS
sftp-server [-ehR] [-d start_directory] [-f log_facility] [-l log_level]
[-P denied_requests] [-p allowed_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 denied_requests
Specifies a comma-separated list of SFTP protocol requests that
are banned by the server. sftp-server will reply to any denied
request with a failure. The -Q flag can be used to determine the
supported request types. If both denied and allowed lists are
specified, then the denied list is applied before the allowed
list.
-p allowed_requests
Specifies a comma-separated list of SFTP protocol requests that
are permitted by the server. All request types that are not on
the allowed list 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
Queries 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 to deny or allow specific requests (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 7.5 July 27, 2021 OpenBSD 7.5

438
sftp.0 Normal file
View File

@ -0,0 +1,438 @@
SFTP(1) General Commands Manual SFTP(1)
NAME
sftp M-bM-^@M-^S OpenSSH secure file transfer
SYNOPSIS
sftp [-46AaCfNpqrv] [-B buffer_size] [-b batchfile] [-c cipher]
[-D sftp_server_command] [-F ssh_config] [-i identity_file]
[-J destination] [-l limit] [-o ssh_option] [-P port]
[-R num_requests] [-S program] [-s subsystem | sftp_server]
[-X sftp_option] destination
DESCRIPTION
sftp is a 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.
The destination may be specified either as [user@]host[:path] or as a URI
in the form sftp://[user@]host[:port][/path].
If the destination includes a path and it is not a directory, sftp will
retrieve files automatically if a non-interactive authentication method
is used; otherwise it will do so after successful interactive
authentication.
If no path is specified, or if the path is a directory, sftp will log in
to the specified host and enter interactive command mode, changing to the
remote directory if one was specified. An optional trailing slash can be
used to force the path to be interpreted as a directory.
Since the destination formats use colon characters to delimit host names
from path names or port numbers, IPv6 addresses must be enclosed in
square brackets to avoid ambiguity.
The options are as follows:
-4 Forces sftp to use IPv4 addresses only.
-6 Forces sftp to use IPv6 addresses only.
-A Allows forwarding of ssh-agent(1) to the remote system. The
default is not to forward an authentication agent.
-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 to
obviate the need to enter a password at connection time (see
sshd(8) and ssh-keygen(1) for details).
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, copy, cp,
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*). Echo of the command may be suppressed by
prefixing the command with a M-bM-^@M-^X@M-bM-^@M-^Y character. These two prefixes
may be combined in any order, for example -@ls /bsd.
-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_command
Connect directly to a local sftp server (rather than via ssh(1)).
A command and arguments may be specified, for example
"/path/sftp-server -el debug3". 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).
-J destination
Connect to the target host by first making an sftp connection to
the jump host described by destination and then establishing a
TCP forwarding to the ultimate destination from there. Multiple
jump hops may be specified separated by comma characters. This
is a shortcut to specify a ProxyJump configuration directive.
This option is directly passed to ssh(1).
-l limit
Limits the used bandwidth, specified in Kbit/s.
-N Disables quiet mode, e.g. to override the implicit quiet mode set
by the -b flag.
-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
BindInterface
CanonicalDomains
CanonicalizeFallbackLocal
CanonicalizeHostname
CanonicalizeMaxDots
CanonicalizePermittedCNAMEs
CASignatureAlgorithms
CertificateFile
CheckHostIP
Ciphers
Compression
ConnectionAttempts
ConnectTimeout
ControlMaster
ControlPath
ControlPersist
GlobalKnownHostsFile
GSSAPIAuthentication
GSSAPIDelegateCredentials
HashKnownHosts
Host
HostbasedAcceptedAlgorithms
HostbasedAuthentication
HostKeyAlgorithms
HostKeyAlias
Hostname
IdentitiesOnly
IdentityAgent
IdentityFile
IPQoS
KbdInteractiveAuthentication
KbdInteractiveDevices
KexAlgorithms
KnownHostsCommand
LogLevel
MACs
NoHostAuthenticationForLocalhost
NumberOfPasswordPrompts
PasswordAuthentication
PKCS11Provider
Port
PreferredAuthentications
ProxyCommand
ProxyJump
PubkeyAcceptedAlgorithms
PubkeyAuthentication
RekeyLimit
RequiredRSASize
SendEnv
ServerAliveInterval
ServerAliveCountMax
SetEnv
StrictHostKeyChecking
TCPKeepAlive
UpdateHostKeys
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 when the remote sshd(8) does
not have an sftp subsystem configured.
-v Raise logging level. This option is also passed to ssh.
-X sftp_option
Specify an option that controls aspects of SFTP protocol
behaviour. The valid options are:
nrequests=value
Controls how many concurrent SFTP read or write requests
may be in progress at any point in time during a download
or upload. By default 64 requests may be active
concurrently.
buffer=value
Controls the maximum buffer size for a single SFTP
read/write operation used during download or upload. By
default a 32KB buffer is used.
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. If path is not specified, then
change directory to the one the session started in.
chgrp [-h] grp path
Change group of file path to grp. path may contain glob(7)
characters and may match multiple files. grp must be a numeric
GID.
If the -h flag is specified, then symlinks will not be followed.
Note that this is only supported by servers that implement the
"lsetstat@openssh.com" extension.
chmod [-h] mode path
Change permissions of file path to mode. path may contain
glob(7) characters and may match multiple files.
If the -h flag is specified, then symlinks will not be followed.
Note that this is only supported by servers that implement the
"lsetstat@openssh.com" extension.
chown [-h] own path
Change owner of file path to own. path may contain glob(7)
characters and may match multiple files. own must be a numeric
UID.
If the -h flag is specified, then symlinks will not be followed.
Note that this is only supported by servers that implement the
"lsetstat@openssh.com" extension.
copy oldpath newpath
Copy remote file from oldpath to newpath.
Note that this is only supported by servers that implement the
"copy-data" extension.
cp oldpath newpath
Alias to copy command.
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 [-afpR] 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(7)
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 the -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. If path is not specified, then
change directory to the local user's home directory.
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(7) 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(7)
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 [-afpR] 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(7)
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 the -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 [-fpR] remote-path [local-path]
Resume download of remote-path. Equivalent to get with the -a
flag set.
reput [-fpR] 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), ssh_config(5),
glob(7), 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 7.5 December 16, 2022 OpenBSD 7.5

209
ssh-add.0 Normal file
View File

@ -0,0 +1,209 @@
SSH-ADD(1) General Commands Manual SSH-ADD(1)
NAME
ssh-add M-bM-^@M-^S adds private key identities to the OpenSSH authentication agent
SYNOPSIS
ssh-add [-CcDdKkLlqvXx] [-E fingerprint_hash] [-H hostkey_file]
[-h destination_constraint] [-S provider] [-t life] [file ...]
ssh-add -s pkcs11 [-Cv] [certificate ...]
ssh-add -e pkcs11
ssh-add -T pubkey ...
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_ecdsa, ~/.ssh/id_ecdsa_sk, ~/.ssh/id_ed25519 and
~/.ssh/id_ed25519_sk. 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 When loading keys into or deleting keys from the agent, process
certificates only and skip plain keys.
-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. If
the argument list consists of M-bM-^@M-^\-M-bM-^@M-^] then ssh-add will read public
keys to be removed from standard input.
-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.
-H hostkey_file
Specifies a known hosts file to look up hostkeys when using
destination-constrained keys via the -h flag. This option may be
specified multiple times to allow multiple files to be searched.
If no files are specified, ssh-add will use the default
ssh_config(5) known hosts files: ~/.ssh/known_hosts,
~/.ssh/known_hosts2, /etc/ssh/ssh_known_hosts, and
/etc/ssh/ssh_known_hosts2.
-h destination_constraint
When adding keys, constrain them to be usable only through
specific hosts or to specific destinations.
Destination constraints of the form M-bM-^@M-^X[user@]dest-hostnameM-bM-^@M-^Y permit
use of the key only from the origin host (the one running
ssh-agent(1)) to the listed destination host, with optional user
name.
Constraints of the form M-bM-^@M-^Xsrc-hostname>[user@]dst-hostnameM-bM-^@M-^Y allow
a key available on a forwarded ssh-agent(1) to be used through a
particular host (as specified by M-bM-^@M-^Xsrc-hostnameM-bM-^@M-^Y) to authenticate
to a further host, specified by M-bM-^@M-^Xdst-hostnameM-bM-^@M-^Y.
Multiple destination constraints may be added when loading keys.
When attempting authentication with a key that has destination
constraints, the whole connection path, including ssh-agent(1)
forwarding, is tested against those constraints and each hop must
be permitted for the attempt to succeed. For example, if key is
forwarded to a remote host, M-bM-^@M-^Xhost-bM-bM-^@M-^Y, and is attempting
authentication to another host, M-bM-^@M-^Xhost-cM-bM-^@M-^Y, then the operation will
be successful only if M-bM-^@M-^Xhost-bM-bM-^@M-^Y was permitted from the origin host
and the subsequent M-bM-^@M-^Xhost-b>host-cM-bM-^@M-^Y hop is also permitted by
destination constraints.
Hosts are identified by their host keys, and are looked up from
known hosts files by ssh-add. Wildcards patterns may be used for
hostnames and certificate host keys are supported. By default,
keys added by ssh-add are not destination constrained.
Destination constraints were added in OpenSSH release 8.9.
Support in both the remote SSH client and server is required when
using destination-constrained keys over a forwarded ssh-agent(1)
channel.
It is also important to note that destination constraints can
only be enforced by ssh-agent(1) when a key is used, or when it
is forwarded by a cooperating ssh(1). Specifically, it does not
prevent an attacker with access to a remote SSH_AUTH_SOCK from
forwarding it again and using it on a different host (but only to
a permitted destination).
-K Load resident keys from a FIDO authenticator.
-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.
-q Be quiet after a successful operation.
-S provider
Specifies a path to a library that will be used when adding FIDO
authenticator-hosted keys, overriding the default of using the
internal USB HID support.
-s pkcs11
Add keys provided by the PKCS#11 shared library pkcs11.
Certificate files may optionally be listed as command-line
arguments. If these are present, then they will be loaded into
the agent using any corresponding private keys loaded from the
PKCS#11 token.
-T pubkey ...
Tests whether the private keys that correspond to the specified
pubkey files are usable by performing sign and verify operations
on each.
-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).
-v Verbose mode. Causes ssh-add to print debugging messages about
its progress. This is helpful in debugging problems. Multiple
-v options increase the verbosity. The maximum is 3.
-X Unlock the agent.
-x Lock the agent with a password.
ENVIRONMENT
DISPLAY, SSH_ASKPASS and SSH_ASKPASS_REQUIRE
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.
SSH_ASKPASS_REQUIRE allows further control over the use of an
askpass program. If this variable is set to M-bM-^@M-^\neverM-bM-^@M-^] then ssh-add
will never attempt to use one. If it is set to M-bM-^@M-^\preferM-bM-^@M-^], then
ssh-add will prefer to use the askpass program instead of the TTY
when requesting passwords. Finally, if the variable is set to
M-bM-^@M-^\forceM-bM-^@M-^], then the askpass program will be used for all passphrase
input regardless of whether DISPLAY is set.
SSH_AUTH_SOCK
Identifies the path of a UNIX-domain socket used to communicate
with the agent.
SSH_SK_PROVIDER
Specifies a path to a library that will be used when loading any
FIDO authenticator-hosted keys, overriding the default of using
the built-in USB HID support.
FILES
~/.ssh/id_ecdsa
~/.ssh/id_ecdsa_sk
~/.ssh/id_ed25519
~/.ssh/id_ed25519_sk
~/.ssh/id_rsa
Contains the ECDSA, authenticator-hosted ECDSA, Ed25519,
authenticator-hosted Ed25519 or 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 7.5 June 17, 2024 OpenBSD 7.5

140
ssh-agent.0 Normal file
View File

@ -0,0 +1,140 @@
SSH-AGENT(1) General Commands Manual SSH-AGENT(1)
NAME
ssh-agent M-bM-^@M-^S OpenSSH authentication agent
SYNOPSIS
ssh-agent [-c | -s] [-Dd] [-a bind_address] [-E fingerprint_hash]
[-O option] [-P allowed_providers] [-t life]
ssh-agent [-a bind_address] [-E fingerprint_hash] [-O option]
[-P allowed_providers] [-t life] command [arg ...]
ssh-agent [-c | -s] -k
DESCRIPTION
ssh-agent is a program to hold private keys used for public key
authentication. 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 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).
-O option
Specify an option when starting ssh-agent. Currently two options
are supported: allow-remote-pkcs11 and no-restrict-websafe.
The allow-remote-pkcs11 option allows clients of a forwarded
ssh-agent to load PKCS#11 or FIDO provider libraries. By default
only local clients may perform this operation. Note that
signalling that an ssh-agent client is remote is performed by
ssh(1), and use of other tools to forward access to the agent
socket may circumvent this restriction.
The no-restrict-websafe option instructs ssh-agent to permit
signatures using FIDO keys that might be web authentication
requests. By default, ssh-agent refuses signature requests for
FIDO keys where the key application string does not start with
M-bM-^@M-^\ssh:M-bM-^@M-^] and when the data to be signed does not appear to be a
ssh(1) user authentication request or a ssh-keygen(1) signature.
The default behaviour prevents forwarded access to a FIDO key
from also implicitly forwarding the ability to authenticate to
websites.
-P allowed_providers
Specify a pattern-list of acceptable paths for PKCS#11 provider
and FIDO authenticator middleware shared libraries that may be
used with the -S or -s options to ssh-add(1). Libraries that do
not match the pattern list will be refused. See PATTERNS in
ssh_config(5) for a description of pattern-list syntax. The
default list is M-bM-^@M-^\usr/lib*/*,/usr/local/lib*/*M-bM-^@M-^].
-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.
command [arg ...]
If a command (and optional arguments) is given, this is executed
as a subprocess of the agent. The agent exits automatically when
the command given on the command line terminates.
There are two main ways to get an agent set up. The first is at the
start of an X session, where all other windows or programs are started as
children of the ssh-agent program. The agent starts a command under
which its environment variables are exported, for example ssh-agent xterm
&. When the command terminates, so does the agent.
The second method is used for a login session. When ssh-agent is
started, it prints the shell commands required to set its environment
variables, which in turn can be evaluated in the calling shell, for
example eval `ssh-agent -s`.
In both cases, ssh(1) looks at these environment variables and uses them
to establish a connection to the agent.
The agent initially does not have any private keys. Keys are added using
ssh-add(1) or by ssh(1) when AddKeysToAgent is set in ssh_config(5).
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.
Connections to ssh-agent may be forwarded from further remote hosts using
the -A option to ssh(1) (but see the caveats documented therein),
avoiding the need for authentication data to be stored on other machines.
Authentication passphrases and private keys never go over the network:
the connection to the agent is forwarded over SSH remote connections and
the result is returned to the requester, allowing the user access to
their identities anywhere in the network in a secure fashion.
ENVIRONMENT
SSH_AGENT_PID When ssh-agent starts, it stores the name of the agent's
process ID (PID) in this variable.
SSH_AUTH_SOCK When ssh-agent starts, it creates a UNIX-domain socket and
stores its pathname in this variable. It is accessible
only to the current user, but is easily abused by root or
another instance of the same user.
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), ssh_config(5), 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 7.5 August 10, 2023 OpenBSD 7.5

907
ssh-keygen.0 Normal file
View File

@ -0,0 +1,907 @@
SSH-KEYGEN(1) General Commands Manual SSH-KEYGEN(1)
NAME
ssh-keygen M-bM-^@M-^S OpenSSH authentication key utility
SYNOPSIS
ssh-keygen [-q] [-a rounds] [-b bits] [-C comment] [-f output_keyfile]
[-m format] [-N new_passphrase] [-O option]
[-t ecdsa | ecdsa-sk | ed25519 | ed25519-sk | rsa]
[-w provider] [-Z cipher]
ssh-keygen -p [-a rounds] [-f keyfile] [-m format] [-N new_passphrase]
[-P old_passphrase] [-Z cipher]
ssh-keygen -i [-f input_keyfile] [-m key_format]
ssh-keygen -e [-f input_keyfile] [-m key_format]
ssh-keygen -y [-f input_keyfile]
ssh-keygen -c [-a rounds] [-C comment] [-f keyfile] [-P passphrase]
ssh-keygen -l [-v] [-E fingerprint_hash] [-f input_keyfile]
ssh-keygen -B [-f input_keyfile]
ssh-keygen -D pkcs11
ssh-keygen -F hostname [-lv] [-f known_hosts_file]
ssh-keygen -H [-f known_hosts_file]
ssh-keygen -K [-a rounds] [-w provider]
ssh-keygen -R hostname [-f known_hosts_file]
ssh-keygen -r hostname [-g] [-f input_keyfile]
ssh-keygen -M generate [-O option] output_file
ssh-keygen -M screen [-f input_file] [-O option] output_file
ssh-keygen -I certificate_identity -s ca_key [-hU] [-D pkcs11_provider]
[-n principals] [-O option] [-V validity_interval]
[-z serial_number] file ...
ssh-keygen -L [-f input_keyfile]
ssh-keygen -A [-a rounds] [-f prefix_path]
ssh-keygen -k -f krl_file [-u] [-s ca_public] [-z version_number]
file ...
ssh-keygen -Q [-l] -f krl_file file ...
ssh-keygen -Y find-principals [-O option] -s signature_file
-f allowed_signers_file
ssh-keygen -Y match-principals -I signer_identity -f allowed_signers_file
ssh-keygen -Y check-novalidate [-O option] -n namespace -s signature_file
ssh-keygen -Y sign [-O option] -f key_file -n namespace file ...
ssh-keygen -Y verify [-O option] -f allowed_signers_file
-I signer_identity -n namespace -s signature_file
[-r revocation_file]
DESCRIPTION
ssh-keygen generates, manages and converts authentication keys for
ssh(1). ssh-keygen can create keys for use by SSH protocol version 2.
The type of key to be generated is specified with the -t option. If
invoked without any arguments, ssh-keygen will generate an Ed25519 key.
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/id_ecdsa,
~/.ssh/id_ecdsa_sk, ~/.ssh/id_ed25519, ~/.ssh/id_ed25519_sk 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.
ssh-keygen will by default write keys in an OpenSSH-specific format.
This format is preferred as it offers better protection for keys at rest
as well as allowing storage of key comments within the private key file
itself. The key comment may be useful to help identify the key. 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.
It is still possible for ssh-keygen to write the previously-used PEM
format private keys using the -m flag. This may be used when generating
new keys, and existing new-format keys may be converted using this option
in conjunction with the -p (change passphrase) flag.
After a key is generated, ssh-keygen will ask where the keys should be
placed to be activated.
The options are as follows:
-A Generate host keys of all default key types (rsa, ecdsa, and
ed25519) if they do not already exist. The host keys are
generated with the default key file path, an empty passphrase,
default bits for the key type, and default comment. If -f has
also been specified, its argument is used as a prefix to the
default path for the resulting host key files. This is used by
/etc/rc to generate new host keys.
-a rounds
When saving a private key, this option specifies the number of
KDF (key derivation function, currently bcrypt_pbkdf(3)) rounds
used. Higher numbers result in slower passphrase verification
and increased resistance to brute-force password cracking (should
the keys be stolen). The default is 16 rounds.
-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 3072 bits.
Generally, 3072 bits is considered sufficient. 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. ECDSA-SK, Ed25519 and Ed25519-SK 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. 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 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 a public 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 | [hostname]:port
Search for the specified hostname (with optional port number) 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 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. See the CERTIFICATES section for details.
-I certificate_identity
Specify the key identity when signing a public key. 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-^].
-K Download resident keys from a FIDO authenticator. Public and
private key files will be written to the current directory for
each downloaded key. If multiple FIDO authenticators are
attached, keys will be downloaded from the first touched
authenticator. See the FIDO AUTHENTICATOR section for more
information.
-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 one or more certificates.
-l Show fingerprint of specified public key file. ssh-keygen will
try to find the matching public key file and prints its
fingerprint. If combined with -v, a visual ASCII art
representation of the key is supplied with the fingerprint.
-M generate
Generate candidate Diffie-Hellman Group Exchange (DH-GEX)
parameters for eventual use by the
M-bM-^@M-^Xdiffie-hellman-group-exchange-*M-bM-^@M-^Y key exchange methods. The
numbers generated by this operation must be further screened
before use. See the MODULI GENERATION section for more
information.
-M screen
Screen candidate parameters for Diffie-Hellman Group Exchange.
This will accept a list of candidate numbers and test that they
are safe (Sophie Germain) primes with acceptable group
generators. The results of this operation may be added to the
/etc/moduli file. See the MODULI GENERATION section for more
information.
-m key_format
Specify a key format for key generation, the -i (import), -e
(export) conversion options, and the -p change passphrase
operation. The latter may be used to convert between OpenSSH
private key and PEM private key formats. The supported key
formats are: M-bM-^@M-^\RFC4716M-bM-^@M-^] (RFC 4716/SSH2 public or private key),
M-bM-^@M-^\PKCS8M-bM-^@M-^] (PKCS8 public or private key) or M-bM-^@M-^\PEMM-bM-^@M-^] (PEM public key).
By default OpenSSH will write newly-generated private keys in its
own format, but when converting public keys for export the
default format is M-bM-^@M-^\RFC4716M-bM-^@M-^]. Setting a format of M-bM-^@M-^\PEMM-bM-^@M-^] when
generating or updating a supported private key type will cause
the key to be stored in the legacy PEM private key format.
-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. See the
CERTIFICATES section for details.
-O option
Specify a key/value option. These are specific to the operation
that ssh-keygen has been requested to perform.
When signing certificates, one of the options listed in the
CERTIFICATES section may be specified here.
When performing moduli generation or screening, one of the
options listed in the MODULI GENERATION section may be specified.
When generating FIDO authenticator-backed keys, the options
listed in the FIDO AUTHENTICATOR section may be specified.
When performing signature-related options using the -Y flag, the
following options are accepted:
hashalg=algorithm
Selects the hash algorithm to use for hashing the message
to be signed. Valid algorithms are M-bM-^@M-^\sha256M-bM-^@M-^] and
M-bM-^@M-^\sha512.M-bM-^@M-^] The default is M-bM-^@M-^\sha512.M-bM-^@M-^]
print-pubkey
Print the full public key to standard output after
signature verification.
verify-time=timestamp
Specifies a time to use when validating signatures
instead of the current time. The time may be specified
as a date or time in the YYYYMMDD[Z] or in
YYYYMMDDHHMM[SS][Z] formats. Dates and times will be
interpreted in the current system time zone unless
suffixed with a Z character, which causes them to be
interpreted in the UTC time zone.
When generating SSHFP DNS records from public keys using the -r
flag, the following options are accepted:
hashalg=algorithm
Selects a hash algorithm to use when printing SSHFP
records using the -D flag. Valid algorithms are M-bM-^@M-^\sha1M-bM-^@M-^]
and M-bM-^@M-^\sha256M-bM-^@M-^]. The default is to print both.
The -O option may be specified multiple times.
-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. If the -l option
is also specified then the contents of the KRL will be printed.
-q Silence ssh-keygen.
-R hostname | [hostname]:port
Removes all keys belonging to the specified hostname (with
optional port number) 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 ca_key
Certify (sign) a public key using the specified CA key. 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 ecdsa | ecdsa-sk | ed25519 | ed25519-sk | rsa
Specifies the type of key to create. The possible values are
M-bM-^@M-^\ecdsaM-bM-^@M-^], M-bM-^@M-^\ecdsa-skM-bM-^@M-^], M-bM-^@M-^\ed25519M-bM-^@M-^], M-bM-^@M-^\ed25519-skM-bM-^@M-^], or M-bM-^@M-^\rsaM-bM-^@M-^].
This flag may also be used to specify the desired signature type
when signing certificates using an RSA CA key. The available RSA
signature variants are M-bM-^@M-^\ssh-rsaM-bM-^@M-^] (SHA1 signatures, not
recommended), M-bM-^@M-^\rsa-sha2-256M-bM-^@M-^], and M-bM-^@M-^\rsa-sha2-512M-bM-^@M-^] (the default).
-U When used in combination with -s or -Y sign, this option
indicates that a CA key resides in a ssh-agent(1). See the
CERTIFICATES section for more information.
-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:
M-bM-^@M-M-bM-^@M-" The string M-bM-^@M-^\alwaysM-bM-^@M-^] to indicate the certificate has no
specified start time.
M-bM-^@M-M-bM-^@M-" A date or time in the system time zone formatted as YYYYMMDD
or YYYYMMDDHHMM[SS].
M-bM-^@M-M-bM-^@M-" A date or time in the UTC time zone as YYYYMMDDZ or
YYYYMMDDHHMM[SS]Z.
M-bM-^@M-M-bM-^@M-" A relative time before the current system time consisting of
a minus sign followed by an interval in the format described
in the TIME FORMATS section of sshd_config(5).
M-bM-^@M-M-bM-^@M-" A raw seconds since epoch (Jan 1 1970 00:00:00 UTC) as a
hexadecimal number beginning with M-bM-^@M-^\0xM-bM-^@M-^].
The end time may be specified similarly to the start time:
M-bM-^@M-M-bM-^@M-" The string M-bM-^@M-^\foreverM-bM-^@M-^] to indicate the certificate has no
specified end time.
M-bM-^@M-M-bM-^@M-" A date or time in the system time zone formatted as YYYYMMDD
or YYYYMMDDHHMM[SS].
M-bM-^@M-M-bM-^@M-" A date or time in the UTC time zone as YYYYMMDDZ or
YYYYMMDDHHMM[SS]Z.
M-bM-^@M-M-bM-^@M-" A relative time after the current system time consisting of a
plus sign followed by an interval in the format described in
the TIME FORMATS section of sshd_config(5).
M-bM-^@M-M-bM-^@M-" A raw seconds since epoch (Jan 1 1970 00:00:00 UTC) as a
hexadecimal number beginning with M-bM-^@M-^\0xM-bM-^@M-^].
For example:
+52w1d Valid from now to 52 weeks and one day from now.
-4w:+4w
Valid from four weeks ago to four weeks from now.
20100101123000:20110101123000
Valid from 12:30 PM, January 1st, 2010 to 12:30 PM,
January 1st, 2011.
20100101123000Z:20110101123000Z
Similar, but interpreted in the UTC time zone rather than
the system time zone.
-1d:20110101
Valid from yesterday to midnight, January 1st, 2011.
0x1:0x2000000000
Valid from roughly early 1970 to May 2033.
-1m:forever
Valid from one minute ago and never expiring.
-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 provider
Specifies a path to a library that will be used when creating
FIDO authenticator-hosted keys, overriding the default of using
the internal USB HID support.
-Y find-principals
Find the principal(s) associated with the public key of a
signature, provided using the -s flag in an authorized signers
file provided using the -f flag. The format of the allowed
signers file is documented in the ALLOWED SIGNERS section below.
If one or more matching principals are found, they are returned
on standard output.
-Y match-principals
Find principal matching the principal name provided using the -I
flag in the authorized signers file specified using the -f flag.
If one or more matching principals are found, they are returned
on standard output.
-Y check-novalidate
Checks that a signature generated using ssh-keygen -Y sign has a
valid structure. This does not validate if a signature comes
from an authorized signer. When testing a signature, ssh-keygen
accepts a message on standard input and a signature namespace
using -n. A file containing the corresponding signature must
also be supplied using the -s flag. Successful testing of the
signature is signalled by ssh-keygen returning a zero exit
status.
-Y sign
Cryptographically sign a file or some data using an SSH key.
When signing, ssh-keygen accepts zero or more files to sign on
the command-line - if no files are specified then ssh-keygen will
sign data presented on standard input. Signatures are written to
the path of the input file with M-bM-^@M-^\.sigM-bM-^@M-^] appended, or to standard
output if the message to be signed was read from standard input.
The key used for signing is specified using the -f option and may
refer to either a private key, or a public key with the private
half available via ssh-agent(1). An additional signature
namespace, used to prevent signature confusion across different
domains of use (e.g. file signing vs email signing) must be
provided via the -n flag. Namespaces are arbitrary strings, and
may include: M-bM-^@M-^\fileM-bM-^@M-^] for file signing, M-bM-^@M-^\emailM-bM-^@M-^] for email signing.
For custom uses, it is recommended to use names following a
NAMESPACE@YOUR.DOMAIN pattern to generate unambiguous namespaces.
-Y verify
Request to verify a signature generated using ssh-keygen -Y sign
as described above. When verifying a signature, ssh-keygen
accepts a message on standard input and a signature namespace
using -n. A file containing the corresponding signature must
also be supplied using the -s flag, along with the identity of
the signer using -I and a list of allowed signers via the -f
flag. The format of the allowed signers file is documented in
the ALLOWED SIGNERS section below. A file containing revoked
keys can be passed using the -r flag. The revocation file may be
a KRL or a one-per-line list of public keys. Successful
verification by an authorized signer is signalled by ssh-keygen
returning a zero exit status.
-y This option will read a private OpenSSH format file and print an
OpenSSH public key to stdout.
-Z cipher
Specifies the cipher to use for encryption when writing an
OpenSSH-format private key file. The list of available ciphers
may be obtained using "ssh -Q cipher". The default is
M-bM-^@M-^\aes256-ctrM-bM-^@M-^].
-z serial_number
Specifies a serial number to be embedded in the certificate to
distinguish this certificate from others from the same CA. If
the serial_number is prefixed with a M-bM-^@M-^X+M-bM-^@M-^Y character, then the
serial number will be incremented for each certificate signed on
a single command-line. 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 -M generate option. The
desired length of the primes may be specified by the -O bits option. For
example:
# ssh-keygen -M generate -O bits=2048 moduli-2048.candidates
By default, the search for primes begins at a random point in the desired
length range. This may be overridden using the -O start 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 -M screen option. In this
mode ssh-keygen will read candidates from standard input (or a file
specified using the -f option). For example:
# ssh-keygen -M screen -f moduli-2048.candidates moduli-2048
By default, each candidate will be subjected to 100 primality tests.
This may be overridden using the -O prime-tests 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 -O
generator 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.
A number of options are available for moduli generation and screening via
the -O flag:
lines=number
Exit after screening the specified number of lines while
performing DH candidate screening.
start-line=line-number
Start screening at the specified line number while performing DH
candidate screening.
checkpoint=filename
Write the last line processed to the specified file while
performing DH candidate screening. This will be used to skip
lines in the input file that have already been processed if the
job is restarted.
memory=mbytes
Specify the amount of memory to use (in megabytes) when
generating candidate moduli for DH-GEX.
start=hex-value
Specify start point (in hex) when generating candidate moduli for
DH-GEX.
generator=value
Specify desired generator (in decimal) when testing candidate
moduli for DH-GEX.
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 user_key.pub
Similarly, it is possible for the CA key to be hosted in a ssh-agent(1).
This is indicated by the -U flag and, again, the CA key must be
identified by its public half.
$ ssh-keygen -Us ca_key.pub -I key_id user_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 host_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.
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.
critical:name[=contents]
extension:name[=contents]
Includes an arbitrary certificate critical option or extension.
The specified name should include a domain suffix, e.g.
M-bM-^@M-^\name@example.comM-bM-^@M-^]. If contents is specified then it is included
as the contents of the extension/option encoded as a string,
otherwise the extension/option is created with no contents
(usually indicating a flag). Extensions may be ignored by a
client or server that does not recognise them, whereas unknown
critical options will cause the certificate to be refused.
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.
no-touch-required
Do not require signatures made using this key include
demonstration of user presence (e.g. by having the user touch the
authenticator). This option only makes sense for the FIDO
authenticator algorithms ecdsa-sk and ed25519-sk.
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.
verify-required
Require signatures made using this key indicate that the user was
first verified. This option only makes sense for the FIDO
authenticator algorithms ecdsa-sk and ed25519-sk. Currently PIN
authentication is the only supported verification method, but
other methods may be supported in the future.
At present, no standard options are valid for host keys.
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 the 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). Refer to those manual
pages for details.
FIDO AUTHENTICATOR
ssh-keygen is able to generate FIDO authenticator-backed keys, after
which they may be used much like any other key type supported by OpenSSH,
so long as the hardware authenticator is attached when the keys are used.
FIDO authenticators generally require the user to explicitly authorise
operations by touching or tapping them. FIDO keys consist of two parts:
a key handle part stored in the private key file on disk, and a per-
device private key that is unique to each FIDO authenticator and that
cannot be exported from the authenticator hardware. These are combined
by the hardware at authentication time to derive the real key that is
used to sign authentication challenges. Supported key types are ecdsa-sk
and ed25519-sk.
The options that are valid for FIDO keys are:
application
Override the default FIDO application/origin string of M-bM-^@M-^\ssh:M-bM-^@M-^].
This may be useful when generating host or domain-specific
resident keys. The specified application string must begin with
M-bM-^@M-^\ssh:M-bM-^@M-^].
challenge=path
Specifies a path to a challenge string that will be passed to the
FIDO authenticator during key generation. The challenge string
may be used as part of an out-of-band protocol for key enrollment
(a random challenge is used by default).
device Explicitly specify a fido(4) device to use, rather than letting
the authenticator middleware select one.
no-touch-required
Indicate that the generated private key should not require touch
events (user presence) when making signatures. Note that sshd(8)
will refuse such signatures by default, unless overridden via an
authorized_keys option.
resident
Indicate that the key handle should be stored on the FIDO
authenticator itself. This makes it easier to use the
authenticator on multiple computers. Resident keys may be
supported on FIDO2 authenticators and typically require that a
PIN be set on the authenticator prior to generation. Resident
keys may be loaded off the authenticator using ssh-add(1).
Storing both parts of a key on a FIDO authenticator increases the
likelihood of an attacker being able to use a stolen
authenticator device.
user A username to be associated with a resident key, overriding the
empty default username. Specifying a username may be useful when
generating multiple resident keys for the same application name.
verify-required
Indicate that this private key should require user verification
for each signature. Not all FIDO authenticators support this
option. Currently PIN authentication is the only supported
verification method, but other methods may be supported in the
future.
write-attestation=path
May be used at key generation time to record the attestation data
returned from FIDO authenticators during key generation. This
information is potentially sensitive. By default, this
information is discarded.
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 including its SHA1 hash in the KRL.
sha256: public_key
Revokes the specified key by including its SHA256 hash in the
KRL. KRLs that revoke keys by SHA256 hash are not supported by
OpenSSH versions prior to 7.9.
hash: fingerprint
Revokes a key using a fingerprint hash, as obtained from a
sshd(8) authentication log message or the ssh-keygen -l flag.
Only SHA256 fingerprints are supported here and resultant KRLs
are not supported by OpenSSH versions prior to 7.9.
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 command line. 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.
ALLOWED SIGNERS
When verifying signatures, ssh-keygen uses a simple list of identities
and keys to determine whether a signature comes from an authorized
source. This "allowed signers" file uses a format patterned after the
AUTHORIZED_KEYS FILE FORMAT described in sshd(8). Each line of the file
contains the following space-separated fields: principals, options,
keytype, base64-encoded key. Empty lines and lines starting with a M-bM-^@M-^X#M-bM-^@M-^Y
are ignored as comments.
The principals field is a pattern-list (see PATTERNS in ssh_config(5))
consisting of one or more comma-separated USER@DOMAIN identity patterns
that are accepted for signing. When verifying, the identity presented
via the -I option must match a principals pattern in order for the
corresponding key to be considered acceptable for verification.
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
Indicates that this key is accepted as a certificate authority
(CA) and that certificates signed by this CA may be accepted for
verification.
namespaces=namespace-list
Specifies a pattern-list of namespaces that are accepted for this
key. If this option is present, the signature namespace embedded
in the signature object and presented on the verification
command-line must match the specified list before the key will be
considered acceptable.
valid-after=timestamp
Indicates that the key is valid for use at or after the specified
timestamp, which may be a date or time in the YYYYMMDD[Z] or
YYYYMMDDHHMM[SS][Z] formats. Dates and times will be interpreted
in the current system time zone unless suffixed with a Z
character, which causes them to be interpreted in the UTC time
zone.
valid-before=timestamp
Indicates that the key is valid for use at or before the
specified timestamp.
When verifying signatures made by certificates, the expected principal
name must match both the principals pattern in the allowed signers file
and the principals embedded in the certificate itself.
An example allowed signers file:
# Comments allowed at start of line
user1@example.com,user2@example.com ssh-rsa AAAAX1...
# A certificate authority, trusted for all principals in a domain.
*@example.com cert-authority ssh-ed25519 AAAB4...
# A key that is accepted only for file signing.
user2@example.com namespaces="file" ssh-ed25519 AAA41...
ENVIRONMENT
SSH_SK_PROVIDER
Specifies a path to a library that will be used when loading any
FIDO authenticator-hosted keys, overriding the default of using
the built-in USB HID support.
FILES
~/.ssh/id_ecdsa
~/.ssh/id_ecdsa_sk
~/.ssh/id_ed25519
~/.ssh/id_ed25519_sk
~/.ssh/id_rsa
Contains the ECDSA, authenticator-hosted ECDSA, Ed25519,
authenticator-hosted 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_ecdsa.pub
~/.ssh/id_ecdsa_sk.pub
~/.ssh/id_ed25519.pub
~/.ssh/id_ed25519_sk.pub
~/.ssh/id_rsa.pub
Contains the ECDSA, authenticator-hosted ECDSA, Ed25519,
authenticator-hosted 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 7.5 June 17, 2024 OpenBSD 7.5

123
ssh-keyscan.0 Normal file
View File

@ -0,0 +1,123 @@
SSH-KEYSCAN(1) General Commands Manual SSH-KEYSCAN(1)
NAME
ssh-keyscan M-bM-^@M-^S gather SSH public keys from servers
SYNOPSIS
ssh-keyscan [-46cDHqv] [-f file] [-O option] [-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, the format of which is documented in sshd(8).
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 sshd(8). For scanning, one does not need
login access to the machines that are being scanned, nor does the
scanning process involve any encryption.
Hosts to be scanned may be specified by hostname, address or by CIDR
network range (e.g. 192.168.16/28). If a network range is specified,
then all addresses in that range will be scanned.
The options are as follows:
-4 Force ssh-keyscan to use IPv4 addresses only.
-6 Force ssh-keyscan to use IPv6 addresses only.
-c Request certificates from target hosts instead of plain keys.
-D Print keys found as SSHFP DNS records. The default is to print
keys in a format usable as a ssh(1) known_hosts file.
-f file
Read hosts or M-bM-^@M-^\addrlist namelistM-bM-^@M-^] pairs from file, one per line.
If M-bM-^@M-^X-M-bM-^@M-^Y is supplied instead of a filename, ssh-keyscan will read
from the standard input. Names read from a file must start with
an address, hostname or CIDR network range to be scanned.
Addresses and hostnames may optionally be followed by comma-
separated name or address aliases that will be copied to the
output. For example:
192.168.11.0/24
10.20.1.1
happy.example.org
10.0.0.1,sad.example.org
-H Hash all hostnames and addresses in the output. Hashed names may
be used normally by ssh(1) and sshd(8), but they do not reveal
identifying information should the file's contents be disclosed.
-O option
Specify a key/value option. At present, only a single option is
supported:
hashalg=algorithm
Selects a hash algorithm to use when printing SSHFP
records using the -D flag. Valid algorithms are M-bM-^@M-^\sha1M-bM-^@M-^]
and M-bM-^@M-^\sha256M-bM-^@M-^]. The default is to print both.
-p port
Connect to port on the remote host.
-q Quiet mode: do not print server host name and banners in
comments.
-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, the connection is
closed and the host in question considered unavailable. The
default is 5 seconds.
-t type
Specify the type of the key to fetch from the scanned hosts. The
possible values are M-bM-^@M-^\ecdsaM-bM-^@M-^], M-bM-^@M-^\ed25519M-bM-^@M-^], M-bM-^@M-^\ecdsa-skM-bM-^@M-^], M-bM-^@M-^\ed25519-skM-bM-^@M-^],
or M-bM-^@M-^\rsaM-bM-^@M-^]. Multiple values may be specified by separating them
with commas. The default is to fetch all the above key types.
-v Verbose mode: print debugging messages about progress.
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
/etc/ssh/ssh_known_hosts
EXAMPLES
Print the RSA host key for machine hostname:
$ ssh-keyscan -t rsa hostname
Search a network range, printing all supported key types:
$ ssh-keyscan 192.168.0.64/25
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,ecdsa,ed25519 -f ssh_hosts | \
sort -u - ssh_known_hosts | diff ssh_known_hosts -
SEE ALSO
ssh(1), sshd(8)
Using DNS to Securely Publish Secure Shell (SSH) Key Fingerprints, RFC
4255, 2006.
AUTHORS
David Mazieres <dm@lcs.mit.edu> wrote the initial version, and Wayne
Davison <wayned@users.sourceforge.net> added support for protocol version
2.
OpenBSD 7.5 June 17, 2024 OpenBSD 7.5

50
ssh-keysign.0 Normal file
View File

@ -0,0 +1,50 @@
SSH-KEYSIGN(8) System Manager's Manual SSH-KEYSIGN(8)
NAME
ssh-keysign M-bM-^@M-^S OpenSSH helper 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.
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_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_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 7.5 June 17, 2024 OpenBSD 7.5

35
ssh-pkcs11-helper.0 Normal file
View File

@ -0,0 +1,35 @@
SSH-PKCS11-HELPER(8) System Manager's Manual SSH-PKCS11-HELPER(8)
NAME
ssh-pkcs11-helper M-bM-^@M-^S OpenSSH helper for PKCS#11 support
SYNOPSIS
ssh-pkcs11-helper [-v]
DESCRIPTION
ssh-pkcs11-helper is used by ssh(1), ssh-agent(1), and ssh-keygen(1) to
access keys provided by a PKCS#11 token.
ssh-pkcs11-helper is not intended to be invoked directly by the user.
A single option is supported:
-v Verbose mode. Causes ssh-pkcs11-helper to print debugging
messages about its progress. This is helpful in debugging
problems. Multiple -v options increase the verbosity. The
maximum is 3.
Note that ssh(1), ssh-agent(1), and ssh-keygen(1) will
automatically pass the -v flag to ssh-pkcs11-helper when they
have themselves been placed in debug mode.
SEE ALSO
ssh(1), ssh-agent(1), ssh-keygen(1)
HISTORY
ssh-pkcs11-helper first appeared in OpenBSD 4.7.
AUTHORS
Markus Friedl <markus@openbsd.org>
OpenBSD 7.5 April 29, 2022 OpenBSD 7.5

34
ssh-sk-helper.0 Normal file
View File

@ -0,0 +1,34 @@
SSH-SK-HELPER(8) System Manager's Manual SSH-SK-HELPER(8)
NAME
ssh-sk-helper M-bM-^@M-^S OpenSSH helper for FIDO authenticator support
SYNOPSIS
ssh-sk-helper [-v]
DESCRIPTION
ssh-sk-helper is used by ssh(1), ssh-agent(1), and ssh-keygen(1) to
access keys provided by a FIDO authenticator.
ssh-sk-helper is not intended to be invoked directly by the user.
A single option is supported:
-v Verbose mode. Causes ssh-sk-helper to print debugging messages
about its progress. This is helpful in debugging problems.
Multiple -v options increase the verbosity. The maximum is 3.
Note that ssh(1), ssh-agent(1), and ssh-keygen(1) will
automatically pass the -v flag to ssh-sk-helper when they have
themselves been placed in debug mode.
SEE ALSO
ssh(1), ssh-agent(1), ssh-keygen(1)
HISTORY
ssh-sk-helper first appeared in OpenBSD 6.7.
AUTHORS
Damien Miller <djm@openbsd.org>
OpenBSD 7.5 April 29, 2022 OpenBSD 7.5

1019
ssh.0 Normal file
View File

File diff suppressed because it is too large Load Diff

1431
ssh_config.0 Normal file
View File

File diff suppressed because it is too large Load Diff

685
sshd.0 Normal file
View File

@ -0,0 +1,685 @@
SSHD(8) System Manager's Manual SSHD(8)
NAME
sshd M-bM-^@M-^S OpenSSH daemon
SYNOPSIS
sshd [-46DdeGiqTtV] [-C connection_spec] [-c host_certificate_file]
[-E log_file] [-f config_file] [-g login_grace_time]
[-h host_key_file] [-o option] [-p port] [-u len]
DESCRIPTION
sshd (OpenSSH Daemon) is the daemon program for ssh(1). It provides
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.
-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 are applied before the configuration is
written to standard output. The connection parameters are
supplied as keyword=value pairs and may be supplied in any order,
either with multiple -C options or as a comma-separated list.
The keywords are M-bM-^@M-^\addrM-bM-^@M-^], 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-^\rdomainM-bM-^@M-^] and correspond to source address, user, resolved source
host name, local address, local port number and routing domain
respectively.
-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(2) 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 Parse and print configuration file. 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.
-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_ecdsa_key, /etc/ssh/ssh_host_ed25519_key and
/etc/ssh/ssh_host_rsa_key. It is possible to have multiple host
key files for the different host key algorithms.
-i Specifies that sshd is being run from inetd(8).
-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. This is
similar to the -G flag, but it includes the additional testing
performed by the -t flag.
-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 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.
-V Display the version number and exit.
AUTHENTICATION
The OpenSSH SSH daemon supports SSH protocol 2 only. Each host has a
host-specific key, used to identify the host. Whenever a client
connects, the daemon responds with its public host key. The client
compares the host key against its own database to verify that it has not
changed. Forward secrecy is provided through a Diffie-Hellman key
agreement. This key agreement results in a shared session key. The rest
of the session is encrypted using a symmetric cipher. The client selects
the encryption algorithm to use from those offered by the server.
Additionally, session integrity is provided through a cryptographic
message authentication code (MAC).
Finally, the server and the client enter an authentication dialog. The
client tries to authenticate itself using host-based authentication,
public key authentication, challenge-response authentication, or password
authentication.
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 dependent. 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 an interactive shell or execution
of a non-interactive command, which sshd will execute via the user's
shell using its -c option. 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(1). 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 this option is not 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). Public keys consist of the following space-
separated fields: options, keytype, base64-encoded key, comment. The
options field is optional. The supported key types are:
sk-ecdsa-sha2-nistp256@openssh.com
ecdsa-sha2-nistp256
ecdsa-sha2-nistp384
ecdsa-sha2-nistp521
sk-ssh-ed25519@openssh.com
ssh-ed25519
ssh-rsa
The comment field is not used for anything (but may be convenient for the
user to identify the key).
Note that lines in this file can be several hundred bytes long (because
of the size of the public key encoding) up to a limit of 8 kilobytes,
which permits RSA keys up to 16 kilobits. You don't want to type them
in; instead, copy the id_ecdsa.pub, id_ecdsa_sk.pub, id_ed25519.pub,
id_ed25519_sk.pub, or the id_rsa.pub file and edit it.
sshd enforces a minimum RSA key modulus size of 1024 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):
agent-forwarding
Enable authentication agent forwarding previously disabled by the
restrict option.
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, e.g. using the restrict key option.
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 a sshd_config(5) ForceCommand
directive.
If a command is specified and a forced-command is embedded in a
certificate used for authentication, then the certificate will be
accepted only if the two commands are identical.
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.
expiry-time="timespec"
Specifies a time after which the key will not be accepted. The
time may be specified as a YYYYMMDD[Z] date or a
YYYYMMDDHHMM[SS][Z] time. Dates and times will be interpreted in
the system time zone unless suffixed by a Z character, in which
case they will be interpreted in the UTC time zone.
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.
permitlisten="[host:]port"
Limit remote port forwarding with the ssh(1) -R option such that
it may only listen on the specified host (optional) and port.
IPv6 addresses can be specified by enclosing the address in
square brackets. Multiple permitlisten options may be applied
separated by commas. Hostnames may include wildcards as
described in the PATTERNS section in ssh_config(5). A port
specification of * matches any port. Note that the setting of
GatewayPorts may further restrict listen addresses. Note that
ssh(1) will send a hostname of M-bM-^@M-^\localhostM-bM-^@M-^] if a listen host was
not specified when the forwarding was requested, and that this
name is treated differently to the explicit localhost addresses
M-bM-^@M-^\127.0.0.1M-bM-^@M-^] and M-bM-^@M-^\::1M-bM-^@M-^].
permitopen="host:port"
Limit local port forwarding with the ssh(1) -L option 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 or name lookup is performed on
the specified hostnames, they must be literal host names and/or
addresses. A port specification of * matches any port.
port-forwarding
Enable port forwarding previously disabled by the restrict
option.
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.
pty Permits tty allocation previously disabled by the restrict
option.
no-touch-required
Do not require demonstration of user presence for signatures made
using this key. This option only makes sense for the FIDO
authenticator algorithms ecdsa-sk and ed25519-sk.
verify-required
Require that signatures made using this key attest that they
verified the user, e.g. via a PIN. This option only makes sense
for the FIDO authenticator algorithms ecdsa-sk and ed25519-sk.
restrict
Enable all restrictions, i.e. disable port, agent and X11
forwarding, as well as disabling PTY allocation and execution of
~/.ssh/rc. If any future restriction capabilities are added to
authorized_keys files, they will be included in this set.
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.
user-rc
Enables execution of ~/.ssh/rc previously disabled by the
restrict option.
X11-forwarding
Permits X11 forwarding previously disabled by the restrict
option.
An example authorized_keys file:
# Comments are allowed at start of line. Blank lines are allowed.
# Plain key, no restrictions
ssh-rsa ...
# Forced command, disable PTY and all forwarding
restrict,command="dump /home" ssh-rsa ...
# Restriction of ssh -L forwarding destinations
permitopen="192.0.2.1:80",permitopen="192.0.2.2:25" ssh-rsa ...
# Restriction of ssh -R forwarding listeners
permitlisten="localhost:8080",permitlisten="[::1]:22000" ssh-rsa ...
# Configuration for tunnel forwarding
tunnel="0",command="sh /etc/netstart tun0" ssh-rsa ...
# Override of restriction to allow PTY allocation
restrict,pty,command="nethack" ssh-rsa ...
# Allow FIDO key without requiring touch
no-touch-required sk-ecdsa-sha2-nistp256@openssh.com ...
# Require user-verification (e.g. PIN or biometric) for FIDO key
verify-required sk-ecdsa-sha2-nistp256@openssh.com ...
# Trust CA key, allow touch-less FIDO if requested in certificate
cert-authority,no-touch-required,principals="user_a" ssh-rsa ...
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 to an unknown host, its key is
added to the per-user file.
Each line in these files contains the following fields: marker
(optional), hostnames, keytype, base64-encoded key, 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 host name. When
sshd is authenticating a client, such as when using
HostbasedAuthentication, this will be the canonical client host name.
When ssh(1) is authenticating a server, this will be the host name given
by the user, the value of the ssh(1) HostkeyAlias if it was specified, or
the canonical server hostname if the ssh(1) CanonicalizeHostname option
was used.
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.
The keytype and base64-encoded key are taken directly from the host key;
they can be obtained, for example, from /etc/ssh/ssh_host_rsa_key.pub.
The optional comment field continues to the end of the line, and is not
used.
Lines starting with 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, for
example, /etc/ssh/ssh_host_rsa_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
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 (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.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" key exchange method. The file format is described in
moduli(5). If no usable groups are found in this file then fixed
internal groups will be used.
/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_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_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), 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 7.5 June 17, 2024 OpenBSD 7.5

1393
sshd_config.0 Normal file
View File

File diff suppressed because it is too large Load Diff