xargs argument replacement

This is how xargs works:

cat listfile | xargs ls 

but if you want to use the argument in the middle, such as "mv", you need to do the following:

cat listfile | xargs -I {} mv {} trash

-I {} tells xargs to replace all instances of {} with the argument from listfile.

So you can use other weird strings as long as you know it does not appear in the listfile, such as

cat listfile | xargs -I HAHA mv HAHA trash

Windows 7 IKEv2 with StrongSwan Certificate Generation Guide

Windows 7 supports IPSec IKEv2 with machine certificate authentication. Using StrongSwan on Linux for server, this is a good solution for Road Warrior remote access.

The problem with Windows 7 IKEv2 client is that it does not provide any log for trouble-shooting at all. So if it does not like something in your setup, it simply throws an error number and a very vague error message.  Error 13806 is one of them.

I spent a few days finally got my Windows 7 running IKEv2 machine authentication with my strongswan server. Below are a few tips for Error 13806:

1. Error 13806 is because the machine certificate or CA certificate  on the Windows 7 has problems. This is NOT about the Server's certificate. So focus on fixing the Windows 7 certificates. The error message does not really tell you this clearly.

2. There are a few variables in your client certificate that are important, whether you use OpenSSL or StrongSwan ipsec pki to generate your certs:

1. The Common Name (CN) in the subject of your certificate
2. The Subject Alternative Name (SAN) 
3. The Key Usage
4. The Extended Key Usage, where you can specify "clientAuth", "serverAuth", "1.3.6.1.5.5.8.2.2", either one or a combination of them.

Here is what works and what does not work in my tests (For Windows 7 client only, not for StrongSwan server):

• You do not need to set Key Usage and Extended Key Usage(EKU). If you set them, some combinations may cause trouble. see more below.
•  You do not need to set SAN. If you really want to set it, it has to be exactly the same as the CN. Otherwise you will get Error 13806.
•  Set CN to either a full DNS name such as "win7.mycompany.local", or just a string name "win7". Either one works.
•  If you set Key Usage to "nonRepudiation, digitalSignature, keyEncipherment", and Extended Key Usage to "1.3.6.1.5.5.8.2.2,serverAuth,clientAuth", you MUST set your CN to the long form of DNS name such as "win7.mycompany.local". Using the short form "win7" will fail and cause error 13806.

The name win7.mycompany.local does not have to be in your DNS server.

What works:

• CN="win7", no SAN, No Keyusage, No EKU.
• CN="win7", SAN="win7", No Keyusage, No EKU.
• CN="win7.mycompany.local", SAN="win7.mycompany.local", No Keyusage, No EKU.
• CN="win7.mycompany.local", SAN="win7.mycompany.local",keyUsage = nonRepudiation,   digitalSignature, keyEncipherment,  extendedKeyUsage = 1.3.6.1.5.5.8.2.2,serverAuth,clientAuth

What does not work (Error 13806):

• CN="win7", SAN="something else", No Keyusage, No EKU.
• CN="win7", SAN="win7",keyUsage = nonRepudiation,   digitalSignature, keyEncipherment,  extendedKeyUsage = 1.3.6.1.5.5.8.2.2,serverAuth,clientAuth

Your server certificate should have the following:

•   CN 
•   SAN, which should be exactly the same as your CN
•   keyUsage = nonRepudiation,   digitalSignature, keyEncipherment,  
•   extendedKeyUsage = 1.3.6.1.5.5.8.2.2,serverAuth

Your Windows 7 VPN connection host name should exactly the same as the Server's CN. And that CN name should be DNS resolvable. The easiest way to do that in a test environment is to add the CN name to your local computer's host file, located at "c:\windows\system32\drivers\etc\hosts"

Of course you should read StrongSwan's Wiki page on Windows 7. Very helpful, although can be a little bit more detailed on the client side. (http://wiki.strongswan.org/projects/strongswan/wiki/Windows7)

Andreas at StrongSwan also pointed out to me that although ECDSA has been supported by Windows since Windows Vista, it only works in IKEv1. IKEv2 in Windows 7 and Windows 2008 R2 does not support ECDSA. I have also personally verified that this is true.

One more important note:

Please make sure all your certificates has the PKIX recommended "Authority Key Identifier" in it. Otherwise, Windows 7 will give an Error 13806.


If you use OpenSSL to generate your certs, make sure the following line is in your openssl.conf file:

authorityKeyIdentifier=keyid,issuer

"Subject Key Identifier" seems to be optional for Windows 7.

Another useful post on this subject: http://forums.opensuse.org/english/get-technical-help-here/network-internet/435097-strongswan-opensuse-11-2-quick-setup.html

More Update:
Following above-written rules, I was able to generate certificates using StrongSwan ipsec pki command for both Windows 7 and StrongSwan, and the IKEv2 connection was established.

Here are the scripts:

First, Generate the CA:



bits=2048
ipsec pki --gen --type rsa --size $bits --outform pem > ca.key
ipsec pki --self --flag serverAuth --in ca.key --type rsa --digest sha1 --dn "C=CH, O=strongSwan, CN=pkiCA" --ca > caCert.der

Next, generate two certs, one for Server and one for Win7

bits=2048

for user in server win7; do

    ipsec pki --gen --type rsa --size $bits --outform pem > $user.key

    flags="";

    [ "$user" = "server" ] && flags="--flag serverAuth";

    ipsec pki --pub --in $user.key --type rsa | ipsec pki --issue --cacert caCert.der --cakey ca.key --digest sha1 \

        --dn "C=CH, O=strongSwan, CN=$user.mycompany.local" --san "$user.mycompany.local" $flags --outform pem > $user.cert

done;

Next convert Win7 cert to P12 format:

# Usage: ./convert-to-p12.sh Username

user=$1

openssl pkcs12 -export -inkey $user.key -in $user.cert -name "$user" -certfile caCert.der -caname "vpnserver7" -out $user.p12

then run ./convert-to-p12.sh win7

Next convert Server key to DER format so that Strongswan can take it:

openssl rsa -in $1.key  -out $1.der -outform DER

where $1 is "server"

[Solved] apt-get “is to be installed” errors in Debian

Fortunately, you can force the version in apt-get:

sudo apt-get install deluge-common=1.3.0-0ubuntu1

Source: http://www.absolutelytech.com/2010/10/17/solved-apt-get-is-to-be-installed-errors-in-ubuntu/