ipsec.secrets man page on Alpinelinux

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

IPSEC.SECRETS(5)		  strongSwan		      IPSEC.SECRETS(5)

NAME
       ipsec.secrets - secrets for IKE/IPsec authentication

DESCRIPTION
       The  file  ipsec.secrets	 holds	a table of secrets.  These secrets are
       used by the  strongSwan	Internet  Key  Exchange	 (IKE)	daemons	 pluto
       (IKEv1) and charon (IKEv2) to authenticate other hosts.

       It  is vital that these secrets be protected.  The file should be owned
       by the super-user, and its permissions  should  be  set	to  block  all
       access by others.

       The  file  is a sequence of entries and include directives.  Here is an
       example.

	      # /etc/ipsec.secrets - strongSwan IPsec secrets file
	      192.168.0.1 %any : PSK "v+NkxY9LLZvwj4qCC2o/gGrWDF2d21jL"

	      : RSA moonKey.pem

	      alice@strongswan.org : EAP "x3.dEhgN"

	      carol : XAUTH "4iChxLT3"

	      dave  : XAUTH "ryftzG4A"

	      # get secrets from other files
	      include ipsec.*.secrets

       Each entry in the file is a list of optional ID selectors, followed  by
       a  secret.   The	 two  parts  are separated by a colon (:) that is sur‐
       rounded by whitespace. If no ID selectors are specified the  line  must
       start with a colon.

       A  selector is an IP address, a Fully Qualified Domain Name, user@FQDN,
       %any or %any6 (other kinds may come).

       Matching IDs with selectors is fairly straightforward: they have to  be
       equal.  In the case of a ``Road Warrior'' connection, if an equal match
       is not found for the Peer's ID, and it is in the form of an IP address,
       a  selector  of %any will match the peer's IP address if IPV4 and %any6
       will match a the peer's IP address if IPV6.   Currently,	 the  obsolete
       notation 0.0.0.0 may be used in place of %any.

       In  IKEv1 an additional complexity arises in the case of authentication
       by preshared secret: the responder will need  to	 look  up  the	secret
       before  the  Peer's ID payload has been decoded, so the ID used will be
       the IP address.

       To authenticate a connection between two hosts,	the  entry  that  most
       specifically  matches  the host and peer IDs is used.  An entry with no
       selectors will match any host and peer.	More  specifically,  an	 entry
       with  one  selector  will match a host and peer if the selector matches
       the host's ID (the peer isn't considered).  Still more specifically, an
       entry with multiple selectors will match a host and peer if the host ID
       and peer ID each match one of the selectors.  If	 the  key  is  for  an
       asymmetric  authentication  technique (i.e. a public key system such as
       RSA), an entry with multiple selectors will match a host and peer  even
       if  only the host ID matches a selector (it is presumed that the selec‐
       tors are all identities of the host).  It is acceptable for two entries
       to  be the best match as long as they agree about the secret or private
       key.

       Authentication by preshared secret requires that both systems find  the
       identical  secret  (the	secret	is not actually transmitted by the IKE
       protocol).  If both the host and peer appear in the selector list,  the
       same  entry  will  be  suitable	for  both  systems so verbatim copying
       between systems can be used.  This naturally extends to	larger	groups
       sharing	the  same secret.  Thus multiple-selector entries are best for
       PSK authentication.

       Authentication by public key systems such as  RSA  requires  that  each
       host have its own private key.  A host could reasonably use a different
       private keys for different interfaces and for different peers.  But  it
       would  not  be  normal to share entries between systems.	 Thus thus no-
       selector and one-selector forms of entry often make  sense  for	public
       key authentication.

       The key part of an entry must start with a token indicating the kind of
       key.  The following types of secrets are currently supported:

       PSK    defines a pre-shared key

       RSA    defines an RSA private key

       ECDSA  defines an ECDSA private key

       P12    defines a PKCS#12 container

       EAP    defines EAP credentials

       NTLM   defines NTLM credentials

       XAUTH  defines XAUTH credentials

       PIN    defines a smartcard PIN

       Details on each type of secret are given below.

       Whitespace at the end of a line is ignored. At the start of a  line  or
       after whitespace, # and the following text up to the end of the line is
       treated as a comment.

       An include directive causes the contents of the named file to  be  pro‐
       cessed  before  continuing with the current file.  The filename is sub‐
       ject to ``globbing'' as in sh(1), so every file with a matching name is
       processed.   Includes  may be nested to a modest depth (10, currently).
       If the filename doesn't start with a /, the  directory  containing  the
       current file is prepended to the name.  The include directive is a line
       that starts with the word include, followed by whitespace, followed  by
       the filename (which must not contain whitespace).

   TYPES OF SECRETS
       [ <selectors> ] : PSK <secret>
	      A	 preshared  secret  is	most  conveniently  represented	 as  a
	      sequence of characters, which is delimited by double-quote char‐
	      acters (").  The sequence cannot contain newline or double-quote
	      characters.
	      Alternatively, preshared secrets can be represented as hexadeci‐
	      mal or Base64 encoded binary values. A character sequence begin‐
	      ning with 0x is interpreted as sequence of  hexadecimal  digits.
	      Similarly, a character sequence beginning with 0s is interpreted
	      as Base64 encoded binary data.

       : RSA <private key file> [ <passphrase> | %prompt ]
       : ECDSA <private key file> [ <passphrase> | %prompt ]
	      For the private key file both absolute paths or  paths  relative
	      to /etc/ipsec.d/private are accepted. If the private key file is
	      encrypted,  the  passphrase  must	 be  defined.  Instead	of   a
	      passphrase  %prompt  can be used which then causes the daemon to
	      ask the user for the password whenever it is required to decrypt
	      the key.

       : P12 <PKCS#12 file> [ <passphrase> | %prompt ]
	      For  the	PKCS#12	 file both absolute paths or paths relative to
	      /etc/ipsec.d/private  are	 accepted.   If	  the	container   is
	      encrypted,   the	passphrase  must  be  defined.	Instead	 of  a
	      passphrase %prompt can be used which then causes the  daemon  to
	      ask the user for the password whenever it is required to decrypt
	      the container. Private keys,  client  and	 CA  certificates  are
	      extracted	 from  the container. To use such a client certificate
	      in a connection set leftid to one of the subjects	 of  the  cer‐
	      tificate.

       <user id> : EAP <secret>
	      The format of secret is the same as that of PSK secrets.
	      EAP secrets are IKEv2 only.

       <user id> : NTLM <secret>
	      The format of secret is the same as that of PSK secrets, but the
	      secret is stored as NTLM hash, which  is	MD4(UTF-16LE(secret)),
	      instead of as cleartext.
	      NTLM secrets can only be used with the eap-mschapv2 plugin.

       [ <servername> ] <username> : XAUTH <password>
	      The  format  of  password	 is  the  same as that of PSK secrets.
	      XAUTH secrets are IKEv1 only.

       : PIN %smartcard[<slot nr>[@<module>]]:<keyid> <pin code> | %prompt
	      The smartcard selector  always  requires	a  keyid  to  uniquely
	      select  the correct key. The slot number defines the slot on the
	      token, the module name refers to	the  module  name  defined  in
	      strongswan.conf(5).   Instead  of specifying the pin code stati‐
	      cally, %prompt can be specified, which causes the daemon to  ask
	      the user for the pin code.

FILES
       /etc/ipsec.secrets

SEE ALSO
       ipsec.conf(5), strongswan.conf(5), ipsec(8)

HISTORY
       Originally  written  for	 the  FreeS/WAN project by D. Hugh Redelmeier.
       Updated	   and	   extended	for	the	strongSwan     project
       <http://www.strongswan.org> by Tobias Brunner and Andreas Steffen.

BUGS
       If  an  ID is 0.0.0.0, it will match %any; if it is 0::0, it will match
       %any6.

5.1.3				  2011-12-14		      IPSEC.SECRETS(5)
[top]

List of man pages available for Alpinelinux

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