Over the last few years we’ve seen a series of high profile SSL fails with names like Heartbleed, BEAST and POODLE which are based on various flaws in SSL and its various algorithm/cipher implementations. SSL (otherwise formerly known as SSLv3) is dead and has now all but been abandoned as essentially “not fixable”. TLS is now the only show in town with three active versions TLSv1, TLSv1.1 and TLSv1.2 (and TLSv1.
In a previous post I covered how I’ve been using PuTTY to get through the day, I decided to expand on it a little further and document a couple steps to bring a particular server’s ports closer to you … even if they’re firewalled away. An ssh tunnel can be explained quite simply as: an encrypted connection that is used to transport another protocol Single Server sshing into a server is one thing, but what if port 22 is the only practical accessible port due to firewall restrictions?
Lately I’ve been working with quite a few AWS EC2 Instances which have required me to SSH into them at various points for troubleshooting, so I thought I might as well document a few basics of SSH with key pairs. Using PuTTY PuTTY is the most prominant Secure Shell (SSH) client out there as demonstrated by its inclusion by serveral other applications, such as WinSCP. PuTTY can make the process of connecting remotely to a server via SSH (mostly) painless.
A little rundown on how I’ve used Kimono and a little Json transformation to automatically retrieve and display various metrics from across the web on a Geckoboard dashboard.