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:

#%PAM-1.0auth required pam_sepermit.soauth substack password-authauth include postlogin# Yubikey authenticationauth required pam_yubico.so id=16account required pam_nologin.soaccount include password-authpassword include password-auth# pam_selinux.so close should be the first session rulesession required pam_selinux.so closesession required pam_loginuid.so# pam_selinux.so open should only be followed by sessions to be executed in the user contextsession required pam_selinux.so open env_paramssession optional pam_keyinit.so force revokesession include password-authsession include postlogin

# 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 promptforce_color_prompt=yes

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 http://www.nomachine.com. 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.

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:

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.