Run Ansible modules inside a virtualenv

I've had to look way too long for a way to do this, so here it is.

I wanted to use the docker_container Ansible module on a Debian Jessie host, but it requires version docker-py >= 1.7.0 whereas Debian only has 0.5.3 in apt.
Installing with pip would be an option, but mixing OS libraries with newer ones through pip is pretty dirty... So here is how to do it cleanly in a separate virtualenv:

- name: Install virtualenv
  apt: name=virtualenv update_cache=yes cache_valid_time=3600

- name: Install docker-py inside of virtualenv
  pip: name=docker-py version=1.9.0 virtualenv=/opt/ansible_env

- name: Rancher container
    name: rancher
    image: rancher/server
    memory: 1GB
    - /var/lib/rancher-mysql:/var/lib/mysql
    restart_policy: unless-stopped
    ansible_python_interpreter: /opt/ansible_env/bin/python

The pip module will autocreate the virtualenv if its not yet there, and by overriding the ansible_python_interpreter variable on the container task, the module will be executed inside.

pam_yubico for ssh on CentOS 7


rpm -ivh

Install pam_yubico:

yum install -y pam_yubico

Set selinux boolean to permit sshd to make http connects:

setsebool -P authlogin_yubikey 1

Configure pam: (/etc/pam.d/sshd)

auth    required
auth       substack     password-auth
auth       include      postlogin
# Yubikey authentication
auth       required id=16
account    required
account    include      password-auth
password   include      password-auth
# close should be the first session rule
session    required close
session    required
# open should only be followed by sessions to be executed in the user context
session    required open env_params
session    optional force revoke
session    include      password-auth
session    include      postlogin

Create ~/.yubico/authorized_yubikeys and put your username and yubikey id code in:


Edit /etc/ssh/sshd_config:

ChallengeResponseAuthentication yes

Reload sshd:

systemctl reload sshd

Quick and dirty SSL Cert + Key

Here is a quick and dirty way to generate a self-signed SSL certificate + key:

openssl req -new -days 7300 -batch \
    -newkey rsa:2048 -keyout "${CN}.key" -nodes \
    -subj "/C=BE/ST=Antwerp/O=KRASH/commonName=${CN}/" \
    -x509 -out "${CN}.crt"

Run remote commands on a Windows machine from Linux using winrm

Quick and dirty: Run commands on a Windows machine from Linux.

On the windows host

Enable winrm:

winrm quickconfig

Enable basic authentication and permit Unencrypted traffic:

winrm set winrm/config/client/auth @{Basic="true"}
winrm set winrm/config/service/auth @{Basic="true"}
winrm set winrm/config/service @{AllowUnencrypted="true"}

On the linux host

Install the winrm ruby gem (might need ruby-dev):

gem install -r winrm

Create a ruby script that implements winrm (winrm-chef-client.rb):

require 'winrm'
endpoint = ''
myuser = 'Administrator'
mypass = 'Password'
winrm =, :plaintext, :user => myuser, :pass => mypass, :basic_auth_only => true)
winrm.cmd('chef-client') do |stdout, stderr|
    STDOUT.print stdout
    STDERR.print stderr

And execute your script with ruby:

ruby winrm-chef-client.rb

selinux module for fail2ban on Centos/RHEL 7

Update: This may not be necessary anymore with newer versions of fail2ban

The policy that is installed for fail2ban isn't working with journald (fail2ban-systemd package). Here is how to make a custom module that will allow it to function normally:

  • Create a new file (fail2ban-syslog.te):
    module fail2ban-syslog 1.0;

    require {
    type syslogd_var_run_t;
    type fail2ban_t;
    class dir read;
    class file read;
    class file open;
    class file getattr;

    #============= fail2ban_t ==============
    allow fail2ban_t syslogd_var_run_t:dir read;
    allow fail2ban_t syslogd_var_run_t:file read;
    allow fail2ban_t syslogd_var_run_t:file open;
    allow fail2ban_t syslogd_var_run_t:file getattr;

  • Compile it:
    checkmodule -M -m -o fail2ban-syslog.mod fail2ban-syslog.te
    semodule_package -o fail2ban-syslog.pp -m fail2ban-syslog.mod
  • Import it:
    semodule -i fail2ban-syslog.pp
  • Restart fail2ban and monitor /var/log/audit/audit.log for avc denied messages:
    systemctl restart fail2ban
    tail -f /var/log/audit/audit.log
  • Update: To allow logrotate on the fail2ban log file:

    module logrotate-fail2ban 1.7;

    require {
    type fail2ban_client_exec_t;
    type logrotate_t;
    type init_var_lib_t;
    class file { open read execute getattr write create execute_no_trans setattr unlink ioctl rename};

    #============= logrotate_t ==============
    allow logrotate_t fail2ban_client_exec_t:file execute_no_trans;
    allow logrotate_t fail2ban_client_exec_t:file { open read execute ioctl };
    allow logrotate_t init_var_lib_t:file { open read getattr write create unlink setattr rename };

Color shifting bash prompt based on exit code

Here is my PS1 variable to get a green bash prompt if the previous command exited successfully and a red one otherwise.
Based on the Smiley Face Bash Prompt.
Reference to bash colours:

PS1="${debian_chroot:+($debian_chroot)}\`if [ \$? = 0 ]; then echo '\[\033[01;32m\]\u@\h\[\033[00m\]:\[\033[01;34m\]\w\[\033[00m\]\$ '; else echo '\[\033[01;31m\]\u@\h\[\033[00m\]:\[\033[01;34m\]\w\[\033[00m\]\$ '; fi\`"

Edit your ~/.bashrc script:

# uncomment for a colored prompt, if the terminal has the capability; turned
# off by default to not distract the user: the focus in a terminal window
# should be on the output of commands, not on the prompt


if [ "$color_prompt" = yes ]; then
  #  PS1='${debian_chroot:+($debian_chroot)}\[\033[01;32m\]\u@\h\[\033[00m\]:\[\033[01;34m\]\w\[\033[00m\]\$ '
     PS1="${debian_chroot:+($debian_chroot)}\`if [ \$? = 0 ]; then echo '\[\033[01;32m\]\u@\h\[\033[00m\]:\[\033[01;34m\]\w\[\033[00m\]\$ '; else echo '\[\033[01;31m\]\u@\h\[\033[00m\]:\[\033[01;34m\]\w\[\033[00m\]\$ '; fi\`"
    PS1='${debian_chroot:+($debian_chroot)}\u@\h:\w\$ '

NoMachine NX kicks VNC ass

NX technology was developed to greatly enhance the X windows protocol for use over slow network connections. It can be used to provide desktop virtualisation by making an X windows session on a Linux/Solaris system available remotely. The functionality can be compared to that of running a VNC server, but with some major advantages:

  • It's faster
  • It's encrypted (uses ssh tunneling by default)
  • It supports multiple simultaneous user sessions through the same network port, unlike VNC

The functionality can be compared to that of Windows Remote Desktop services, but then for GNU/Linux and Solaris.

Commercial packages are available from A free version comes with a limit on two simultaneous users.
However, there is also an opensource implementation called FreeNX, which does not have this limitation.
Packages are available for all major distributions.

Debian wiki:
CentOS wiki:
FreeNX home page:
NoMachine official site:

Raspberry Pi

It arrived!

Now only to find something useful to do with it. Perhaps take over the role of MPD server?

Brute force attack from a /24

Perusing through some of my logwatches, I noticed a very large amount of failed login attempts. What made these stand out, was that none of the ip addresses got automatically blocked by my fail2ban filters:

       root ( 2 Time(s)
       root ( 2 Time(s)
       root ( 2 Time(s)
       root ( 2 Time(s)

Turns out that this/these systems used a very large amount of source ip addresses, to circumvent any fail2ban or sshguard systems in place. Nothing too advanced, but it goes to show that even though the attack is pretty dumb, given enough resources, it can still become quite effective and difficult to defend against.
If you have a /24 to use, and are willing to do two tries per source ip, you can get 500 tries without breaking a sweat.
Combine that with some finetuning based on default settings for popular defense mechanisms like fail2ban, and you've got yourself a pretty efficient brute forcer.

So how do you protect against this stuff?

  • Don't run ssh on the default port (pretty lame)
  • Use portknocking (too much work)
  • Only allow passwordless logins, using ssh keys
  • Don't allow ssh access from the entire internet (Block China!)

Or just some good old paranoia and a manual firewall filter. :-)

Secure delete

Watch me "securely" erase a 5G laptop hd.

And no, that's not the disk making chicken sounds.


Subscribe to RSS