Well, hasn’t it been a long time since I’ve posted here!

Just a quick announcement that I’ve posted kernel 3.18.14-1 in the el6-testing repo with the aim to replace the current 3.14.x based kernels with 3.18.x.

Current testing shows a seemless upgrade and as of right now, no issues have been reported. As always, feedback is welcome!

After a week of hard work, I’m happy to announce Xen 4.5.0 testing packages for both EL6 and EL7. These work on CentOS, Scientific Linux and RHEL.

Packages can be downloaded from:

So the openjdk in most linux distros has now been upgraded to v1.8. This has a good bug fix regarding the whole SSLv3 Poodle vulnerability.

This has one problem. The Dell DRAC remote management cards installed in a lot of Dell servers relies on SSLv3 to operate. Without this, you can get into the web interface - but when you get an error stating Error when reading from SSL socket connection and no further.

Thankfully, it is simple to re-enable SSLv3 to allow the connection to succeed.

Open up /usr/lib/jvm/*/jre/lib/security/java.security in your favourite editor as root, and change the following line:

1

jdk.tls.disabledAlgorithms=SSLv3

to

1

jdk.tls.disabledAlgorithms=

This enables SSLv3 to all java applications - however it exposes yourself to the MITM attack as defined in CVE-2014-3566. I suggest having a read of the CVE to understand if you want to leave this setting as default on your system or disable it again afterwards.

A while ago I wrote about how to do this exact thing but with an older version of openssh.

If you’re running a newer version of SSH, then the command syntax has been updated somewhat.

Firstly, once you’ve got your yubikey, you’ll need to enable EPEL for EL6/7 and install the pam_yubico package.

You’ll then need to modify the sshd pam file /etc/pam.d/sshd. There are two options here.

1) You require just the OTP; or

2) You want the OTP and a password.

If you want just the OTP, you add this just after the #%PAM-1.0 header:

1

auth       sufficient   pam_yubico.so id=16 authfile=/etc/yubikey_mappings

If you want both password AND OTP, you add this:

1

auth       required     pam_yubico.so id=16 authfile=/etc/yubikey_mappings

Now to create the /etc/yubikey_mappings user to key mapping. The README says:

1
2
3
4
5
6
7
8
9
10

Create a /etc/yubikey_mappings, the file must contain a user name and the
Yubikey token ID separated by colons (same format as the passwd file) for
each user you want to allow onto the system using a Yubikey.

The mappings should look like this, one per line:

------
   first user name:yubikey token ID1:yubikey token ID2:….
   second user name:yubikey token ID3:yubikey token ID4:….
------

Now, if you want to go further and require both a ssh key AND an OTP, you can add the following to /etc/ssh/sshd_config:

1

AuthenticationMethods publickey,password

Now after you supply a valid ssh key you will be asked for your password. If you’ve set this up correctly, this will either be your password + OTP or just OTP.

Enjoy!

Update 21/Jun/2015

One common question I get is how they can allow access without a yubikey while in the office, but force its usage outside of the office. This has a couple of parts - mainly, you’ll probably want to use a public key from inside, but force say a publickey + yubikey outside.

We do this by using a Match block in /etc/ssh/sshd_config as follows:

1
2
3
4

AuthenticationMethods publickey,keyboard-interactive

Match Address 10.1.1.0/24
        AuthenticationMethods publickey

In this method, we set that EVERYONE must use a public key and a keyboard-interactive method to authenticate, then we allow exceptions for small address spaces that we trust. I also recommend making the following changes:

1
2

PasswordAuthentication no
ChallengeResponseAuthentication yes

This disallows skipping the yubikey auth and just using a password. Although, now we’re using PAM as the auth source, you can still use a password via PAM - so we need to disable this in /etc/pam.d/sshd:

1
2

#auth       substack     password-auth
#password   include      password-auth

Hope this helps.

So I’ve been a bit paranoid of late when reading of the actions of the NSA - and looking at the default configs of sshd that ship with distros like EL6, there is a lot that can be done - however it requires updating to a newer openssh version than the ones that ship with EL6.

I now build openssh (currently v6.7p1) in my testing repo: http://au1.mirror.crc.id.au/repo/el6-testing/x86_64/

After installing this, I use the following to change options as required for ‘best practices’. A lot of these come from here. There is a bit more discussion on this by Aaron Toponce.

Firstly, remove existing SSH server keys and only create the following two. Also set AUTOCREATE_SERVER_KEYS=NO in /etc/sysconfig/sshd to stop missing keys being automatically recreated on start.

1
2
3
4
5

cd /etc/ssh/
rm -f ssh_host_*key*
echo AUTOCREATE_SERVER_KEYS=NO > /etc/sysconfig/sshd
ssh-keygen -t ed25519 -f ssh_host_ed25519_key < /dev/null
ssh-keygen -t rsa -b 16384 -f ssh_host_rsa_key < /dev/null

Then add some config to /etc/sshd/sshd_config. If you have any Match blocks, this needs to come before them. If not, add the following to /etc/sshd/sshd_config:

1
2
3
4
5
6

## Change key exchange preferences to pick secure methods.
KexAlgorithms   curve25519-sha256@libssh.org,diffie-hellman-group-exchange-sha256
Ciphers         chacha20-poly1305@openssh.com,aes256-ctr,aes192-ctr,aes128-ctr
MACs            hmac-sha2-512-etm@openssh.com,hmac-sha2-256-etm@openssh.com,hmac-ripemd160-etm@openssh.com,umac-128-etm@openssh.com,hmac-sha2-512,hmac-sha2-256,hmac-ripemd160,umac-128@openssh.com
HostKey         /etc/ssh/ssh_host_ed25519_key
HostKey         /etc/ssh/ssh_host_rsa_key

Then eventually restart the sshd service: service sshd restart

Remember to always keep an SSH session open to a server as you do these - as if you get it wrong, a failed start of sshd may lock you out of that system!