sshd man page on QNX

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

SSHD(8)								       SSHD(8)

       sshd - OpenSSH SSH daemon

       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]

       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

       -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_rsa_key		   and
	      /usr/pkg/etc/ssh/ssh_host_dsa_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

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

       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 both RSA and  DSA	 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

       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; 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.

       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/pkg/etc/ssh/sshrc is run, and if that
       does not exist either, xauth is used to add the cookie.

       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 ``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‐,, or the 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):

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

	      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.

	      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).

	      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  local  ``ssh  -L''	 port forwarding such that it may only
	      connect to the specified host and port.  IPv6 addresses  can  be
	      specified	 with an alternative syntax: host/port.	 Multiple per‐
	      mitopen options may be applied separated by commas.  No  pattern
	      matching	is  performed on the specified hostnames, they must be
	      literal domains or addresses.

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

	      An example authorized_keys file:

	      # Comments allowed at start of line
	      ssh-rsa AAAAB3Nza...LiPk==
	      from="*,!" ssh-rsa
	      command="dump /home",no-pty,no-port-forwarding ssh-dss
	      permitopen="",permitopen="" ssh-dss
	      tunnel="0",command="sh /etc/netstart tun0" ssh-rsa AAAA...==

       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/   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

       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/ 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
	      enabled.	 It does not suppress printing of the banner specified
	      by Banner.

	      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 (RSA/DSA) that can be used for logging  in
	      as  this user.  The format of this file is described above.  The
	      content of the file is not highly sensitive, but the recommended
	      permissions  are	read/write for the user, and not accessible by

	      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''.

	      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
	      defined 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".	The file format is described in moduli(5).

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



	      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).

	      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.

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

				 March 5 2010			       SSHD(8)
                             _         _         _ 
                            | |       | |       | |     
                            | |       | |       | |     
                         __ | | __ __ | | __ __ | | __  
                         \ \| |/ / \ \| |/ / \ \| |/ /  
                          \ \ / /   \ \ / /   \ \ / /   
                           \   /     \   /     \   /    
                            \_/       \_/       \_/ 
More information is available in HTML format for server QNX

List of man pages available for QNX

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]
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