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

FreeBSD Manual Pages

  
 
  

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

NAME
       sshd -- OpenSSH daemon

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

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

       sshd listens for	connections from clients.  It is normally  started  at
       boot from /etc/rc.d/sshd.  It forks a new daemon	for each incoming con-
       nection.	 The forked daemons handle key exchange, encryption, authenti-
       cation, 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 number and
	       routing domain respectively.

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

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

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

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

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

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

       -G      Parse  and print	configuration file.  Check the validity	of the
	       configuration file, output the effective	configuration to  std-
	       out  and	 then exit.  Optionally, Match rules may be applied by
	       specifying the connection parameters using one or more  -C  op-
	       tions.

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

       -h host_key_file
	       Specifies  a  file  from	which a	host key is read.  This	option
	       must be given if	sshd is	not run	as root	(as  the  normal  host
	       key  files  are normally	not readable by	anyone but root).  The
	       default		   is		  /etc/ssh/ssh_host_ecdsa_key,
	       /etc/ssh/ssh_host_ed25519_key   and  /etc/ssh/ssh_host_rsa_key.
	       It is possible to have multiple host key	files for the  differ-
	       ent 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 configu-
	       ration file.  This is useful for	specifying options  for	 which
	       there  is  no  separate command-line flag.  For full details of
	       the options, and	their values, see sshd_config(5).

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

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

       -T      Extended	 test  mode.   Check the validity of the configuration
	       file, output the	effective configuration	 to  stdout  and  then
	       exit.  Optionally, Match	rules may be applied by	specifying the
	       connection  parameters  using  one or more -C options.  This is
	       similar to the -G flag, but it includes the additional  testing
	       performed by the	-t flag.

       -t      Test  mode.   Only check	the validity of	the configuration file
	       and sanity of the keys.	This is	useful for updating sshd 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 re-
	       solved host name	is longer than len, the	dotted	decimal	 value
	       will  be	 used  instead.	 This allows hosts with	very long host
	       names that overflow this	field to still be uniquely identified.
	       Specifying -u0 indicates	that  only  dotted  decimal  addresses
	       should be put into the utmp file.  -u0 may also be used to pre-
	       vent  sshd  from	 making	DNS requests unless the	authentication
	       mechanism or configuration requires it.	Authentication	mecha-
	       nisms  that may require DNS include HostbasedAuthentication and
	       using a from="pattern-list" option in a key  file.   Configura-
	       tion options that require DNS include using a USER@HOST pattern
	       in AllowUsers or	DenyUsers.

       -V      Display the version number and exit.

AUTHENTICATION
       The  OpenSSH  SSH daemon	supports SSH protocol 2	only.  Each host has a
       host-specific key, used to identify the host.  Whenever a  client  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  of	 a  non-interactive  command,  which sshd will execute via the
       user's shell using its -c option.  The sides then enter	session	 mode.
       In  this	 mode, either side may send data at any	time, and such data is
       forwarded to/from the shell or command on the server side, and the user
       terminal	in the client side.

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

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

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

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

	     3.	  Checks /etc/nologin 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
		  PermitUserEnvironment	option in sshd_config(5).

	     7.	  Changes to user's home directory.

	     8.	  If  ~/.ssh/rc	exists and the sshd_config(5) PermitUserRC op-
		  tion is set, runs it;	else if	 /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.

SSHRC
       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-
       ies.

       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
		  else
			  # X11UseLocalhost=no
			  echo add $DISPLAY $proto $cookie
		  fi | xauth -q	-
	  fi

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

AUTHORIZED_KEYS	FILE FORMAT
       AuthorizedKeysFile specifies the	files containing public	keys for  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:

	     sk-ecdsa-sha2-nistp256@openssh.com
	     ecdsa-sha2-nistp256
	     ecdsa-sha2-nistp384
	     ecdsa-sha2-nistp521
	     sk-ssh-ed25519@openssh.com
	     ssh-ed25519
	     ssh-dss
	     ssh-rsa

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

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

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

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

       agent-forwarding
	       Enable authentication agent forwarding previously  disabled  by
	       the restrict option.

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

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

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

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

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

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

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

       expiry-time="timespec"
	       Specifies a time	after which the	key will not be	accepted.  The
	       time  may  be  specified	 as  a	YYYYMMDD[Z] date or a YYYYMMD-
	       DHHMM[SS][Z] time.  Dates and times will	be interpreted in  the
	       system  time  zone  unless  suffixed by a Z character, in which
	       case they will be interpreted in	the UTC	time zone.

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

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

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

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

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

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

       no-user-rc
	       Disables	execution of ~/.ssh/rc.

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

       permitlisten="[host:]port"
	       Limit  remote  port  forwarding	with the ssh(1)	-R option such
	       that it may only	listen on the specified	 host  (optional)  and
	       port.  IPv6 addresses can be specified by enclosing the address
	       in  square  brackets.  Multiple permitlisten options may	be ap-
	       plied separated by commas.  Hostnames may include wildcards  as
	       described  in  the  PATTERNS  section in	ssh_config(5).	A port
	       specification of	* matches any port.  Note that the setting  of
	       GatewayPorts  may further restrict listen addresses.  Note that
	       ssh(1) will send	a hostname of "localhost" if a listen host was
	       not specified when the forwarding was requested,	and that  this
	       name is treated differently to the explicit localhost addresses
	       "127.0.0.1" and "::1".

       permitopen="host:port"
	       Limit local port	forwarding with	the ssh(1) -L option such that
	       it  may	only connect to	the specified host and port.  IPv6 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.

       port-forwarding
	       Enable port forwarding previously disabled by the restrict  op-
	       tion.

       principals="principals"
	       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-
	       tion.

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

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

       restrict
	       Enable  all restrictions, i.e. disable port, agent and X11 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.

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

       user-rc
	       Enables	execution  of  ~/.ssh/rc  previously  disabled	by the
	       restrict	option.

       X11-forwarding
	       Permits X11 forwarding previously disabled by the restrict  op-
	       tion.

       An example authorized_keys file:

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

SSH_KNOWN_HOSTS	FILE FORMAT
       The  /etc/ssh/ssh_known_hosts and ~/.ssh/known_hosts files contain host
       public keys for all known hosts.	 The global file should	be prepared by
       the administrator (optional), and the per-user file is maintained auto-
       matically: 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
       HostbasedAuthentication,	this will be the canonical client  host	 name.
       When  ssh(1)  is	 authenticating	 a  server, this will be the host name
       given by	the user, the value of the ssh(1) HostkeyAlias if it was spec-
       ified,	or   the   canonical   server	hostname   if	 the	ssh(1)
       CanonicalizeHostname option was used.

       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
       /etc/ssh/ssh_host_rsa_key.pub.  The optional comment field continues to
       the end of the line, and	is not used.

       Lines starting with `#' 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-authority" 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 authenti-
       cation 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
       file.

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

       An example ssh_known_hosts file:

	  # Comments allowed at	start of line
	  cvs.example.net,192.0.2.10 ssh-rsa AAAA1234.....=
	  # A hashed hostname
	  |1|JfKTdBh7rNbXkVAQCRp4OQoPfmI=|USECr3SWf1JUPsms5AqfD5QfxkM= ssh-rsa
	  AAAA1234.....=
	  # A revoked key
	  @revoked * ssh-rsa AAAAB5W...
	  # A CA key, accepted for any host in *.mydomain.com or *.mydomain.org
	  @cert-authority *.mydomain.org,*.mydomain.com	ssh-rsa	AAAAB5W...

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

       ~/.rhosts
	       This file is used for host-based	authentication (see ssh(1) for
	       more information).  On some machines this file may need	to  be
	       world-readable if the user's home directory is on an NFS	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.

       ~/.shosts
	       This file is used in exactly the	same way as .rhosts,  but  al-
	       lows  host-based	 authentication	 without permitting login with
	       rlogin/rsh.

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

       ~/.ssh/authorized_keys
	       Lists  the  public  keys	(DSA, ECDSA, Ed25519, RSA) that	can be
	       used for	logging	in as this user.  The format of	this  file  is
	       described  above.  The content of the file is not highly	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	direc-
	       tory are	writable by other users, then the file could be	 modi-
	       fied  or	 replaced  by  unauthorized users.  In this case, sshd
	       will not	allow it to be used unless the StrictModes option  has
	       been set	to "no".

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

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

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

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

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

       /etc/moduli
	       Contains	 Diffie-Hellman	 groups	 used  for the "Diffie-Hellman
	       Group Exchange" 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.

       /etc/motd
	       See motd(5).

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

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

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

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

       /etc/ssh/ssh_known_hosts
	       Systemwide list of known	host keys.  This file should  be  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.

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

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

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

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

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

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

FreeBSD	13.2		      September	19, 2023		       SSHD(8)

NAME | SYNOPSIS | DESCRIPTION | AUTHENTICATION | LOGIN PROCESS | SSHRC | AUTHORIZED_KEYS FILE FORMAT | SSH_KNOWN_HOSTS FILE FORMAT | FILES | SEE ALSO | AUTHORS

Want to link to this manual page? Use this URL:
<https://man.freebsd.org/cgi/man.cgi?query=sshd&sektion=8&manpath=FreeBSD+14.0-RELEASE+and+Ports>

home | help