sshd man page on Minix

Man page or keyword search:  
man Server   6208 pages
apropos Keyword Search (all sections)
Output format
Minix logo
[printable version]

SSHD(8)								       SSHD(8)

NAME
       sshd - OpenSSH SSH daemon

SYNOPSIS
       sshd  [-46DdeiqTt]  [-b	bits]  [-C  connection_spec] [-c host_certifi‐
       cate_file] [-f config_file] [-g	login_grace_time]  [-h	host_key_file]
       [-k key_gen_time] [-o option] [-p port] [-u len]

DESCRIPTION
       sshd (OpenSSH Daemon) is the daemon program for ssh(1).	Together these
       programs replace rlogin(1) and rsh(1),  and  provide  secure  encrypted
       communications between two untrusted hosts over an insecure network.

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

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

       The options are as follows:

       -4     Forces sshd to use IPv4 addresses only.

       -6     Forces sshd to use IPv6 addresses only.

       -b bits
	      Specifies the number of bits in the ephemeral protocol version 1
	      server key (default 1024).

       -C connection_spec
	      Specify  the  connection	parameters  to use for the -T extended
	      test mode.  If provided, any Match directives in the  configura‐
	      tion  file  that	would  apply  to the specified user, host, and
	      address will be set before the configuration is written to stan‐
	      dard  output.   The  connection  parameters are supplied as key‐
	      word=value pairs.	 The  keywords	are  ``user'',	``host'',  and
	      ``addr''.	  All  are  required and may be supplied in any order,
	      either with multiple -C options or as a comma-separated list.

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

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

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

       -e     When this option is specified, sshd will send the output to  the
	      standard error instead of the system log.

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

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

       -h host_key_file
	      Specifies a file from which a host key  is  read.	  This	option
	      must be given if sshd is not run as root (as the normal host key
	      files are normally  not  readable	 by  anyone  but  root).   The
	      default is /usr/pkg/etc/ssh/ssh_host_key for protocol version 1,
	      and			    /usr/pkg/etc/ssh/ssh_host_dsa_key,
	      /usr/pkg/etc/ssh/ssh_host_ecdsa_key			   and
	      /usr/pkg/etc/ssh/ssh_host_rsa_key for protocol version 2.	 It is
	      possible	to have multiple host key files for the different pro‐
	      tocol versions and host key algorithms.

       -i     Specifies that sshd is being run from inetd(8).	sshd  is  nor‐
	      mally not run from inetd because it needs to generate the server
	      key before it can respond to the client, and this may take  tens
	      of  seconds.  Clients would have to wait too long if the key was
	      regenerated every time.  However, with  small  key  sizes	 (e.g.
	      512) using sshd from inetd may be feasible.

       -k key_gen_time
	      Specifies	 how often the ephemeral protocol version 1 server key
	      is regenerated (default 3600 seconds, or one hour).  The motiva‐
	      tion  for	 regenerating  the key fairly often is that the key is
	      not stored anywhere, and after about an hour it becomes impossi‐
	      ble to recover the key for decrypting intercepted communications
	      even if the machine is cracked into  or  physically  seized.   A
	      value of zero indicates that the key will never be regenerated.

       -o option
	      Can be used to give options in the format used in the 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
	      logged.

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

       -t     Test  mode.   Only  check the validity of the configuration file
	      and sanity of the keys.  This is useful for updating sshd	 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  RhostsRSAAuthentication,  HostbasedAuthentication,
	      and  using a from="pattern-list" option in a key file.  Configu‐
	      ration options that require DNS include using a  USER@HOST  pat‐
	      tern in AllowUsers or DenyUsers.

AUTHENTICATION
       The  OpenSSH SSH daemon supports SSH protocols 1 and 2.	The default is
       to use protocol 2 only, though this can be  changed  via	 the  Protocol
       option in sshd_config(5).  Protocol 2 supports DSA, ECDSA and RSA keys;
       protocol 1 only supports RSA keys.  For both protocols, each host has a
       host-specific key, normally 2048 bits, used to identify the host.

       Forward	security  for  protocol	 1  is	provided through an additional
       server key, normally 768 bits, generated when the server starts.	  This
       key  is	normally  regenerated  every  hour if it has been used, and is
       never stored on disk.  Whenever a client connects, the daemon  responds
       with its public host and server keys.  The client compares the RSA host
       key against its own database to verify that it has  not	changed.   The
       client then generates a 256-bit random number.  It encrypts this random
       number using both the host key  and  the	 server	 key,  and  sends  the
       encrypted number to the server.	Both sides then use this random number
       as a session key which is used to encrypt all further communications in
       the session.  The rest of the session is encrypted using a conventional
       cipher, currently Blowfish or 3DES, with 3DES being  used  by  default.
       The  client  selects the encryption algorithm to use from those offered
       by the server.

       For protocol 2, forward security is provided through  a	Diffie-Hellman
       key  agreement.	 This  key  agreement results in a shared session key.
       The rest of the session is encrypted using  a  symmetric	 cipher,  cur‐
       rently  128-bit	AES, Blowfish, 3DES, CAST128, Arcfour, 192-bit AES, or
       256-bit AES.  The client selects the encryption algorithm to  use  from
       those  offered  by the server.  Additionally, session integrity is pro‐
       vided through a cryptographic message  authentication  code  (hmac-md5,
       hmac-sha1, umac-64 or hmac-ripemd160).

       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 dependant. 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
       account 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 a shell or execution of a com‐
       mand.  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;  if	 it  exists, prints contents and quits
	      (unless root).

       4.     Changes to run with normal user privileges.

       5.     Sets up basic environment.

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

       7.     Changes to user's home directory.

       8.     If ~/.ssh/rc exists, runs	 it;  else  if	/usr/pkg/etc/ssh/sshrc
	      exists,  runs  it;  otherwise  runs xauth.  The ``rc'' files are
	      given the X11 authentication protocol  and  cookie  in  standard
	      input.  See SSHRC , below.

       9.     Runs user's shell or command.

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, /usr/pkg/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 file containing public keys for public
       key authentication; if none is specified, the default is	 ~/.ssh/autho‐
       rized_keys.   Each  line	 of the file contains one key (empty lines and
       lines starting with a `#' are ignored as comments).  Protocol 1	public
       keys  consist  of  the following space-separated fields: options, bits,
       exponent, modulus, comment.  Protocol 2 public key consist of: options,
       keytype,	 base64-encoded	 key, comment.	The options field is optional;
       its presence is determined by whether the line starts with a number  or
       not  (the  options  field never starts with a number).  The bits, expo‐
       nent, modulus, and comment fields give the RSA key for protocol version
       1;  the	comment	 field is not used for anything (but may be convenient
       for the user to identify the key).  For protocol version 2 the  keytype
       is     ``ecdsa-sha2-nistp256'',	  ``ecdsa-sha2-nistp384'',    ``ecdsa-
       sha2-nistp521'', ``ssh-dss'' or ``ssh-rsa''.

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

       sshd enforces a minimum RSA key modulus size for protocol 1 and	proto‐
       col 2 keys of 768 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):

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

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

       command="command"
	      Specifies that the command is executed whenever this key is used
	      for  authentication.   The command supplied by the user (if any)
	      is ignored.  The command is run on a pty if the client  requests
	      a	 pty;  otherwise  it  is run without a tty.  If an 8-bit clean
	      channel is required, one must not request a pty or should	 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 forward‐
	      ing unless they are explicitly prohibited.  The  command	origi‐
	      nally  supplied  by  the	client	is available in the SSH_ORIGI‐
	      NAL_COMMAND environment variable.	 Note that this option applies
	      to  shell,  command or subsystem execution.  Also note that this
	      command may be superseded by either a  sshd_config(5)  ForceCom‐
	      mand directive or a command embedded in a certificate.

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

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

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

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

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

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

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

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

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

       permitopen="host:port"
	      Limit  local  ``ssh  -L''	 port forwarding such that it may only
	      connect to the specified host and port.  IPv6 addresses  can  be
	      specified by enclosing the address in square brackets.  Multiple
	      permitopen options may be applied separated by commas.  No  pat‐
	      tern matching is performed on the specified hostnames, they must
	      be literal domains or addresses.

       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.

       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 tun‐
	      nel.

	      An example authorized_keys file:

	      # Comments allowed at start of line
	      ssh-rsa AAAAB3Nza...LiPk== user@example.net
	      from="*.sales.example.net,!pc.sales.example.net" ssh-rsa
	      AAAAB2...19Q== john@example.net
	      command="dump /home",no-pty,no-port-forwarding ssh-dss
	      AAAAC3...51R== example.net
	      permitopen="192.0.2.1:80",permitopen="192.0.2.2:25" ssh-dss
	      AAAAB5...21S==
	      tunnel="0",command="sh /etc/netstart tun0" ssh-rsa AAAA...==
	      jane@example.net

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

       Each  line  in  these  files  contains  the  following  fields: markers
       (optional), hostnames, bits, exponent, modulus,	comment.   The	fields
       are separated by spaces.

       The  marker  is	optional,  but if it is present then it must be one of
       ``@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 canonical  host
       name  (when  authenticating a client) or against the user-supplied name
       (when authenticating a server).	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
       appear  on  a  single  line  and none of the above negation or wildcard
       operators may be applied.

       Bits, exponent, and modulus are taken directly from the RSA  host  key;
       they	  can	    be	    obtained,	   for	    example,	  from
       /usr/pkg/etc/ssh/ssh_host_key.pub.  The optional comment field  contin‐
       ues 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
       authentication or as certification authorities, but instead  will  pro‐
       duce 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
       /usr/pkg/etc/ssh/ssh_host_key.pub  and  adding  the  host  names at the
       front.  ssh-keygen(1) also offers  some	basic  automated  editing  for
       ~/.ssh/known_hosts  including  removing	hosts matching a host name and
       converting all host names to their hashed representations.

       An example ssh_known_hosts file:

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

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

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

       ~/.ssh/
	      This  directory  is  the	default location for all user-specific
	      configuration and authentication information.  There is no  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/RSA) that can be used for log‐
	      ging in as this user.  The format	 of  this  file	 is  described
	      above.  The content of the file is not highly sensitive, but the
	      recommended permissions are read/write for  the  user,  and  not
	      accessible by others.

	      If this file, the ~/.ssh directory, or the user's home directory
	      are writable by other users, then the file could be modified  or
	      replaced	by  unauthorized  users.   In this case, sshd will not
	      allow it to be used unless the StrictModes option has  been  set
	      to ``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
	      defined here.  Further details are described in hosts_access(5).

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

       /usr/pkg/usr/pkg/etc/ssh/moduli
	      Contains Diffie-Hellman  groups  used  for  the  "Diffie-Hellman
	      Group Exchange".	The file format is described in moduli(5).

       /etc/motd
	      See motd(5).

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

       /usr/pkg/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.

       /usr/pkg/etc/ssh/ssh_host_key

       /usr/pkg/etc/ssh/ssh_host_dsa_key

       /usr/pkg/etc/ssh/ssh_host_ecdsa_key

       /usr/pkg/etc/ssh/ssh_host_rsa_key
	      These three 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.

       /usr/pkg/etc/ssh/ssh_host_key.pub

       /usr/pkg/etc/ssh/ssh_host_dsa_key.pub

       /usr/pkg/etc/ssh/ssh_host_ecdsa_key.pub

       /usr/pkg/etc/ssh/ssh_host_rsa_key.pub
	      These  three  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).

       /usr/pkg/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.

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

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

       /usr/var/chroot/sshd
	      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.

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

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 contrib‐
       uted support for privilege separation.

CAVEATS
       System  security	 is  not improved unless rshd, rlogind, and rexecd are
       disabled	 (thus	completely  disabling  rlogin()	 and  rsh()  into  the
       machine).

			       October 28 2010			       SSHD(8)
[top]

List of man pages available for Minix

Copyright (c) for man pages and the logo by the respective OS vendor.

For those who want to learn more, the polarhome community provides shell access and support.

[legal] [privacy] [GNU] [policy] [cookies] [netiquette] [sponsors] [FAQ]
Tweet
Polarhome, production since 1999.
Member of Polarhome portal.
Based on Fawad Halim's script.
....................................................................
Vote for polarhome
Free Shell Accounts :: the biggest list on the net