Your browser does not allow storing cookies. We recommend enabling them.

SSH Tectia 
PreviousNextUp[Contents] [Index]

    About This Document >>
    Installing SSH Tectia Server for IBM z/OS >>
    Getting Started with SSH Tectia Server for IBM z/OS >>
    Configuring the Server >>
    Configuring the Client >>
    Authentication >>
    File Transfer Using SFTP >>
    File Transfer Using Transparent FTP Tunneling >>
    Tunneling on the Command Line >>
    Troubleshooting SSH Tectia Server for IBM z/OS >>
    Advanced Information >>
    Man Pages >>
        ssh-socks-proxy >>
        ssh-socks-proxy-config >>
        ssh-socks-proxy-ctl >>
        ssh-certview >>
        ssh-cmpclient >>
        ssh-keydist2 >>
        ssh-scepclient >>
    Log Messages >>


SSH2_CONFIG(5)                 SSH2                SSH2_CONFIG(5)

       ssh2_config - configuration file format for ssh2 on z/OS

       ssh2  obtains  all  configuration  data from the following
       sources (in this order): the system's global configuration
       file (typically /etc/ssh2/ssh2_config), the user's config-
       uration file ($HOME/.ssh2/ssh2_config), and  the  command-
       line options.  For each parameter, the last obtained value
       will be effective.

       A configuration file can  begin  with  "metaconfiguration"
       information, that is, information configuring the configu-
       ration language itself.

       If the configuration file starts with a line matching  the
       following egrep-style regex

         #.*VERSION[ \t\f]+[0-9]+.[0-9]+

       it  is  interpreted  as  the  version of the configuration
       style.  If this kind of line is not found, the version  is
       considered to be "1.0".

       The version string can be followed by one or more metacon-
       figuration parameters.  The lines have to start with  '#',
       and they have to match the following egrep style regex:

         #[# \t]+[A-Z0-9]+[ \t]+.*

       The parsing of metaconfiguration directives stops with the
       first non-recognized line.

       Version 1.1 and later recognize the following parameter:

              This denotes the regex syntax  used  to  parse  the
              configuration  file  in question.  The regex syntax
              is used in parsing the labels, lists,  and  so  on,
              and when matching something with the regex patterns
              specified in the configuration file.

              The value can be egrep, ssh, zsh_fileglob or tradi-
              tional  (the  arguments  are  not  case-sensitive).
              zsh_fileglob and traditional are synonymous.

       The configuration file has the following format:

              'expression' denotes the start of a  per-host  con-
              figuration  block,  where  'expression' is an arbi-
              trary string which distinguishes  this  block  from
              others.  'expression'  can  contain wildcards.  The
              'expression' will be  compared  with  the  hostname
              obtained  from the command line, and if it matches,
              the block will be evaluated.  Evaluation  stops  at
              the next 'expression:' statement.  If more than one
              match is found, all will be evaluated and the  last
              obtained  values  for parameters will be effective.
              Note that 'expression' does not have to be  a  real
              hostname,  as  long  as the 'expression' block con-
              tains a Host configuration parameter where the real
              hostname to connect to is defined.

              Empty lines and lines starting with '#' are ignored
              as comments.

              Otherwise a line is of the  format  'keyword  argu-
              ments'.   Note that it is possible to enclose argu-
              ments in quotes, and use the standard C convention.
              The  possible  keywords  and  their meanings are as
              follows (note  that  the  configuration  files  are
              case-sensitive but the keywords are not case-sensi-

              This keyword specifies the  authentication  methods
              that  are  allowed.  This is a comma-separated list
              currently consisting of the following  words:  key-
              board-interactive,  password,  publickey, and host-
              based.  Each specifies  an  authentication  method.
              The    default    is   "publickey,keyboard-interac-
              tive,password".   The  authentication  methods  are
              tried  in  the order in which they are specified in
              this configuration parameter.  This means that  the
              least interactive methods should be placed first in
              this list,  for  example  "hostbased,publickey,key-
              board-interactive"  (because public-key authentica-
              tion can be automated by the user with  ssh-agent).

              Specifies whether to print "Authentication success-
              ful." after authentication has  completed  success-
              fully.  This is mainly to prevent malicious servers
              from getting information from the user by  display-
              ing additional password or passphrase prompts.  The
              argument must be yes or no.  The default is yes.

              If set to yes, ssh2  disables  password/passhphrase
              querying.   This  is  useful  in  scripts and other
              batch jobs where there is no  user  to  supply  the
              password.   If  the StrictHostKeyChecking parameter
              is set to ask, ssh2 assumes a no answer to  queries
              (this  is because ssh does not even try to get user
              input when invoked with BatchMode yes).  The  argu-
              ment must be yes or no.  The default is no.

              Specifies  the  ciphers  to  use for encrypting the
              session.  The  supported  ciphers  are  aes128-cbc,
              aes192-cbc,   aes256-cbc,  3des-cbc,  blowfish-cbc,
              cast128-cbc,      twofish-cbc,      twofish128-cbc,
              twofish192-cbc,  twofish256-cbc, arcfour, rijndael-
    ,,          and

              Multiple  ciphers can be specified as a comma-sepa-
              rated list.  Special values  for  this  option  are
              Any,  AnyStd,  none,  AnyCipher,  and AnyStdCipher.
              Any  allows  all  ciphers  including  none;  AnyStd
              allows only those mentioned in the IETF-SecSh draft
              plus none; none forbids any use of encryption; Any-
              Cipher  and AnyStdCipher are analogous to the first
              two cases but exclude  none.  AnyStdCipher  is  the

              Specifies whether to force conversion of the stdout
              data stream.  The argument can be yes, no, or  cond
              (conditional).  If set to yes, the stdout data will
              be converted to EBCDIC.  If set to no,  the  stdout
              data  will  be in ASCII.  The default is cond, that
              is, the stdout data is converted if the client pro-
              gram  is  used  interactively,  otherwise it is not

              Specifies whether to clear  all  remote  and  local
              forwarded  ports defined so far.  The argument must
              be yes or no.  Note that scp  always  automatically
              clears all forwarded ports.

              Specifies whether to use compression.  The argument
              must be yes or no.

              Writes debug messages to a specified file.  (Remem-
              ber to enable debugging.)

              This  option  is  only  useful if set in the global
              configuration file.  This is used by ssh2 and  ssh-
              signer2  to  find  out the system name, if only the
              base part of the system name is available by normal
              means  (those  used  by, for example, hostname(1)).
              This is appended to the found system name,  if  the
              returned  system name does not contain a dot ('.').

              Selects whether to disable  fallback  compatibility
              code  for  earlier,  or otherwise incompatible ver-
              sions of software. Do not disable this  unless  you
              know  what you are doing.  The argument must be yes
              or no.  The default is no.

              Redirects input from /dev/null,  that  is,  do  not
              read  stdin.   The argument must be yes or no.  The
              default is no.

              Specifies the initialization string for the  exter-
              nal  key  provider  for accessing external keys for
              user authentication. This is ignored when the  key-
              word  EkProvider  is not present. The client poten-
              tially tries all keys that match the initialization
              string,  are  RSA  keys, and contain both a private
              key and a certificate. See ssh-externalkeys(5)  for
              further information.

              Specifies  the  external key provider for accessing
              external keys for user  authentication.  Currently,
              the  only  valid value on z/OS is zos-saf. See ssh-
              externalkeys(5) for further information.

              Sets the escape character (default: ~).  The escape
              character can also be set on the command line.  The
              argument should be a single character, '^' followed
              by  a letter, or none to disable the escape charac-
              ter entirely (making the connection transparent for
              binary data).

              Allocates  a  tty  even if a command is given.  The
              argument must be yes or no.  The default is no.

              Specifies whether the connection to the authentica-
              tion agent (if any) will be forwarded to the remote
              machine.  The argument must  be  yes  or  no.   The
              default is yes.

              Specifies that also remote  hosts  may  connect  to
              locally  forwarded ports.  The argument must be yes
              or no.  The default is no.

              Requests ssh2 to go to the background after authen-
              tication  is  done  and  the  forwardings have been
              established.  This is useful if ssh2  is  going  to
              ask for passwords or passphrases but the user wants
              it in the background.  The argument must be yes, no
              or  oneshot.   With  oneshot, ssh2 behaves the same
              way  as  with  -fo  command-line  arguments.    The
              default is no.

       Host   The  real hostname to log in to.  With 'expression'
              above, this can be used  to  specify  nicknames  or
              abbreviations  for  hosts.  The default is the name
              given on the command line.   Numeric  IP  addresses
              are also permitted (both on the command line and in
              HostName specifications).

       HostCA The  argument  is  of   the   format:   ca-certifi-

              This  keyword  specifies  the  CA  certificate  (in
              binary or PEM (base-64) format)  to  be  used  when
              authenticating  remote  server hosts.  The certifi-
              cate received from the host must be issued  by  the
              specified  CA  and must contain a correct alternate
              name of type DNS (FQDN).  If the remote hostname is
              not  fully  qualified, the domain specified by con-
              figuration option DefaultDomain is appended  to  it
              before comparing it to certificate alternate names.

              If no CA certificates are specified in the configu-
              ration  file, the protocol tries to do key exchange
              with ordinary public keys.  Otherwise  certificates
              are  preferred.   Multiple  CAs  are permitted, but
              only one per HostCA keyword.

              If   the   additional    comma-separated    keyword
              use_expired_crls  is  given,  expired  CRLs will be
              allowed for this  CA  for  the  specified  duration
              after  the  expiration,  if newer CRLs are unavail-
              able. WARNING:  This  feature  allows  a  malicious
              party  to force the use of expired CRLs if the said
              party  can  perform  a   denial-of-service   attack
              against the CRL distribution point.

              Specifies  the  external key provider for accessing
              CA certificates that are trusted for server authen-
              tication.    The    value    is   of   the   format
              "provider:initstring". Currently,  the  only  valid
              value for provider on z/OS is zos-saf. For the for-
              mat of the initstring, see ssh-externalkeys(5).

              This keyword is similar  to  HostCAEkProvider,  but
              disables  CRL  checking  for  the  CA  certificates
              defined  by  "provider:initstring".   This   option
              should be used for testing purposes only. In normal
              operations, it is highly recommended to always  use

              This keyword is similar to HostCA, but disables CRL
              checking for the given ca-certificate.  This option
              should be used for testing purposes only. In normal
              operations, it is highly recommended to always  use

              This keyword specifies which format the client pro-
              grams  should  use  when storing remote server host
              keys.  The argument must be plain  or  hashed.  The
              hashed format prevents address harvesting.

              In  the  plain  format, the name of a host key file
              includes  the  hosts's  name  and   port,   as   in
    ,  and the file contains
              the host's public key in plaintext format.

              In the hashed format, the name of a host  key  file
              is  keys_hhh...,  where  hhh  is a hash of the host
              port and name.  The file contains  a  hash  of  the
              host's  public  key. A salt is included in the hash
              calculations. The value of the salt  is  stored  in
              the  file  salt  in  the same directory as the host
              keys, $HOME/.ssh2/hostkeys.

              The default is hashed.

              This keyword specifies whether the server must pre-
              sent a certificate  to  the  client  during  server
              authentication.  If the client does not receive the
              certificate, the server authentication  fails.  The
              argument must be yes or no.  The default is no.

              This  keyword  specifies the method used for server
              host certificate validation.  Its value can be tec-
              tia  or  saf, or both (saf,tectia).  The default is

              If saf is specified, RACF/SAF is used for  validat-
              ing  server  host certificates. The server certifi-
              cates must exist in a trusted key ring defined  by
              the HostKeysEkProvider keyword. Note that when only
              SAF validation is used,  the  certificate  validity
              period and revocation status are not checked.

              If  tectia  is specified (or the keyword is missing
              from the configuration), the SSH Tectia Certificate
              Validator  is  used for validating server host cer-
              tificates. The server certificates must  be  issued
              by a trusted certification authority defined in the
              HostCA, HostCANoCRLs,  HostCAEkProvider,  or  Host-
              CaEkProviderNoCRLs keyword.

              If  both values are specified, the RACF/SAF valida-
              tion is performed first and after that the SSH Tec-
              tia  validation. The server certificates must exist
              in the  local  trusted  key  ring  defined  by  the
              HostKeysEkProvider keyword. Also the CA certificate
              of the issuing certification authority has to exist
              in  the local trusted key ring defined by the Host-
              CaEkProvider or HostCAEkProviderNoCRLs keyword.

              Specifies  the  external key provider for accessing
              server host keys (certificates)  that  are  trusted
              for server authentication. The value is of the for-
              mat  "provider:initstring".  Currently,  the   only
              valid  value  for  provider on z/OS is zos-saf. For
              the  format  of  the  initstring,  see   ssh-exter-

              The name of the user's identification file.  The
              default is $HOME/.ssh2/identification.

              The name of the user's key file used in  public-key
              authentication.   This is given as a pattern string
              which is expanded by ssh2. %D is  the  user's  home
              directory,  %U is the user's login name, %IU is the
              user's user ID (uid), and %IG is  user's  group  ID

              If  multiple  IdentityKeyFile  options are defined,
              all are offered during  authentication.  Additional
              key  files can still be given from the command line
              or defined in  the  identification  file.  See  the
              IdentityFile configuration option.

              This option is disabled by default.

              Specifies  whether the system should send keepalive
              messages to the other side.  If they  are  sent,  a
              broken  connection  or crash of one of the machines
              will be properly noticed.  However, this means that
              connections will die if the route is down temporar-
              ily, and some people find this annoying.

              The default is yes (to send  keepalives),  and  the
              client  will notice if the network goes down or the
              remote host dies.  This  is  important  when  using
              scripts, and many users want it.

              To  disable  keepalives, the value should be set to
              no in both the server and the client  configuration

              The  argument  format is port:host:hostport. See -L
              in ssh2(1) for more detailed information on forward

       MACs   Specifies  the  MAC  (Message  Authentication Code)
              algorithm to use for data  integrity  verification.
              The supported algorithms are hmac-md5, hmac-md5-96,
              hmac-sha1, hmac-sha1-96,,  and

              Multiple MACs can be specified as a comma-separated
              list.  Special values  for  this  option  are  Any,
              AnyStd,  none,  AnyMac,  and AnyStdMac.  Any allows
              all MACs including none; AnyStd allows  only  those
              mentioned  in  the  IETF-SecSh draft and none; none
              forbids any use of MACs; AnyMac and  AnyStdMac  are
              analogous  to the first two cases but exclude none.
              AnyStdMac is the default.

              If yes, enables  socket  option  TCP_NODELAY.   The
              argument must be yes or no.  The default is no.

              Specifies  the OCSP (Online Certificate Status Pro-
              tocol) Responder service address in URL format,  in
              case  OCSP  should  be used instead of CRLs and the
              certificate itself does not contain a valid Author-
              ity  Info  Access  extension with an OCSP Responder
              URL. Note that for the OCSP validation to  succeed,
              both   the  end-entity  certificate  and  the  OCSP
              Responder certificate must be issued  by  the  same

              If  OCSP responder is defined globally or in a cer-
              tificate, it is tried first; only if it fails, tra-
              ditional  CRL checking is tried, and if that fails,
              the certificate validation returns a failure.

              Sets the password prompt that the  user  sees  when
              connecting  to  a host.  Variables %U and %H can be
              used to  give  the  user's  login  name  and  host,

              Specifies  the  file  where  the  process ID of the
              client is written. The default is none.

       Port   Specifies the port number  to  connect  to  on  the
              remote host.  The default is 22.

              With  this  option,  the  client  can connect using
              SOCKS or HTTP proxy. With SOCKS,  you  can  specify
              whether to use SOCKS5 with the option UseSocks5.

              Overrides  the  value of the SSH_SOCKS_SERVER envi-
              ronment variable.

              The  format  of  the  variable   is   socks://user-
              mask  ...   (with  SOCKS  proxy)  or   http://user-
              mask ...  (with HTTP proxy).

              For   instance,   by   setting    ProxyServer    to
              host  and port 1080 are used as your
              SOCKS server for connections  outside  of  networks
      (16-bit domain) and (8-bit
              domain). Those networks are connected directly.

              If this option is set, it should almost always con-
              tain  the local loopback network ( as a
              network that is connected directly.

              This option and the option SocksServer behave iden-
              tically. Specifying both will cause the later defi-
              nition to override the first.

              All  warnings  and  diagnostic  messages  are  sup-
              pressed.   Only  fatal  errors  are displayed.  The
              argument must be yes or no.  The default is no.

              The name of the user's random-seed file.

              The number of seconds after which the key  exchange
              is  done  again.   The  default  is 3600 seconds (1
              hour).  Value '0' turns rekey requests  off.   This
              does not prevent the server from requesting rekeys.

              Other  servers  may  not  have  rekey  capabilities
              implemented  correctly,  and your connection may be
              cut off if you are connecting  to  a  server  other
              than  sshd2.   (The server may also crash, but this
              is not the fault of ssh2.)

              The argument format is port:host:hostport.  See  -R
              in ssh2(1) for more detailed information on forward

              Specifies an environment variable  to  set  in  the
              server  before  executing  a shell or command.  The
              value should be of form VAR=val.  val can be empty.
              You  can specify multiple variables by using multi-
              ple options.

              Setting the variable may fail on  the  server  end,
              e.g. because of policy decisions (see SettableEnvi-
              ronmentVars in sshd2_config(5)).  Note:  This  fea-
              ture is not implemented in sshd2 versions 3.0.x and

              Specifies whether to forward  also  an  SSH1  agent
              connection.  Legal values for this option are none,
              traditional, and ssh2.  With value none  (default),
              the  SSH1 agent connection is not forwarded at all.
              With value traditional, SSH1  agent  connection  is
              forwarded transparently like in SSH1.  Value tradi-
              tional can always be  used  but  it  constitutes  a
              security  risk,  because the agent does not get the
              information about the forwarding path.  Value  ssh2
              makes  SSH1  agent forwarding similar to SSH2 agent
              forwarding and with this mode, the agent  gets  the
              information  about the agent forwarding path.  Note
              that value ssh2 can only be used if  you  use  ssh-
              agent2 in the SSH1 compatibility mode.

              Specifies  whether to use SSH1 compatibility.  With
              this option, ssh1 is executed when the server  sup-
              ports  only  the SSH1 protocols.  The argument must
              be yes or no.

              Specifies whether to use  SSH1  internal  emulation
              code.   With this option, ssh2 can also communicate
              with ssh1 servers, without using an  external  ssh1
              program.  The argument must be yes or no.

              Specifies whether to send SSH_MSG_IGNORE packets to
              mask the password length  (otherwise,  it  is  very
              easy  to get, as the SSH1 protocol does not encrypt
              the length fields of packets).  The  argument  must
              be yes or no.  The default is yes.

              Specifies  the  path  to  the ssh1 client, which is
              executed if the server supports only SSH 1.x proto-
              cols.   The  arguments  for  ssh2 are passed to the
              ssh1 client.

              Equal to ProxyServer.

              If this flag is set to yes, ssh2 will  never  auto-
              matically add host keys to the $HOME/.ssh2/hostkeys
              directory, and refuses to connect  to  hosts  whose
              key  has changed.  This provides maximum protection
              against man-in-the-middle attacks.  However, it can
              be  somewhat  annoying if you frequently connect to
              new hosts.

              The argument must be yes, no, or ask.  The  default
              is  ask,  which means that new hosts will automati-
              cally be added to the known host  files  after  you
              have acknowledged this.  If a host key has changed,
              you will be asked whether you want  to  accept  the
              new  host  key  as  the only valid one.  If you set
              this to no, the  new  host  will  be  automatically
              added to $HOME/.ssh2/hostkeys.  yes forces the user
              to add all new hosts manually.  The  host  keys  of
              known  hosts  will be verified automatically in any

              Specifies whether ssh2 should check file  modes  of
              credentials   during   public  key  authentication.
              Specifically, this checks the user's  .ssh2  direc-
              tory  and  private  keys  for  invalid permissions.
              .ssh2 must only be writable and  the  private  keys
              must only be readable and writable by the user. The
              permission check of the user's .ssh2 directory  can
              be     further     controlled    by    using    the
              StrictModes.UserDirMaskBits configuration option.

              The argument must be yes or no.  The default is no.

              Specifies  the permission mask for the user's .ssh2
              directory if StrictModes  configuration  option  is
              used. The bits set this with option are not allowed
              to be set in the  actual  permissions.  This  means
              that with StrictModes and this option set to "077",
              the user's .ssh2 directory may not have any permis-
              sions  to  group  or  others  (only  for the user).
              Default is "022".

              Specifies how cryptographic hardware  is  utilized.
              Currently  this  option  has  an effect only on IBM
              z/OS platforms.  The value for  this  option  is  a
              comma-separated   list  of  algorithm:support_level
              pairs. The list may start with a sole support level

              Valid  values  for  support  level are yes, no, and
              must.  yes means  that  cryptographic  hardware  is
              used  for  this algorithm if available and software
              cryptography is used if  hardware  cryptography  is
              not available.

              no  means  that  software  cryptography is used for
              this algorithm.

              must means that only cryptographic hardware is used
              for the algorithm.

              Valid  values for the algorithm part of this option
              are 3des, aes, sha1, and rng.

              3des and aes mean the Triple DES and AES  symmetric
              ciphers used for encrypting the session. sha1 means
              the SHA-1 algorithm used for MAC (Message Authenti-
              cation  Code).   rng means random number generator.
              The hardware is used to generate  entropy  for  the
              random  seed at start up and for reseeding the ran-
              dom number generator algorithm periodically  during

              Example: use hardware for 3des and sha1, all others
              should use software:

              UseCryptoHardware        no,3des:must,sha1:must

              This could be coupled with allowing only  the  3des
              cipher  and sha1 MAC with Ciphers and MACs options.

              Another  example:  use  crypto  hardware  for   all
              ciphers except AES:

              UseCryptoHardware yes,aes:no

       User   Specifies who the user will log in as.  This can be
              useful if you have a different username in  differ-
              ent  machines.  This saves the trouble of having to
              remember to specify the  username  on  the  command

              Use  SOCKS5  instead of SOCKS4 when connecting to a
              remote host. Note that you have to set  SocksServer
              to a meaningful value.  The argument must be yes or
              no.  The default is no (i.e. use SOCKS4).

              Causes ssh2 to print debugging messages  about  its
              progress.   This  is helpful when debugging connec-
              tion, authentication, and  configuration  problems.
              The argument must be yes or no.  The default is no.

       SSH Communications Security Corp.

       For more information, see


PreviousNextUp[Contents] [Index]

[ Contact Information | Support | Feedback | SSH Home Page | SSH Products ]

Copyright © 2007 SSH Communications Security Corp.
This software is protected by international copyright laws. All rights reserved.
Copyright Notice




What to read next:

  • Reduce Secure Shell risk. Get to know the NIST 7966.

    The NISTIR 7966 guideline from the Computer Security Division of NIST is a direct call to action for organizations regardless of industry and is a mandate for the US Federal government.
    Download now
  • ISACA Practitioner Guide for SSH

    With contributions from practitioners, specialists and SSH.COM experts, the ISACA “SSH: Practitioner Considerations” guide is vital best practice from the compliance and audit community.
    Download now