Skip site navigation (1)Skip section navigation (2)

FreeBSD Manual Pages


home | help
SSHD(8)			    System Manager's Manual		       SSHD(8)

       sshd - OpenSSH daemon

       sshd  [-46DdeiqTt]  [-C connection_spec]	[-c host_certificate_file] [-E
       log_file] [-f config_file] [-g login_grace_time]	[-h host_key_file] [-o
       option] [-p port] [-u len]

       sshd  (OpenSSH  Daemon)	is the daemon program for ssh(1).  It provides
       secure encrypted	communications between two untrusted hosts over	an in-
       secure network.

       sshd  listens  for connections from clients.  It	is normally started at
       boot from /usr/local/etc/rc.d/openssh.  It forks	a new daemon for  each
       incoming	 connection.   The forked daemons handle key exchange, encryp-
       tion, authentication, command execution,	and data exchange.

       sshd can	be configured using command-line options  or  a	 configuration
       file (by	default	sshd_config(5))	; command-line options override	values
       specified in the	configuration file.  sshd  rereads  its	 configuration
       file when it receives a hangup signal, SIGHUP, by executing itself with
       the name	and options it was started with, e.g. /usr/sbin/sshd.

       The options are as follows:

       -4     Forces sshd to use IPv4 addresses	only.

       -6     Forces sshd to use IPv6 addresses	only.

       -C connection_spec
	      Specify the connection parameters	to use	for  the  -T  extended
	      test  mode.  If provided,	any Match directives in	the configura-
	      tion file	that would apply are applied before the	 configuration
	      is  written  to  standard	output.	 The connection	parameters are
	      supplied as keyword=value	pairs and may be supplied in  any  or-
	      der,  either  with  multiple  -C options or as a comma-separated
	      list.  The keywords are ``addr'',	``user'', ``host'', ``laddr'',
	      ``lport'',  and  ``rdomain''  and	 correspond to source address,
	      user, resolved source host name, local address, local port  num-
	      ber and routing domain respectively.

       -c host_certificate_file
	      Specifies	 a  path to a certificate file to identify sshd	during
	      key exchange.  The certificate file must match a host  key  file
	      specified	 using	the -h option or the HostKey configuration di-

       -D     When this	option is specified, sshd will not detach and does not
	      become a daemon.	This allows easy monitoring of sshd.

       -d     Debug  mode.   The server	sends verbose debug output to standard
	      error, and does not put itself in	the  background.   The	server
	      also  will  not  fork(2)	and  will only process one connection.
	      This option is only intended for debugging for the server.  Mul-
	      tiple -d options increase	the debugging level.  Maximum is 3.

       -E log_file
	      Append debug logs	to log_file instead of the system log.

       -e     Write debug logs to standard error instead of the	system log.

       -f config_file
	      Specifies	 the  name  of the configuration file.	The default is
	      /usr/local/etc/ssh/sshd_config.  sshd refuses to start if	 there
	      is no configuration file.

       -g login_grace_time
	      Gives the	grace time for clients to authenticate themselves (de-
	      fault 120	seconds).  If the client  fails	 to  authenticate  the
	      user within this many seconds, the server	disconnects and	exits.
	      A	value of zero indicates	no limit.

       -h host_key_file
	      Specifies	a file from which a host key  is  read.	  This	option
	      must be given if sshd is not run as root (as the normal host key
	      files are	normally not readable by anyone	but  root).   The  de-
	      fault    is    /usr/local/etc/ssh/ssh_host_ecdsa_key,   /usr/lo-
	      cal/etc/ssh/ssh_host_ed25519_key		and	      /usr/lo-
	      cal/etc/ssh/ssh_host_rsa_key.   It  is possible to have multiple
	      host key files for the different host key	algorithms.

       -i     Specifies	that sshd is being run from inetd(8).

       -o option
	      Can be used to give options in the format	used in	the configura-
	      tion  file.   This  is  useful  for specifying options for which
	      there is no separate command-line	flag.  For full	details	of the
	      options, and their values, see sshd_config(5).

       -p port
	      Specifies	 the  port on which the	server listens for connections
	      (default 22).  Multiple port options are permitted.  Ports spec-
	      ified in the configuration file with the Port option are ignored
	      when a command-line port is specified.   Ports  specified	 using
	      the ListenAddress	option override	command-line ports.

       -q     Quiet  mode.   Nothing  is sent to the system log.  Normally the
	      beginning, authentication, and termination of each connection is

       -T     Extended	test  mode.   Check  the validity of the configuration
	      file, output the effective  configuration	 to  stdout  and  then
	      exit.   Optionally, Match	rules may be applied by	specifying the
	      connection parameters using one or more -C options.

       -t     Test mode.  Only check the validity of  the  configuration  file
	      and  sanity of the keys.	This is	useful for updating sshd reli-
	      ably as configuration options may	change.

       -u len This option is used to specify the size of the field in the utmp
	      structure	that holds the remote host name.  If the resolved host
	      name is longer than len, the dotted decimal value	will  be  used
	      instead.	This allows hosts with very long host names that over-
	      flow this	field to still be uniquely identified.	Specifying -u0
	      indicates	 that only dotted decimal addresses should be put into
	      the utmp file.  -u0 may also be used to prevent sshd from	making
	      DNS  requests  unless the	authentication mechanism or configura-
	      tion requires it.	 Authentication	mechanisms  that  may  require
	      DNS  include  HostbasedAuthentication and	using a	from="pattern-
	      list" option in a	key file.  Configuration options that  require
	      DNS   include   using  a	USER@HOST  pattern  in	AllowUsers  or

       The OpenSSH SSH daemon supports SSH protocol 2 only.  Each host	has  a
       host-specific  key,  used to identify the host.	Whenever a client con-
       nects, the daemon responds with its public host key.  The  client  com-
       pares  the  host	key against its	own database to	verify that it has not
       changed.	 Forward secrecy is  provided  through	a  Diffie-Hellman  key
       agreement.   This  key  agreement results in a shared session key.  The
       rest of the session is encrypted	using a	symmetric cipher.  The	client
       selects	the  encryption	 algorithm  to	use  from those	offered	by the
       server.	Additionally, session integrity	is provided through a  crypto-
       graphic message authentication code (MAC).

       Finally,	the server and the client enter	an authentication dialog.  The
       client tries to authenticate itself  using  host-based  authentication,
       public  key authentication, challenge-response authentication, or pass-
       word authentication.

       Regardless of the authentication	type, the account is checked to	ensure
       that  it	 is accessible.	 An account is not accessible if it is locked,
       listed in DenyUsers or its group	is listed in DenyGroups	.  The defini-
       tion of a locked	account	is system dependent. Some platforms have their
       own account database (eg	AIX) and some modify the passwd	field (	`*LK*'
       on Solaris and UnixWare,	`*' on HP-UX, containing `Nologin' on Tru64, a
       leading `*LOCKED*' on FreeBSD and a leading `!'	on most	Linuxes).   If
       there  is  a requirement	to disable password authentication for the ac-
       count while allowing still public-key, then the passwd field should  be
       set to something	other than these values	(eg `NP' or `*NP*' ).

       If the client successfully authenticates	itself,	a dialog for preparing
       the session is entered.	At this	time the  client  may  request	things
       like  allocating	 a  pseudo-tty,	forwarding X11 connections, forwarding
       TCP connections,	or forwarding the authentication agent connection over
       the secure channel.

       After  this,  the client	either requests	an interactive shell or	execu-
       tion or a non-interactive command, which	 sshd  will  execute  via  the
       user's  shell  using its	-c option.  The	sides then enter session mode.
       In this mode, either side may send data at any time, and	such  data  is
       forwarded to/from the shell or command on the server side, and the user
       terminal	in the client side.

       When the	user program terminates	and all	forwarded X11 and  other  con-
       nections	 have been closed, the server sends command exit status	to the
       client, and both	sides exit.

       When a user successfully	logs in, sshd does the following:

       1.     If the login is on a tty,	and no	command	 has  been  specified,
	      prints  last  login  time	and /etc/motd (unless prevented	in the
	      configuration file or by ~/.hushlogin; see the FILES section).

       2.     If the login is on a tty,	records	login time.

       3.     Checks /etc/nologin and  /var/run/nologin;  if  one  exists,  it
	      prints the contents and quits (unless root).

       4.     Changes to run with normal user privileges.

       5.     Sets up basic environment.

       6.     Reads  the  file ~/.ssh/environment, if it exists, and users are
	      allowed to change	their environment.  See	the PermitUserEnviron-
	      ment option in sshd_config(5).

       7.     Changes to user's	home directory.

       8.     If  ~/.ssh/rc  exists and	the sshd_config(5) PermitUserRC	option
	      is set, runs it; else if /usr/local/etc/ssh/sshrc	 exists,  runs
	      it; otherwise runs xauth(1).  The	``rc'' files are given the X11
	      authentication protocol and cookie in standard input.  See SSHRC
	      ,	below.

       9.     Runs  user's  shell  or command.	All commands are run under the
	      user's login shell as specified in the system password database.

       If the file ~/.ssh/rc exists, sh(1) runs	it after reading the  environ-
       ment  files  but	 before	starting the user's shell or command.  It must
       not produce any output on stdout; stderr	must be	used instead.  If  X11
       forwarding  is  in  use,	it will	receive	the "proto cookie" pair	in its
       standard	input (and DISPLAY in its environment).	 The script must  call
       xauth(1)	because	sshd will not run xauth	automatically to add X11 cook-

       The primary purpose of this file	is to run any initialization  routines
       which  may  be needed before the	user's home directory becomes accessi-
       ble; AFS	is a particular	example	of such	an environment.

       This file will probably contain some initialization  code  followed  by
       something similar to:

       if read proto cookie && [ -n "$DISPLAY" ]; then
	    if [ `echo $DISPLAY	| cut -c1-10` =	'localhost:' ];	then
		 # X11UseLocalhost=yes
		 echo add unix:`echo $DISPLAY |
		     cut -c11-`	$proto $cookie
		 # X11UseLocalhost=no
		 echo add $DISPLAY $proto $cookie
	    fi | xauth -q -

       If  this	 file  does not	exist, /usr/local/etc/ssh/sshrc	is run,	and if
       that does not exist either, xauth is used to add	the cookie.

       AuthorizedKeysFile specifies the	files containing public	keys for  pub-
       lic key authentication; if this option is not specified,	the default is
       ~/.ssh/authorized_keys and ~/.ssh/authorized_keys2.  Each line  of  the
       file  contains  one  key	(empty lines and lines starting	with a `#' are
       ignored as comments).  Public keys consist of the following space-sepa-
       rated  fields:  options,	keytype, base64-encoded	key, comment.  The op-
       tions field is optional.	 The supported key types are:







       The comment field is not	used for anything (but may be  convenient  for
       the user	to identify the	key).

       Note that lines in this file can	be several hundred bytes long (because
       of the size of the public key encoding) up to a limit of	 8  kilobytes,
       which  permits RSA keys up to 16	kilobits.  You don't want to type them
       in;  instead,  copy  the,,,,, or the file and edit it.

       sshd enforces a minimum RSA key modulus size of 1024 bits.

       The  options  (if present) consist of comma-separated option specifica-
       tions.  No spaces are permitted,	except within double quotes.  The fol-
       lowing  option  specifications are supported (note that option keywords
       are case-insensitive):

	      Enable authentication agent forwarding  previously  disabled  by
	      the restrict option.

	      Specifies	 that the listed key is	a certification	authority (CA)
	      that is trusted to validate signed certificates for user authen-

	      Certificates may encode access restrictions similar to these key
	      options.	If both	certificate restrictions and key  options  are
	      present, the most	restrictive union of the two is	applied.

	      Specifies	that the command is executed whenever this key is used
	      for authentication.  The command supplied	by the user  (if  any)
	      is  ignored.  The	command	is run on a pty	if the client requests
	      a	pty; otherwise it is run without a tty.	  If  an  8-bit	 clean
	      channel  is required, one	must not request a pty or should spec-
	      ify no-pty.  A quote may be included in the command  by  quoting
	      it with a	backslash.

	      This  option  might be useful to restrict	certain	public keys to
	      perform just a specific operation.  An example might  be	a  key
	      that  permits  remote  backups  but nothing else.	 Note that the
	      client may specify TCP and/or X11	forwarding unless they are ex-
	      plicitly prohibited, e.g.	using the restrict key option.

	      The  command  originally	supplied by the	client is available in
	      the SSH_ORIGINAL_COMMAND environment variable.  Note  that  this
	      option  applies  to shell, command or subsystem execution.  Also
	      note that	this command may be  superseded	 by  a	sshd_config(5)
	      ForceCommand directive.

	      If  a command is specified and a forced-command is embedded in a
	      certificate used for authentication, then	the  certificate  will
	      be accepted only if the two commands are identical.

	      Specifies	that the string	is to be added to the environment when
	      logging in using this key.  Environment variables	set  this  way
	      override	other default environment values.  Multiple options of
	      this type	are permitted.	Environment processing is disabled  by
	      default and is controlled	via the	PermitUserEnvironment option.

	      Specifies	 a time	after which the	key will not be	accepted.  The
	      time may be specified as a YYYYMMDD date or  a  YYYYMMDDHHMM[SS]
	      time in the system time-zone.

	      Specifies	 that in addition to public key	authentication,	either
	      the canonical name of the	remote host or its IP address must  be
	      present  in  the comma-separated list of patterns.  See PATTERNS
	      in ssh_config(5) for more	information on patterns.

	      In addition to the wildcard matching  that  may  be  applied  to
	      hostnames	or addresses, a	from stanza may	match IP addresses us-
	      ing CIDR address/masklen notation.

	      The purpose of this option is to optionally  increase  security:
	      public  key  authentication by itself does not trust the network
	      or name servers or anything (but the key); however, if  somebody
	      somehow  steals  the  key, the key permits an intruder to	log in
	      from anywhere in the world.  This	additional option makes	 using
	      a	 stolen	 key more difficult (name servers and/or routers would
	      have to be compromised in	addition to just the key).

	      Forbids authentication agent forwarding when this	 key  is  used
	      for authentication.

	      Forbids TCP forwarding when this key is used for authentication.
	      Any port forward requests	by the client will  return  an	error.
	      This might be used, e.g. in connection with the command option.

       no-pty Prevents tty allocation (a request to allocate a pty will	fail).

	      Disables execution of ~/.ssh/rc.

	      Forbids X11 forwarding when this key is used for authentication.
	      Any X11 forward requests by the client will return an error.

	      Limit remote port	forwarding with	the ssh(1) -R option such that
	      it  may  only  listen on the specified host (optional) and port.
	      IPv6 addresses can be specified  by  enclosing  the  address  in
	      square  brackets.	  Multiple permitlisten	options	may be applied
	      separated	by commas.  Hostnames may  include  wildcards  as  de-
	      scribed in the PATTERNS section in ssh_config(5).	 A port	speci-
	      fication of * matches any	port.  Note that the setting of	 Gate-
	      wayPorts	may  further  restrict	listen	addresses.   Note that
	      ssh(1) will send a hostname of ``localhost'' if  a  listen  host
	      was  not	specified  when	the forwarding was requested, and that
	      this name	is treated differently to the explicit	localhost  ad-
	      dresses ``'' and	``::1''.

	      Limit  local port	forwarding with	the ssh(1) -L option such that
	      it may only connect to the specified host	and  port.   IPv6  ad-
	      dresses  can  be	specified  by  enclosing the address in	square
	      brackets.	 Multiple permitopen options may be applied  separated
	      by  commas.   No pattern matching	or name	lookup is performed on
	      the specified hostnames, they must be literal host names	and/or
	      addresses.  A port specification of * matches any	port.

	      Enable  port  forwarding previously disabled by the restrict op-

	      On a cert-authority line,	specifies allowed principals for  cer-
	      tificate authentication as a comma-separated list.  At least one
	      name from	the list must appear  in  the  certificate's  list  of
	      principals  for  the certificate to be accepted.	This option is
	      ignored for keys that are	 not  marked  as  trusted  certificate
	      signers using the	cert-authority option.

       pty    Permits  tty  allocation previously disabled by the restrict op-

	      Do not require demonstration of  user  presence  for  signatures
	      made  using this key.  This option only makes sense for the FIDO
	      authenticator algorithms ecdsa-sk	and ed25519-sk.

	      Require that signatures made using this  key  attest  that  they
	      verified the user, e.g. via a PIN.  This option only makes sense
	      for the FIDO authenticator algorithms ecdsa-sk and ed25519-sk.

	      Enable all restrictions, i.e. disable port, agent	and  X11  for-
	      warding,	as  well  as disabling PTY allocation and execution of
	      ~/.ssh/rc.  If any future	restriction capabilities are added  to
	      authorized_keys files they will be included in this set.

	      Force  a	tun(4) device on the server.  Without this option, the
	      next available device will be used if the	client requests	a tun-

	      Enables  execution  of  ~/.ssh/rc	previously disabled by the re-
	      strict option.

	      Permits X11 forwarding previously	disabled by the	 restrict  op-

       An example authorized_keys file:

       # Comments are allowed at start of line.	Blank lines are	allowed.
       # Plain key, no restrictions
       ssh-rsa ...
       # Forced	command, disable PTY and all forwarding
       restrict,command="dump /home" ssh-rsa ...
       # Restriction of	ssh -L forwarding destinations
       permitopen="",permitopen="" ssh-rsa ...
       # Restriction of	ssh -R forwarding listeners
       permitlisten="localhost:8080",permitlisten="[::1]:22000"	ssh-rsa	...
       # Configuration for tunnel forwarding
       tunnel="0",command="sh /etc/netstart tun0" ssh-rsa ...
       # Override of restriction to allow PTY allocation
       restrict,pty,command="nethack" ssh-rsa ...
       # Allow FIDO key	without	requiring touch
       no-touch-required ...
       # Require user-verification (e.g. PIN or	biometric) for FIDO key
       verify-required ...
       # Trust CA key, allow touch-less	FIDO if	requested in certificate
       cert-authority,no-touch-required,principals="user_a" ssh-rsa ...

       The  /usr/local/etc/ssh/ssh_known_hosts	and  ~/.ssh/known_hosts	 files
       contain host public keys	for all	known hosts.  The global  file	should
       be  prepared  by	the administrator (optional), and the per-user file is
       maintained automatically: whenever the  user  connects  to  an  unknown
       host, its key is	added to the per-user file.

       Each  line  in  these  files contains the following fields: marker (op-
       tional),	hostnames, keytype, base64-encoded key,	comment.   The	fields
       are separated by	spaces.

       The  marker  is	optional,  but if it is	present	then it	must be	one of
       ``@cert-authority'', to indicate	that the line contains a certification
       authority (CA) key, or ``@revoked'', to indicate	that the key contained
       on the line is revoked and must not ever	be accepted.  Only one	marker
       should be used on a key line.

       Hostnames  is  a	 comma-separated list of patterns (`*' and `?'	act as
       wildcards); each	pattern	in turn	is  matched  against  the  host	 name.
       When  sshd  is authenticating a client, such as when using HostbasedAu-
       thentication, this will be the canonical	client host name.  When	ssh(1)
       is  authenticating  a  server,  this will be the	host name given	by the
       user, the value of the ssh(1) HostkeyAlias if it	was specified, or  the
       canonical server	hostname if the	ssh(1) CanonicalizeHostname option was

       A pattern may also be preceded by `!'  to  indicate  negation:  if  the
       host  name matches a negated pattern, it	is not accepted	(by that line)
       even if it matched another pattern on the line.	A hostname or  address
       may optionally be enclosed within `[' and `]' brackets then followed by
       `:' and a non-standard port number.

       Alternately, hostnames may be stored in a hashed	form which hides  host
       names  and  addresses  should the file's	contents be disclosed.	Hashed
       hostnames start with a `|' character.  Only one hashed hostname may ap-
       pear on a single	line and none of the above negation or wildcard	opera-
       tors may	be applied.

       The keytype and base64-encoded key are taken  directly  from  the  host
       key;    they    can   be	  obtained,   for   example,   from   /usr/lo-
       cal/etc/ssh/  The optional comment field continues
       to the end of the line, and is not used.

       Lines starting with `#' and empty lines are ignored as comments.

       When  performing	host authentication, authentication is accepted	if any
       matching	line has the proper key; either	one that matches  exactly  or,
       if  the	server has presented a certificate for authentication, the key
       of the certification authority that signed the certificate.  For	a  key
       to be trusted as	a certification	authority, it must use the ``@cert-au-
       thority'' marker	described above.

       The known hosts file also provides a facility to	mark keys as  revoked,
       for  example  when it is	known that the associated private key has been
       stolen.	Revoked	keys  are  specified  by  including  the  ``@revoked''
       marker at the beginning of the key line,	and are	never accepted for au-
       thentication or as certification	authorities, but instead will  produce
       a warning from ssh(1) when they are encountered.

       It  is  permissible (but	not recommended) to have several lines or dif-
       ferent host keys	for the	same names.  This will inevitably happen  when
       short  forms  of	host names from	different domains are put in the file.
       It is possible that the files contain conflicting information;  authen-
       tication	 is  accepted  if  valid  information can be found from	either

       Note that the lines in these files are typically	hundreds of characters
       long,  and  you definitely don't	want to	type in	the host keys by hand.
       Rather, generate	them by	a script, ssh-keyscan(1) or by taking, for ex-
       ample,  /usr/local/etc/ssh/	and  adding  the  host
       names at	the front.  ssh-keygen(1) also	offers	some  basic  automated
       editing for ~/.ssh/known_hosts including	removing hosts matching	a host
       name and	converting all host names to their hashed representations.

       An example ssh_known_hosts file:

       # Comments allowed at start of line
       closenet,..., 1024 37 159...93, ssh-rsa AAAA1234.....=
       # A hashed hostname
       |1|JfKTdBh7rNbXkVAQCRp4OQoPfmI=|USECr3SWf1JUPsms5AqfD5QfxkM= ssh-rsa
       # A revoked key
       @revoked	* ssh-rsa AAAAB5W...
       # A CA key, accepted for	any host in * or *
       @cert-authority *,* ssh-rsa AAAAB5W...

	      This file	is used	to suppress printing the last login  time  and
	      /etc/motd,  if PrintLastLog and PrintMotd, respectively, are en-
	      abled.  It does not suppress printing of the banner specified by

	      This  file is used for host-based	authentication (see ssh(1) for
	      more information).  On some machines this	file may  need	to  be
	      world-readable  if the user's home directory is on an NFS	parti-
	      tion, because sshd reads it as root.   Additionally,  this  file
	      must  be	owned by the user, and must not	have write permissions
	      for anyone else.	The recommended	permission for	most  machines
	      is read/write for	the user, and not accessible by	others.

	      This file	is used	in exactly the same way	as .rhosts, but	allows
	      host-based  authentication   without   permitting	  login	  with

	      This  directory  is  the	default	location for all user-specific
	      configuration and	authentication information.  There is no  gen-
	      eral  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.

	      Lists  the  public  keys	(DSA, ECDSA, Ed25519, RSA) that	can be
	      used for logging in as this user.	 The format of	this  file  is
	      described	 above.	  The content of the file is not highly	sensi-
	      tive, but	the recommended	permissions  are  read/write  for  the
	      user, and	not accessible by others.

	      If this file, the	~/.ssh directory, or the user's	home directory
	      are writable by other users, then	the file could be modified  or
	      replaced by unauthorized users.  In this case, sshd will not al-
	      low it to	be used	unless the StrictModes option has been set  to

	      This  file is read into the environment at login (if it exists).
	      It can only contain empty	lines, comment lines (that start  with
	      `#'  )  ,	and assignment lines of	the form name=value.  The file
	      should be	writable only by the user; it need not be readable  by
	      anyone  else.  Environment processing is disabled	by default and
	      is controlled via	the PermitUserEnvironment option.

	      Contains a list of host keys for all hosts the user  has	logged
	      into  that  are not already in the systemwide list of known host
	      keys.  The format	of this	file is	described  above.   This  file
	      should  be writable only by root/the owner and can, but need not
	      be, world-readable.

	      Contains initialization routines to be  run  before  the	user's
	      home directory becomes accessible.  This file should be writable
	      only by the user,	and need not be	readable by anyone else.


	      Access controls that should be enforced by tcp-wrappers are  de-
	      fined here.  Further details are described in hosts_access(5).

	      This  file  is  for host-based authentication (see ssh(1)) .  It
	      should only be writable by root.

	      Contains Diffie-Hellman  groups  used  for  the  "Diffie-Hellman
	      Group  Exchange"	key  exchange  method.	The file format	is de-
	      scribed in moduli(5).  If	no usable groups  are  found  in  this
	      file then	fixed internal groups will be used.

	      See motd(5).

	      If  this file exists, sshd refuses to let	anyone except root log
	      in.  The contents	of the file are	displayed to anyone trying  to
	      log  in,	and non-root connections are refused.  The file	should
	      be world-readable.

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



	      These files contain the private parts of the host	 keys.	 These
	      files  should  only be owned by root, readable only by root, and
	      not accessible to	others.	 Note that  sshd  does	not  start  if
	      these files are group/world-accessible.



	      These  files  contain  the public	parts of the host keys.	 These
	      files should be world-readable but writable only by root.	 Their
	      contents should match the	respective private parts.  These files
	      are not really used for anything;	they are provided for the con-
	      venience	of  the	 user so their contents	can be copied to known
	      hosts files.  These files	are created using ssh-keygen(1).

	      Systemwide list of known host keys.  This	file  should  be  pre-
	      pared  by	 the  system  administrator to contain the public host
	      keys of all machines in the organization.	 The  format  of  this
	      file  is	described above.  This file should be writable only by
	      root/the owner and should	be world-readable.

	      Contains configuration data for sshd.  The file format and  con-
	      figuration options are described in sshd_config(5).

	      Similar to ~/.ssh/rc, it can be used to specify machine-specific
	      login-time  initializations  globally.   This  file  should   be
	      writable only by root, and should	be world-readable.

	      chroot(2)	 directory used	by sshd	during privilege separation in
	      the pre-authentication phase.  The directory should not  contain
	      any  files  and  must  be	 owned by root and not group or	world-

	      Contains the process ID of the sshd  listening  for  connections
	      (if there	are several daemons running concurrently for different
	      ports, this contains the process ID of the  one  started	last).
	      The content of this file is not sensitive; it can	be world-read-

       scp(1), sftp(1),	ssh(1),	ssh-add(1), ssh-agent(1), ssh-keygen(1),  ssh-
       keyscan(1),   chroot(2),	  hosts_access(5),  login.conf(5),  moduli(5),
       sshd_config(5), inetd(8), sftp-server(8)

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

			      September	10 2021			       SSHD(8)


Want to link to this manual page? Use this URL:

home | help