X.509-SSH

This howto assumes you have a flavour of LINUX running on your machine!

SERVER (mainly intended for sysadmins and operators!)

INSTALLATION

• Download openssh sourcecode:

$ wget -c ftp://ftp.openbsd.org/pub/OpenBSD/OpenSSH/portable/openssh-7.7p1.tar.gz

• Download patch to support X.509 certificates for authenticaton:

$ wget -c https://roumenpetrov.info/openssh/x509-11.3.2/openssh-7.7p1+x509-11.3.2.diff.gz

• additional prerequisites:

"libc6" development packages, "zlib" development packages, "patch" binary

• On Ubuntu use:

$ sudo apt-get update $ sudo apt-get install libc6-dev zlib1g-dev patch libssl-dev

• On SLES:

install "zlib-devel[-32bit]" and "openssl-devel[-32bit]"

• Extract openssh:

$ tar -xzf openssh-7.7p1.tar.gz

• Change into the new directory and apply the downloaded patch:

$ cd openssh-7.7p1 openssh-7.7p1/$ zcat <PATH_TO_PATCH>openssh-7.7p1+x509-11.3.2.diff.gz | patch -p 1

• Configure and make:

Note: Commands enclosed in "[...]" are optional! See manpages for details.

openssh-7.7p1/$ [time] ./configure --prefix=<INSTALLATION-DIR> [2>&1 | tee configure.log] openssh-7.7p1/$ [time] make [2>&1 | tee make.log] openssh-7.7p1/$ [sudo] make install

---

---

CLIENT (mainly intended for users)

INSTALLATION

• Download openssh sourcecode:

$ wget -c ftp://ftp.openbsd.org/pub/OpenBSD/OpenSSH/portable/openssh-7.7p1.tar.gz

• Download patch to support X.509 certificates for authenticaton from:

$ wget -c http://www.roumenpetrov.info/openssh/x509-11.3.2/openssh-7.7p1+x509-11.3.2.diff.gz

• additional prerequisites:

"libc6" development packages, "zlib" development packages, "patch" binary

• On Ubuntu use:

$ sudo apt-get update $ sudo apt-get install libc6-dev zlib1g-dev patch libssl-dev

• On SLES:

install "zlib-devel[-32bit]" and "openssl-devel[-32bit]"

• Extract openssh:

$ tar -xzf openssh-7.7p1.tar.gz

• Change into the new directory and apply the downloaded patch:

$ cd openssh-7.7p1 openssh-7.7p1/$ zcat <PATH_TO_PATCH>openssh-7.7p1+x509-11.3.2.diff.gz | patch -p 1

• Configure and make:

Note: Commands enclosed in "[...]" are optional! See manpages for details.

openssh-7.7p1/$ [time] ./configure [2>&1 | tee configure.log] openssh-7.7p1/$ [time] make [2>&1 | tee make.log]

• Pick the following binaries:

openssh-7.7p1/$ cp ./ssh $HOME/bin [&& strip $HOME/bin/ssh] openssh-7.7p1/$ cp ./ssh-keygen $HOME/bin [&& strip $HOME/bin/ssh-keygen]

Note: Make sure that "$HOME/bin" is at the beginning of "$PATH" or call the created binaries directly.

---

CONFIGURATION

---

• Export a PKCS#12 keystore with your grid certificate and private key from your browser.

Note: This usually includes to set a password for the PKCS#12 keystore (referred to as the <KEYSTORE_PASSWD>).

• Export your certificate from the PKCS#12 keystore:

$ openssl pkcs12 -in <PKCS12_KEYSTORE> -clcerts -nokeys -out $HOME/.ssh/certificate.pem

Note: One has to enter the <KEYSTORE_PASSWD> once to unlock the PKCS#12 keystore for the export.

• Make sure the private key file is only accessible by you:

$ umask 0077

• Export private key from keystore:

$ openssl pkcs12 -in <PKCS12_KEYSTORE> -nocerts -out $HOME/.ssh/key.pem

Note: One has to enter the <KEYSTORE_PASSWD> once to unlock the PKCS#12 keystore for the export. Additionally one has to provide a password for the exported private key (two times).

• Create identity (file):

$ cat key.pem certificate.pem > $HOME/.ssh/x509_identity

---

Creating an x509_authorized_keys file

If you want to login to HLRS systems, using X.509-SSH, you need your account being prepared for this. We need you to sent in your username and a authorized_keys-file created from your certificate as follows:

$ Distinguished_Name=`openssl x509 -noout -subject -in usercert.pem -nameopt RFC2253` $ KeyType="x509v3-sign-rsa" or "x509v3-sign-dss"

Which KeyType-value you need depends on your file "id_x509.pub"

$ echo $KeyType $Distinguished_Name > x509_authorized_keys

USAGE

• Log in to a remote system with X.509 SSH:

$ ssh -i $HOME/.ssh/x509_identity -l <YOUR_LOGIN_NAME> -p <PORT> <SERVER>

Note: For "Laki" <PORT> is "443" and <SERVER> is "cl3fr1.hww.de". For "HAZELHEN" <PORT> is "443" and <SERVER> is "hazelhen.hww.de".

---

PROBLEMS

• If there are problems that prevent you from login, please provide us with a full log of the authentication using the switch "-vvv":

$ ssh -vvv -i $HOME/.ssh/x509_identity -l <YOUR_LOGIN_NAME> -p <PORT> <SERVER> [&> full_auth.log]

Some common problems

• Symptom(s):
  • login impossible
  • messages in the full log of the authentication similar to the following messages:

File: full_auth.log

[...]
debug2: key_type_from_name: unknown key type '-----END'
debug3: key_read: missing keytype
debug3: x509key_from_subject: 1 is not x509 key
debug3: key_from_blob(..., 279)
[...]
debug1: Next authentication method: publickey
debug1: Offering public key: x509_identity
debug3: send_pubkey_test
debug2: we sent a publickey packet, wait for reply
debug3: Wrote 368 bytes for a total of 1509
debug1: Authentications that can continue: publickey
debug2: we did not send a packet, disable method
debug1: No more authentication methods to try.
Permission denied (publickey).

• Problem:

You have created a public key from the X.509 ssh private key using an unpatched "ssh-keygen".

• Possible solution:

You don't need to have a public key ready for accessing our systems. The public key is created automatically by your client during authentication. Therefore you can just delete this file (usually named like "x509_identity.pub").

---

• Symptom(s):
  • login impossible
  • messages in the full log of the authentication similar to the following messages:

File: full_auth.log

[...]
debug1: Next authentication method: publickey
debug1: Trying private key: $HOME/.ssh/x509_identity
debug2: we did not send a packet, disable method
debug1: No more authentication methods to try.
Permission denied (publickey).

• Problem:

If "$HOME" wasn't provided by the user as anonymous alternative to his home directory (in order to not disclose his local account's name), it is very likely, that he has provided this in his "ssh_config" file using the "IdentityFile" keyword.

• Possible Solution:

According to the corresponding manual page (ssh_config(5)) shell variables are not evaluated (except "~") inside of the "ssh_config" file. Hence the "ssh" binary cannot find the identity file and therefore "[...]did not send a packet[...]", leading to an impossible login. Please only use the notations supposed in the "ssh_config" manpage shipped with your "ssh" binary.

---

SEE ALSO

Readme for X.509 SSH v11.3.2