SSH(1)                                               General Commands Manual                                              SSH(1)

NAME
       ssh — OpenSSH remote login client

SYNOPSIS
       ssh   [-46AaCfGgKkMNnqsTtVvXxYy]   [-B  bind_interface]  [-b  bind_address]  [-c  cipher_spec]  [-D  [bind_address:]port]
           [-E log_file] [-e escape_char]  [-F  configfile]  [-I  pkcs11]  [-i  identity_file]  [-J  destination]  [-L  address]
           [-l  login_name]  [-m  mac_spec]  [-O  ctl_cmd]  [-o  option]  [-P  tag]  [-p  port]  [-Q  query_option] [-R address]
           [-S ctl_path] [-W host:port] [-w local_tun[:remote_tun]] destination [command [argument ...]]

DESCRIPTION
       ssh (SSH client) is a program for logging into a remote machine and for executing commands on a remote  machine.   It  is
       intended  to  provide  secure encrypted communications between two untrusted hosts over an insecure network.  X11 connec‐
       tions, arbitrary TCP ports and Unix-domain sockets can also be forwarded over the secure channel.

       ssh connects and logs into the specified destination, which may be specified as either [user@]hostname or a  URI  of  the
       form ssh://[user@]hostname[:port].  The user must prove their identity to the remote machine using one of several methods
       (see below).

       If  a command is specified, it will be executed on the remote host instead of a login shell.  A complete command line may
       be specified as command, or it may have additional arguments.  If supplied, the arguments will be appended  to  the  com‐
       mand, separated by spaces, before it is sent to the server to be executed.

       The options are as follows:

       -4      Forces ssh to use IPv4 addresses only.

       -6      Forces ssh to use IPv6 addresses only.

       -A      Enables  forwarding of connections from an authentication agent such as ssh-agent(1).  This can also be specified
               on a per-host basis in a configuration file.

               Agent forwarding should be enabled with caution.  Users with the ability to bypass file permissions on the remote
               host (for the agent's Unix-domain socket) can access the local agent through the forwarded  connection.   An  at‐
               tacker  cannot  obtain  key  material from the agent, however they can perform operations on the keys that enable
               them to authenticate using the identities loaded into the agent.  A safer alternative may be to use a  jump  host
               (see -J).

       -a      Disables forwarding of the authentication agent connection.

       -B bind_interface
               Bind  to the address of bind_interface before attempting to connect to the destination host.  This is only useful
               on systems with more than one address.

       -b bind_address
               Use bind_address on the local machine as the source address of the connection.  Only useful on systems with  more
               than one address.

       -C      Requests  compression  of  all  data  (including  stdin,  stdout,  stderr,  and  data  for forwarded X11, TCP and
               Unix-domain connections).  The compression algorithm is the same used by gzip(1).  Compression  is  desirable  on
               modem  lines  and other slow connections, but will only slow down things on fast networks.  The default value can
               be set on a host-by-host basis in the configuration files; see the Compression option in ssh_config(5).

       -c cipher_spec
               Selects the cipher specification for encrypting the session.  cipher_spec is a comma-separated  list  of  ciphers
               listed in order of preference.  See the Ciphers keyword in ssh_config(5) for more information.

       -D [bind_address:]port
               Specifies  a  local  “dynamic” application-level port forwarding.  This works by allocating a socket to listen to
               port on the local side, optionally bound to the specified bind_address.  Whenever a connection is  made  to  this
               port, the connection is forwarded over the secure channel, and the application protocol is then used to determine
               where  to  connect  to from the remote machine.  Currently the SOCKS4 and SOCKS5 protocols are supported, and ssh
               will act as a SOCKS server.  Only root can forward privileged ports.  Dynamic port forwardings can also be speci‐
               fied in the configuration file.

               IPv6 addresses can be specified by enclosing the address in square brackets.   Only  the  superuser  can  forward
               privileged  ports.  By default, the local port is bound in accordance with the GatewayPorts setting.  However, an
               explicit bind_address may be used to bind the connection to a specific address.  The bind_address of  “localhost”
               indicates  that  the listening port be bound for local use only, while an empty address or ‘*’ indicates that the
               port should be available from all interfaces.

       -E log_file
               Append debug logs to log_file instead of standard error.

       -e escape_char
               Sets the escape character for sessions with a pty (default: ‘~’).  The escape character is only recognized at the
               beginning of a line.  The escape character followed by a dot (‘.’) closes the connection; followed  by  control-Z
               suspends the connection; and followed by itself sends the escape character once.  Setting the character to “none”
               disables any escapes and makes the session fully transparent.

       -F configfile
               Specifies  an alternative per-user configuration file.  If a configuration file is given on the command line, the
               system-wide configuration file (/etc/ssh/ssh_config) will be ignored.  The default for the per-user configuration
               file is ~/.ssh/config.  If set to “none”, no configuration files will be read.

       -f      Requests ssh to go to background just before command execution.  This is useful if ssh is going to ask for  pass‐
               words  or  passphrases,  but the user wants it in the background.  This implies -n.  The recommended way to start
               X11 programs at a remote site is with something like ssh -f host xterm.

               If the ExitOnForwardFailure configuration option is set to “yes”, then a client started with -f will wait for all
               remote port forwards to be successfully established before placing itself in the background.  Refer  to  the  de‐
               scription of ForkAfterAuthentication in ssh_config(5) for details.

       -G      Causes ssh to print its configuration after evaluating Host and Match blocks and exit.

       -g      Allows  remote  hosts to connect to local forwarded ports.  If used on a multiplexed connection, then this option
               must be specified on the master process.

       -I pkcs11
               Specify the PKCS#11 shared library ssh should use to communicate with a PKCS#11 token providing keys for user au‐
               thentication.

       -i identity_file
               Selects a file from which the identity (private key) for public key authentication is read.  You can also specify
               a public key file to use the corresponding private key that is loaded in ssh-agent(1) when the private  key  file
               is  not  present  locally.  The default is ~/.ssh/id_rsa, ~/.ssh/id_ecdsa, ~/.ssh/id_ecdsa_sk, ~/.ssh/id_ed25519,
               ~/.ssh/id_ed25519_sk and ~/.ssh/id_dsa.  Identity files may also be specified on a per-host basis in the configu‐
               ration file.  It is possible to have multiple -i options (and  multiple  identities  specified  in  configuration
               files).  If no certificates have been explicitly specified by the CertificateFile directive, ssh will also try to
               load certificate information from the filename obtained by appending -cert.pub to identity filenames.

       -J destination
               Connect  to  the target host by first making an ssh 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  sepa‐
               rated by comma characters.  This is a shortcut to specify a ProxyJump configuration directive.  Note that config‐
               uration  directives  supplied  on  the command-line generally apply to the destination host and not any specified
               jump hosts.  Use ~/.ssh/config to specify configuration for jump hosts.

       -K      Enables GSSAPI-based authentication and forwarding (delegation) of GSSAPI credentials to the server.

       -k      Disables forwarding (delegation) of GSSAPI credentials to the server.

       -L [bind_address:]port:host:hostport
       -L [bind_address:]port:remote_socket
       -L local_socket:host:hostport
       -L local_socket:remote_socket
               Specifies that connections to the given TCP port or Unix socket on the local (client) host are to be forwarded to
               the given host and port, or Unix socket, on the remote side.  This works by allocating a socket to listen to  ei‐
               ther a TCP port on the local side, optionally bound to the specified bind_address, or to a Unix socket.  Whenever
               a connection is made to the local port or socket, the connection is forwarded over the secure channel, and a con‐
               nection is made to either host port hostport, or the Unix socket remote_socket, from the remote machine.

               Port  forwardings  can  also  be  specified in the configuration file.  Only the superuser can forward privileged
               ports.  IPv6 addresses can be specified by enclosing the address in square brackets.

               By default, the local port  is  bound  in  accordance  with  the  GatewayPorts  setting.   However,  an  explicit
               bind_address may be used to bind the connection to a specific address.  The bind_address of “localhost” indicates
               that the listening port be bound for local use only, while an empty address or ‘*’ indicates that the port should
               be available from all interfaces.

       -l login_name
               Specifies  the  user  to  log in as on the remote machine.  This also may be specified on a per-host basis in the
               configuration file.

       -M      Places the ssh client into “master” mode for connection sharing.  Multiple -M options places  ssh  into  “master”
               mode  but  with  confirmation  required  using ssh-askpass(1) before each operation that changes the multiplexing
               state (e.g. opening a new session).  Refer to the description of ControlMaster in ssh_config(5) for details.

       -m mac_spec
               A comma-separated list of MAC (message authentication code) algorithms, specified in order  of  preference.   See
               the MACs keyword in ssh_config(5) for more information.

       -N      Do  not  execute  a  remote  command.   This  is  useful  for just forwarding ports.  Refer to the description of
               SessionType in ssh_config(5) for details.

       -n      Redirects stdin from /dev/null (actually, prevents reading from stdin).  This must be used when ssh is run in the
               background.  A common trick is to use this to run X11  programs  on  a  remote  machine.   For  example,  ssh  -n
               shadows.cs.hut.fi  emacs & will start an emacs on shadows.cs.hut.fi, and the X11 connection will be automatically
               forwarded over an encrypted channel.  The ssh program will be put in the background.  (This does not work if  ssh
               needs  to  ask  for  a password or passphrase; see also the -f option.)  Refer to the description of StdinNull in
               ssh_config(5) for details.

       -O ctl_cmd
               Control an active connection multiplexing master process.  When the -O option is specified, the ctl_cmd  argument
               is  interpreted  and passed to the master process.  Valid commands are: “check” (check that the master process is
               running), “forward” (request forwardings without command execution), “cancel” (cancel forwardings),  “exit”  (re‐
               quest the master to exit), and “stop” (request the master to stop accepting further multiplexing requests).

       -o option
               Can  be used to give options in the format used in the configuration file.  This is useful for specifying options
               for which there is no separate command-line flag.  For full details of the options listed below, and their possi‐
               ble values, see ssh_config(5).

                     AddKeysToAgent
                     AddressFamily
                     BatchMode
                     BindAddress
                     CanonicalDomains
                     CanonicalizeFallbackLocal
                     CanonicalizeHostname
                     CanonicalizeMaxDots
                     CanonicalizePermittedCNAMEs
                     CASignatureAlgorithms
                     CertificateFile
                     CheckHostIP
                     Ciphers
                     ClearAllForwardings
                     Compression
                     ConnectionAttempts
                     ConnectTimeout
                     ControlMaster
                     ControlPath
                     ControlPersist
                     DynamicForward
                     EnableEscapeCommandline
                     EscapeChar
                     ExitOnForwardFailure
                     FingerprintHash
                     ForkAfterAuthentication
                     ForwardAgent
                     ForwardX11
                     ForwardX11Timeout
                     ForwardX11Trusted
                     GatewayPorts
                     GlobalKnownHostsFile
                     GSSAPIAuthentication
                     GSSAPIDelegateCredentials
                     HashKnownHosts
                     Host
                     HostbasedAcceptedAlgorithms
                     HostbasedAuthentication
                     HostKeyAlgorithms
                     HostKeyAlias
                     Hostname
                     IdentitiesOnly
                     IdentityAgent
                     IdentityFile
                     IPQoS
                     KbdInteractiveAuthentication
                     KbdInteractiveDevices
                     KexAlgorithms
                     KnownHostsCommand
                     LocalCommand
                     LocalForward
                     LogLevel
                     MACs
                     Match
                     NoHostAuthenticationForLocalhost
                     NumberOfPasswordPrompts
                     PasswordAuthentication
                     PermitLocalCommand
                     PermitRemoteOpen
                     PKCS11Provider
                     Port
                     PreferredAuthentications
                     ProxyCommand
                     ProxyJump
                     ProxyUseFdpass
                     PubkeyAcceptedAlgorithms
                     PubkeyAuthentication
                     RekeyLimit
                     RemoteCommand
                     RemoteForward
                     RequestTTY
                     RequiredRSASize
                     SendEnv
                     ServerAliveInterval
                     ServerAliveCountMax
                     SessionType
                     SetEnv
                     StdinNull
                     StreamLocalBindMask
                     StreamLocalBindUnlink
                     StrictHostKeyChecking
                     TCPKeepAlive
                     Tunnel
                     TunnelDevice
                     UpdateHostKeys
                     User
                     UserKnownHostsFile
                     VerifyHostKeyDNS
                     VisualHostKey
                     XAuthLocation

       -P tag  Specify a tag name that may be used to select configuration in ssh_config(5).  Refer to the Tag  and  Match  key‐
               words in ssh_config(5) for more information.
       -p port
               Port to connect to on the remote host.  This can be specified on a per-host basis in the configuration file.

       -Q query_option
               Queries  for  the  algorithms  supported  by one of the following features: cipher (supported symmetric ciphers),
               cipher-auth (supported symmetric ciphers that support authenticated encryption), help (supported query terms  for
               use  with  the -Q flag), mac (supported message integrity codes), kex (key exchange algorithms), key (key types),
               key-ca-sign (valid CA signature algorithms for certificates), key-cert (certificate key types),  key-plain  (non-
               certificate  key types), key-sig (all key types and signature algorithms), protocol-version (supported SSH proto‐
               col versions), and sig (supported signature  algorithms).   Alternatively,  any  keyword  from  ssh_config(5)  or
               sshd_config(5) that takes an algorithm list may be used as an alias for the corresponding query_option.

       -q      Quiet mode.  Causes most warning and diagnostic messages to be suppressed.

       -R [bind_address:]port:host:hostport
       -R [bind_address:]port:local_socket
       -R remote_socket:host:hostport
       -R remote_socket:local_socket
       -R [bind_address:]port
               Specifies  that  connections to the given TCP port or Unix socket on the remote (server) host are to be forwarded
               to the local side.

               This works by allocating a socket to listen to either a TCP port or to a Unix socket on the remote  side.   When‐
               ever a connection is made to this port or Unix socket, the connection is forwarded over the secure channel, and a
               connection  is  made from the local machine to either an explicit destination specified by host port hostport, or
               local_socket, or, if no explicit destination was specified, ssh will act as a SOCKS 4/5 proxy and forward connec‐
               tions to the destinations requested by the remote SOCKS client.

               Port forwardings can also be specified in the configuration file.  Privileged ports can be  forwarded  only  when
               logging  in  as  root  on the remote machine.  IPv6 addresses can be specified by enclosing the address in square
               brackets.

              By default, TCP listening sockets on the server will be bound to the loopback interface only.  This may be  over‐
               ridden by specifying a bind_address.  An empty bind_address, or the address ‘*’, indicates that the remote socket
               should listen on all interfaces.  Specifying a remote bind_address will only succeed if the server's GatewayPorts
               option is enabled (see sshd_config(5)).

               If  the  port  argument  is  ‘0’, the listen port will be dynamically allocated on the server and reported to the
               client at run time.  When used together with -O forward, the allocated port will be printed to the standard  out‐
               put.

       -S ctl_path
               Specifies  the  location  of  a control socket for connection sharing, or the string “none” to disable connection
               sharing.  Refer to the description of ControlPath and ControlMaster in ssh_config(5) for details.

       -s      May be used to request invocation of a subsystem on the remote system.  Subsystems facilitate the use of SSH as a
               secure transport for other applications (e.g. sftp(1)).  The subsystem is specified as the remote command.  Refer
               to the description of SessionType in ssh_config(5) for details.

       -T      Disable pseudo-terminal allocation.

       -t      Force pseudo-terminal allocation.  This can be used to execute arbitrary screen-based programs on  a  remote  ma‐
               chine, which can be very useful, e.g. when implementing menu services.  Multiple -t options force tty allocation,
               even if ssh has no local tty.

       -V      Display the version number and exit.

       -v      Verbose  mode.   Causes ssh to print debugging messages about its progress.  This is helpful in debugging connec‐
               tion, authentication, and configuration problems.  Multiple -v options increase the verbosity.  The maximum is 3.

       -W host:port
               Requests that standard input and output on the client be forwarded to host on port over the secure channel.   Im‐
               plies  -N,  -T, ExitOnForwardFailure and ClearAllForwardings, though these can be overridden in the configuration
               file or using -o command line options.

       -w local_tun[:remote_tun]
               Requests tunnel device forwarding with the specified tun(4) devices between the client (local_tun) and the server
               (remote_tun).

               The devices may be specified by numerical ID or the keyword “any”, which uses the next available  tunnel  device.
               If  remote_tun  is  not  specified,  it  defaults  to  “any”.  See also the Tunnel and TunnelDevice directives in
               ssh_config(5).

               If the Tunnel directive is unset, it will be set to the default tunnel mode, which  is  “point-to-point”.   If  a
               different Tunnel forwarding mode it desired, then it should be specified before -w.

       -X      Enables X11 forwarding.  This can also be specified on a per-host basis in a configuration file.

               X11  forwarding  should be enabled with caution.  Users with the ability to bypass file permissions on the remote
               host (for the user's X authorization database) can access the local X11 display through the forwarded connection.
               An attacker may then be able to perform activities such as keystroke monitoring.

               For this reason, X11 forwarding is subjected to X11 SECURITY extension restrictions by default.  Refer to the ssh
               -Y option and the ForwardX11Trusted directive in ssh_config(5) for more information.

       -x      Disables X11 forwarding.

       -Y      Enables trusted X11 forwarding.  Trusted X11 forwardings are not subjected to the  X11  SECURITY  extension  con‐
               trols.

       -y      Send log information using the syslog(3) system module.  By default this information is sent to stderr.

       ssh  may  additionally obtain configuration data from a per-user configuration file and a system-wide configuration file.
       The file format and configuration options are described in ssh_config(5).

AUTHENTICATION
       The OpenSSH SSH client supports SSH protocol 2.

       The methods available for authentication are: GSSAPI-based authentication, host-based authentication, public key  authen‐
       tication,  keyboard-interactive authentication, and password authentication.  Authentication methods are tried in the or‐
       der specified above, though PreferredAuthentications can be used to change the default order.

       Host-based authentication works as follows: If the machine the user  logs  in  from  is  listed  in  /etc/hosts.equiv  or
       /etc/ssh/shosts.equiv  on  the  remote machine, the user is non-root and the user names are the same on both sides, or if
       the files ~/.rhosts or ~/.shosts exist in the user's home directory on the remote machine and contain a  line  containing
       the name of the client machine and the name of the user on that machine, the user is considered for login.  Additionally,
       the  server  must  be  able  to  verify  the  client's  host  key  (see  the  description of /etc/ssh/ssh_known_hosts and
       ~/.ssh/known_hosts, below) for login to be permitted.  This authentication method closes security holes due to IP  spoof‐
       ing,  DNS  spoofing,  and  routing spoofing.  [Note to the administrator: /etc/hosts.equiv, ~/.rhosts, and the rlogin/rsh
       protocol in general, are inherently insecure and should be disabled if security is desired.]

       Public key authentication works as follows: The scheme is based on public-key cryptography, using cryptosystems where en‐
       cryption and decryption are done using separate keys, and it is unfeasible to derive the decryption key from the  encryp‐
       tion  key.   The  idea is that each user creates a public/private key pair for authentication purposes.  The server knows
       the public key, and only the user knows the private key.  ssh implements public  key  authentication  protocol  automati‐
       cally, using one of the DSA, ECDSA, Ed25519 or RSA algorithms.  The HISTORY section of ssl(8) contains a brief discussion
       of the DSA and RSA algorithms.

       The  file ~/.ssh/authorized_keys lists the public keys that are permitted for logging in.  When the user logs in, the ssh
       program tells the server which key pair it would like to use for authentication.  The client proves that it has access to
       the private key and the server checks that the corresponding public key is authorized to accept the account.

       The server may inform the client of errors that prevented public key authentication from succeeding after  authentication
       completes using a different method.  These may be viewed by increasing the LogLevel to DEBUG or higher (e.g. by using the
       -v flag).

       The  user  creates  their  key  pair  by  running  ssh-keygen(1).   This  stores  the private key in ~/.ssh/id_dsa (DSA),
       ~/.ssh/id_ecdsa    (ECDSA),    ~/.ssh/id_ecdsa_sk    (authenticator-hosted    ECDSA),    ~/.ssh/id_ed25519     (Ed25519),
       ~/.ssh/id_ed25519_sk   (authenticator-hosted   Ed25519),   or   ~/.ssh/id_rsa   (RSA)   and  stores  the  public  key  in
       ~/.ssh/id_dsa.pub   (DSA),   ~/.ssh/id_ecdsa.pub   (ECDSA),    ~/.ssh/id_ecdsa_sk.pub    (authenticator-hosted    ECDSA),
       ~/.ssh/id_ed25519.pub  (Ed25519),  ~/.ssh/id_ed25519_sk.pub (authenticator-hosted Ed25519), or ~/.ssh/id_rsa.pub (RSA) in
       the user's home directory.  The user should then copy the public key to ~/.ssh/authorized_keys in their home directory on
       the remote machine.  The authorized_keys file corresponds to the conventional ~/.rhosts file, and has one key  per  line,
       though the lines can be very long.  After this, the user can log in without giving the password.

       A variation on public key authentication is available in the form of certificate authentication: instead of a set of pub‐
       lic/private keys, signed certificates are used.  This has the advantage that a single trusted certification authority can
       be used in place of many public/private keys.  See the CERTIFICATES section of ssh-keygen(1) for more information.

       The  most  convenient  way  to  use  public  key  or certificate authentication may be with an authentication agent.  See
       ssh-agent(1) and (optionally) the AddKeysToAgent directive in ssh_config(5) for more information.

       Keyboard-interactive authentication works as follows: The server sends an arbitrary "challenge" text and  prompts  for  a
       response,  possibly  multiple  times.   Examples  of  keyboard-interactive authentication include BSD Authentication (see
       login.conf(5)) and PAM (some non-OpenBSD systems).

       Finally, if other authentication methods fail, ssh prompts the user for a password.  The password is sent to  the  remote
       host  for  checking; however, since all communications are encrypted, the password cannot be seen by someone listening on
       the network.

       ssh automatically maintains and checks a database containing identification for all hosts it has  ever  been  used  with.
       Host keys are stored in ~/.ssh/known_hosts in the user's home directory.  Additionally, the file /etc/ssh/ssh_known_hosts
      is automatically checked for known hosts.  Any new hosts are automatically added to the user's file.  If a host's identi‐
       fication  ever  changes,  ssh warns about this and disables password authentication to prevent server spoofing or man-in-
       the-middle attacks, which could otherwise be used to circumvent the encryption.  The StrictHostKeyChecking option can  be
       used to control logins to machines whose host key is not known or has changed.

       When  the user's identity has been accepted by the server, the server either executes the given command in a non-interac‐
       tive session or, if no command has been specified, logs into the machine and gives the user a normal shell as an interac‐
       tive session.  All communication with the remote command or shell will be automatically encrypted.

       If an interactive session is requested, ssh by default will only request a pseudo-terminal (pty) for interactive sessions
       when the client has one.  The flags -T and -t can be used to override this behaviour.

       If a pseudo-terminal has been allocated, the user may use the escape characters noted below.

       If no pseudo-terminal has been allocated, the session is transparent and can be used to reliably  transfer  binary  data.
       On most systems, setting the escape character to “none” will also make the session transparent even if a tty is used.

       The  session  terminates  when the command or shell on the remote machine exits and all X11 and TCP connections have been
       closed.

ESCAPE CHARACTERS
       When a pseudo-terminal has been requested, ssh supports a number of functions through the use of an escape character.

       A single tilde character can be sent as ~~ or by following the tilde by a character other  than  those  described  below.
       The  escape  character must always follow a newline to be interpreted as special.  The escape character can be changed in
       configuration files using the EscapeChar configuration directive or on the command line by the -e option.

       The supported escapes (assuming the default ‘~’) are:

       ~.      Disconnect.

       ~^Z     Background ssh.

       ~#      List forwarded connections.

       ~&      Background ssh at logout when waiting for forwarded connection / X11 sessions to terminate.

       ~?      Display a list of escape characters.

       ~B      Send a BREAK to the remote system (only useful if the peer supports it).

       ~C      Open command line.  Currently this allows the addition of port forwardings using the -L, -R and -D  options  (see
               above).   It  also  allows  the  cancellation of existing port-forwardings with -KL[bind_address:]port for local,
               -KR[bind_address:]port for remote and -KD[bind_address:]port for dynamic port-forwardings.  !command  allows  the
               user  to  execute  a  local  command if the PermitLocalCommand option is enabled in ssh_config(5).  Basic help is
               available, using the -h option.

       ~R      Request rekeying of the connection (only useful if the peer supports it).

       ~V      Decrease the verbosity (LogLevel) when errors are being written to stderr.

       ~v      Increase the verbosity (LogLevel) when errors are being written to stderr.

TCP FORWARDING
       Forwarding of arbitrary TCP connections over a secure channel can be specified either on the command line or in a config‐
       uration file.  One possible application of TCP forwarding is a secure connection to  a  mail  server;  another  is  going
       through firewalls.

       In  the  example  below, we look at encrypting communication for an IRC client, even though the IRC server it connects to
       does not directly support encrypted communication.  This works as follows: the user connects to  the  remote  host  using
       ssh,  specifying the ports to be used to forward the connection.  After that it is possible to start the program locally,
       and ssh will encrypt and forward the connection to the remote server.

       The following example tunnels an IRC session from the client to an IRC server at  “server.example.com”,  joining  channel
       “#users”, nickname “pinky”, using the standard IRC port, 6667:

           $ ssh -f -L 6667:localhost:6667 server.example.com sleep 10
           $ irc -c '#users' pinky IRC/127.0.0.1

       The  -f  option backgrounds ssh and the remote command “sleep 10” is specified to allow an amount of time (10 seconds, in
       the example) to start the program which is going to use the tunnel.  If no connections are made within  the  time  speci‐
       fied, ssh will exit.

X11 FORWARDING
       If  the  ForwardX11 variable is set to “yes” (or see the description of the -X, -x, and -Y options above) and the user is
       using X11 (the DISPLAY environment variable is set), the connection to the X11 display is automatically forwarded to  the
       remote  side  in such a way that any X11 programs started from the shell (or command) will go through the encrypted chan‐
       nel, and the connection to the real X server will be made from the local machine.   The  user  should  not  manually  set
       DISPLAY.  Forwarding of X11 connections can be configured on the command line or in configuration files.

       The DISPLAY value set by ssh will point to the server machine, but with a display number greater than zero.  This is nor‐
       mal, and happens because ssh creates a “proxy” X server on the server machine for forwarding the connections over the en‐
       crypted channel.

       ssh  will  also  automatically set up Xauthority data on the server machine.  For this purpose, it will generate a random
       authorization cookie, store it in Xauthority on the server, and verify that any forwarded connections carry  this  cookie
       and  replace  it  by  the real cookie when the connection is opened.  The real authentication cookie is never sent to the
       server machine (and no cookies are sent in the plain).

       If the ForwardAgent variable is set to “yes” (or see the description of the -A and -a options above) and the user is  us‐
       ing an authentication agent, the connection to the agent is automatically forwarded to the remote side.

VERIFYING HOST KEYS
       When connecting to a server for the first time, a fingerprint of the server's public key is presented to the user (unless
       the option StrictHostKeyChecking has been disabled).  Fingerprints can be determined using ssh-keygen(1):

             $ ssh-keygen -l -f /etc/ssh/ssh_host_rsa_key

       If  the  fingerprint  is  already known, it can be matched and the key can be accepted or rejected.  If only legacy (MD5)
       fingerprints for the server are available, the ssh-keygen(1) -E option may be used to downgrade the fingerprint algorithm
       to match.

       Because of the difficulty of comparing host keys just by looking at fingerprint strings, there is also support to compare
       host keys visually, using random art.  By setting the VisualHostKey option to “yes”, a small ASCII graphic gets displayed
       on every login to a server, no matter if the session itself is interactive or not.   By  learning  the  pattern  a  known
       server  produces,  a  user  can easily find out that the host key has changed when a completely different pattern is dis‐
       played.  Because these patterns are not unambiguous however, a pattern that looks similar to the pattern remembered  only
       gives a good probability that the host key is the same, not guaranteed proof.

       To  get  a listing of the fingerprints along with their random art for all known hosts, the following command line can be
       used:

             $ ssh-keygen -lv -f ~/.ssh/known_hosts

       If the fingerprint is unknown, an alternative method of verification is available: SSH fingerprints verified by DNS.   An
       additional resource record (RR), SSHFP, is added to a zonefile and the connecting client is able to match the fingerprint
       with that of the key presented.

       In  this example, we are connecting a client to a server, “host.example.com”.  The SSHFP resource records should first be
       added to the zonefile for host.example.com:

             $ ssh-keygen -r host.example.com.

       The output lines will have to be added to the zonefile.  To check that the zone is answering fingerprint queries:

             $ dig -t SSHFP host.example.com

       Finally the client connects:

             $ ssh -o "VerifyHostKeyDNS ask" host.example.com
             [...]
             Matching host key fingerprint found in DNS.
             Are you sure you want to continue connecting (yes/no)?

       See the VerifyHostKeyDNS option in ssh_config(5) for more information.

SSH-BASED VIRTUAL PRIVATE NETWORKS
       ssh contains support for Virtual Private Network (VPN) tunnelling using the tun(4) network  pseudo-device,  allowing  two
       networks  to  be  joined securely.  The sshd_config(5) configuration option PermitTunnel controls whether the server sup‐
       ports this, and at what level (layer 2 or 3 traffic).

       The following example would connect client network 10.0.50.0/24 with remote network 10.0.99.0/24 using  a  point-to-point
       connection  from  10.1.1.1  to  10.1.1.2,  provided  that the SSH server running on the gateway to the remote network, at
       192.168.1.15, allows it.

       On the client:

             # ssh -f -w 0:1 192.168.1.15 true
             # ifconfig tun0 10.1.1.1 10.1.1.2 netmask 255.255.255.252
             # route add 10.0.99.0/24 10.1.1.2

       On the server:

             # ifconfig tun1 10.1.1.2 10.1.1.1 netmask 255.255.255.252
             # route add 10.0.50.0/24 10.1.1.1

       Client access may be more finely tuned via the /root/.ssh/authorized_keys file (see below) and the PermitRootLogin server
       option.  The following entry would permit connections on tun(4) device 1 from user “jane” and on tun device 2  from  user
       “john”, if PermitRootLogin is set to “forced-commands-only”:

         tunnel="1",command="sh /etc/netstart tun1" ssh-rsa ... jane
         tunnel="2",command="sh /etc/netstart tun2" ssh-rsa ... john

       Since  an SSH-based setup entails a fair amount of overhead, it may be more suited to temporary setups, such as for wire‐
       less VPNs.  More permanent VPNs are better provided by tools such as ipsecctl(8) and isakmpd(8).

ENVIRONMENT
       ssh will normally set the following environment variables:

       DISPLAY               The DISPLAY variable indicates the location of the X11 server.  It is automatically set by  ssh  to
                             point  to  a  value  of  the form “hostname:n”, where “hostname” indicates the host where the shell
                             runs, and ‘n’ is an integer ≥ 1.  ssh uses this special value to forward X11 connections  over  the
                             secure  channel.   The user should normally not set DISPLAY explicitly, as that will render the X11
                             connection insecure (and will require the user to manually copy any  required  authorization  cook‐
                             ies).

       HOME                  Set to the path of the user's home directory.

       LOGNAME               Synonym for USER; set for compatibility with systems that use this variable.

       MAIL                  Set to the path of the user's mailbox.

       PATH                  Set to the default PATH, as specified when compiling ssh.

       SSH_ASKPASS           If ssh needs a passphrase, it will read the passphrase from the current terminal if it was run from
                             a  terminal.   If  ssh  does not have a terminal associated with it but DISPLAY and SSH_ASKPASS are
                             set, it will execute the program specified by SSH_ASKPASS and  open  an  X11  window  to  read  the
                             passphrase.   This  is  particularly  useful  when  calling ssh from a .xsession or related script.
                             (Note that on some machines it may be necessary to redirect the input from /dev/null to  make  this
                             work.)

       SSH_ASKPASS_REQUIRE   Allows further control over the use of an askpass program.  If this variable is set to “never” then
                             ssh  will  never  attempt  to  use  one.  If it is set to “prefer”, then ssh will prefer to use the
                             askpass program instead of the TTY when requesting passwords.  Finally, if the variable is  set  to
                             “force”,  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_CONNECTION        Identifies the client and server ends of the connection.  The variable  contains  four  space-sepa‐
                             rated values: client IP address, client port number, server IP address, and server port number.

       SSH_ORIGINAL_COMMAND  This  variable  contains the original command line if a forced command is executed.  It can be used
                             to extract the original arguments.

       SSH_TTY               This is set to the name of the tty (path to the device) associated with the current shell  or  com‐
                             mand.  If the current session has no tty, this variable is not set.

       SSH_TUNNEL            Optionally  set  by  sshd(8)  to  contain the interface names assigned if tunnel forwarding was re‐
                             quested by the client.

       SSH_USER_AUTH         Optionally set by sshd(8), this variable may contain a pathname to a file that lists the  authenti‐
                             cation  methods  successfully used when the session was established, including any public keys that
                             were used.

       TZ                    This variable is set to indicate the present time zone if it was set when the  daemon  was  started
                             (i.e. the daemon passes the value on to new connections).

       USER                  Set to the name of the user logging in.

       Additionally,  ssh  reads ~/.ssh/environment, and adds lines of the format “VARNAME=value” to the environment if the file
       exists and users are allowed to change their environment.  For more information, see the PermitUserEnvironment option  in
       sshd_config(5).

FILES
       ~/.rhosts
               This  file  is  used for host-based authentication (see above).  On some machines this file may need to be world-
               readable if the user's home directory is on an NFS partition, because sshd(8) reads it  as  root.   Additionally,
               this  file  must be owned by the user, and must not have write permissions for anyone else.  The recommended per‐
               mission 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 lo‐
               gin with rlogin/rsh.

       ~/.ssh/
               This directory is the default location for all user-specific configuration and authentication information.  There
               is no general requirement to keep the entire contents of this directory secret, but the  recommended  permissions
               are read/write/execute for the user, and not accessible by others.

       ~/.ssh/authorized_keys
               Lists  the  public  keys  (DSA, ECDSA, Ed25519, RSA) that can be used for logging in as this user.  The format of
               this file is described in the sshd(8) manual page.  This file is not highly sensitive, but the  recommended  per‐
               missions are read/write for the user, and not accessible by others.

       ~/.ssh/config
               This  is  the  per-user  configuration  file.   The  file  format  and  configuration  options  are  described in
               ssh_config(5).  Because of the potential for abuse, this file must have strict permissions:  read/write  for  the
               user, and not writable by others.

       ~/.ssh/environment
               Contains additional definitions for environment variables; see “ENVIRONMENT”, above.

       ~/.ssh/id_dsa
       ~/.ssh/id_ecdsa
       ~/.ssh/id_ecdsa_sk
       ~/.ssh/id_ed25519
       ~/.ssh/id_ed25519_sk
       ~/.ssh/id_rsa
               Contains  the  private  key for authentication.  These files contain sensitive data and should be readable by the
               user but not accessible by others (read/write/execute).  ssh will simply ignore a private key file if it  is  ac‐
               cessible by others.  It is possible to specify a passphrase when generating the key which will be used to encrypt
               the sensitive part of this file using AES-128.

       ~/.ssh/id_dsa.pub
       ~/.ssh/id_ecdsa.pub
       ~/.ssh/id_ecdsa_sk.pub
       ~/.ssh/id_ed25519.pub
       ~/.ssh/id_ed25519_sk.pub
       ~/.ssh/id_rsa.pub
               Contains  the public key for authentication.  These files are not sensitive and can (but need not) be readable by
               anyone.

       ~/.ssh/known_hosts
               Contains a list of host keys for all hosts the user has logged into that are not already in the  systemwide  list
               of known host keys.  See sshd(8) for further details of the format of this file.

       ~/.ssh/rc
               Commands  in  this  file  are executed by ssh when the user logs in, just before the user's shell (or command) is
               started.  See the sshd(8) manual page for more information.

       /etc/hosts.equiv
               This file is for host-based authentication (see above).  It should only be writable by root.

       /etc/ssh/shosts.equiv
               This file is used in exactly the same way as hosts.equiv, but allows host-based authentication without permitting
               login with rlogin/rsh.

       /etc/ssh/ssh_config
               Systemwide configuration file.  The file format and configuration options are described in ssh_config(5).

       /etc/ssh/ssh_host_key
       /etc/ssh/ssh_host_dsa_key
       /etc/ssh/ssh_host_ecdsa_key
       /etc/ssh/ssh_host_ed25519_key
       /etc/ssh/ssh_host_rsa_key
               These files contain the private parts of the host keys and are used for host-based authentication.

       /etc/ssh/ssh_known_hosts
               Systemwide list of known host keys.  This file should be prepared by the system administrator to contain the pub‐
       /etc/ssh/ssh_host_dsa_key
       /etc/ssh/ssh_host_ecdsa_key
       /etc/ssh/ssh_host_ed25519_key
       /etc/ssh/ssh_host_rsa_key
               These files contain the private parts of the host keys and are used for host-based authentication.

       /etc/ssh/ssh_known_hosts
               Systemwide list of known host keys.  This file should be prepared by the system administrator to contain the pub‐
               lic host keys of all machines in the organization.  It should be world-readable.  See sshd(8) for further details
               of the format of this file.

       /etc/ssh/sshrc
               Commands in this file are executed by ssh when the user logs in, just before the user's  shell  (or  command)  is
               started.  See the sshd(8) manual page for more information.

EXIT STATUS
       ssh exits with the exit status of the remote command or with 255 if an error occurred.

SEE ALSO
       scp(1), sftp(1), ssh-add(1), ssh-agent(1), ssh-keygen(1), ssh-keyscan(1), tun(4), ssh_config(5), ssh-keysign(8), sshd(8)

STANDARDS
       S. Lehtinen and C. Lonvick, The Secure Shell (SSH) Protocol Assigned Numbers, RFC 4250, January 2006.

       T. Ylonen and C. Lonvick, The Secure Shell (SSH) Protocol Architecture, RFC 4251, January 2006.

       T. Ylonen and C. Lonvick, The Secure Shell (SSH) Authentication Protocol, RFC 4252, January 2006.

       T. Ylonen and C. Lonvick, The Secure Shell (SSH) Transport Layer Protocol, RFC 4253, January 2006.

       T. Ylonen and C. Lonvick, The Secure Shell (SSH) Connection Protocol, RFC 4254, January 2006.

       J. Schlyter and W. Griffin, Using DNS to Securely Publish Secure Shell (SSH) Key Fingerprints, RFC 4255, January 2006.

       F.  Cusack and M. Forssen, Generic Message Exchange Authentication for the Secure Shell Protocol (SSH), RFC 4256, January
       2006.

       J. Galbraith and P. Remaker, The Secure Shell (SSH) Session Channel Break Extension, RFC 4335, January 2006.

       M. Bellare, T. Kohno, and C. Namprempre, The Secure Shell (SSH) Transport Layer Encryption Modes, RFC 4344, January 2006.

       B. Harris, Improved Arcfour Modes for the Secure Shell (SSH) Transport Layer Protocol, RFC 4345, January 2006.

       M. Friedl, N. Provos, and W. Simpson, Diffie-Hellman Group Exchange for the Secure Shell (SSH) Transport Layer  Protocol,
       RFC 4419, March 2006.

       J. Galbraith and R. Thayer, The Secure Shell (SSH) Public Key File Format, RFC 4716, November 2006.

       D.  Stebila  and  J.  Green, Elliptic Curve Algorithm Integration in the Secure Shell Transport Layer, RFC 5656, December
       2009.

       A. Perrig and D. Song, Hash Visualization: a New Technique to improve Real-World Security, 1999,  International  Workshop
       on Cryptographic Techniques and E-Commerce (CrypTEC '99).

AUTHORS
       OpenSSH  is  a  derivative  of the original and free ssh 1.2.12 release by Tatu Ylonen.  Aaron Campbell, Bob Beck, Markus
       Friedl, Niels Provos, Theo de Raadt and Dug Song removed many bugs, re-added newer features and created OpenSSH.   Markus
       Friedl contributed the support for SSH protocol versions 1.5 and 2.0.

GNU                                                       July 23, 2023                                                   SSH(1)

SSH-KEYGEN(1)                                        General Commands Manual                                       SSH-KEYGEN(1)

NAME
       ssh-keygen — 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 dsa | 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 gen‐
       erate 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 re‐
       voked 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_dsa, ~/.ssh/id_ecdsa, ~/.ssh/id_ecdsa_sk, ~/.ssh/id_ed25519, ~/.ssh/id_ed25519_sk or ~/.ssh/id_rsa.   Addition‐
       ally, 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 “.pub” 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  con‐
       tain 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  pro‐
       tection 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 “user@host” 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  de‐
               fault  comment.   If -f has also been specified, its argument is used as a prefix to the default path for the re‐
               sulting 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.  DSA keys must be exactly 1024 bits as specified by
               FIPS  186-2.  For ECDSA keys, the -b flag determines the key length by selecting from one of three elliptic curve
               sizes: 256, 384 or 521 bits.  Attempting to use bit lengths other than these three values  for  ECDSA  keys  will
               fail.  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 contain‐
               ing 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: “md5” and “sha256”.   The
               default is “sha256”.

       -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 “RFC4716”.  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 speci‐
               fied  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 “RFC4716”.

       -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.  For RSA and DSA keys ssh-keygen tries to find the matching public
               key file and prints its fingerprint.  If combined with -v, a visual ASCII art representation of the key  is  sup‐
               plied with the fingerprint.

       -M generate
               Generate   candidate   Diffie-Hellman   Group   Exchange   (DH-GEX)   parameters   for   eventual   use   by  the
               ‘diffie-hellman-group-exchange-*’ 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/ssh/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: “RFC4716” (RFC 4716/SSH2 public or private key), “PKCS8” (PKCS8 public or  private
               key)  or  “PEM”  (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 “RFC4716”.  Setting a format of “PEM” when  gen‐
               erating  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  “sha256”
                       and “sha512.” The default is “sha512.”

               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 speci‐
                       fied as a date or time in the YYYYMMDD[Z] or in YYYYMMDDHHMM[SS][Z] formats.  Dates and times will be in‐
                       terpreted in the current system time zone unless suffixed with a Z character, which causes them to be in‐
                       terpreted 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
                       “sha1” and “sha256”.  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 dsa | ecdsa | ecdsa-sk | ed25519 | ed25519-sk | rsa
               Specifies the  type  of  key  to  create.   The  possible  values  are  “dsa”,  “ecdsa”,  “ecdsa-sk”,  “ed25519”,
               “ed25519-sk”, or “rsa”.

               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  “ssh-rsa”  (SHA1  signatures,  not  recommended),  “rsa-sha2-256”,  and
               “rsa-sha2-512” (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,  indi‐
               cating  that  the certificate is valid beginning now and expiring at that time, or may consist of two times sepa‐
               rated by a colon to indicate an explicit time interval.

               The start time may be specified as:
               •   The string “always” to indicate the certificate has no specified start time.
               •   A date or time in the system time zone formatted as YYYYMMDD or YYYYMMDDHHMM[SS].
               •   A date or time in the UTC time zone as YYYYMMDDZ or YYYYMMDDHHMM[SS]Z.
               •   A relative time before the current system time consisting of a minus sign followed by an interval in the for‐
                   mat described in the TIME FORMATS section of sshd_config(5).
               •   A raw seconds since epoch (Jan 1 1970 00:00:00 UTC) as a hexadecimal number beginning with “0x”.

               The end time may be specified similarly to the start time:
               •   The string “forever” to indicate the certificate has no specified end time.
               •   A date or time in the system time zone formatted as YYYYMMDD or YYYYMMDDHHMM[SS].
               •   A date or time in the UTC time zone as YYYYMMDDZ or YYYYMMDDHHMM[SS]Z.
               •   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).
               •   A raw seconds since epoch (Jan 1 1970 00:00:00 UTC) as a hexadecimal number beginning with “0x”.

               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 de‐
               fault 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  in‐
               put.   Signatures  are  written  to the path of the input file with “.sig” 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: “file” for file signing, “email” for email signing.  For cus‐
               tom uses, it is recommended to use names following a NAMESPACE@YOUR.DOMAIN pattern to generate unambiguous  name‐
               spaces.

       -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 corre‐
               sponding 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 avail‐
               able ciphers may be obtained using "ssh -Q cipher".  The default is “aes256-ctr”.

       -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 ‘+’ 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

             # 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 op‐
       tion).  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 op‐
       tion.  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/ssh/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.  Certifi‐
       cates consist of a public key, some identity information, zero or more principal (user or host) names and a  set  of  op‐
       tions  that are signed by a Certification Authority (CA) key.  Clients or servers may then trust only the CA key and ver‐
       ify its signature on a certificate rather than trusting many user/host keys.  Note that OpenSSH certificates are  a  dif‐
       ferent, 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 cer‐
       tificate option may disable features of the SSH session, may be valid only when  presented  from  particular  source  ad‐
       dresses 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  suf‐
               fix,  e.g. “name@example.com”.  If contents is specified then it is included as the contents of the extension/op‐
               tion 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-sepa‐
               rated 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  sup‐
               ported 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).  Re‐
       fer 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 gen‐
       erally 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 au‐
       thenticator and that cannot be exported from the authenticator hardware.  These are combined by the hardware at authenti‐
       cation 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 “ssh:”.  This may be useful when generating host or do‐
               main-specific resident keys.  The specified application string must begin with “ssh:”.

       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 re‐
               quire that a PIN be set on the authenticator prior to generation.  Resident keys may be loaded off the  authenti‐
              cator  using  ssh-add(1).  Storing both parts of a key on a FIDO authenticator increases the likelihood of an at‐
               tacker 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 ex‐
       isting 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 de‐
       scribed 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 ‘#’ 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@DO‐
       MAIN  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  speci‐
               fied 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_dsa
       ~/.ssh/id_ecdsa
       ~/.ssh/id_ecdsa_sk
       ~/.ssh/id_ed25519
       ~/.ssh/id_ed25519_sk
       ~/.ssh/id_rsa
               Contains the DSA, 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
               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_dsa
       ~/.ssh/id_ecdsa
       ~/.ssh/id_ecdsa_sk
       ~/.ssh/id_ed25519
       ~/.ssh/id_ed25519_sk
       ~/.ssh/id_rsa
               Contains the DSA, 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_dsa.pub
       ~/.ssh/id_ecdsa.pub
       ~/.ssh/id_ecdsa_sk.pub
       ~/.ssh/id_ed25519.pub
       ~/.ssh/id_ed25519_sk.pub
       ~/.ssh/id_rsa.pub
               Contains  the DSA, 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 se‐
               cret.

       /etc/ssh/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.

GNU                                                     September 4, 2023                                          SSH-KEYGEN(1)