SSH out of network that is disabling your VPN

So school has started back up this semester and over the summer break, the IT department stepped up their game. I used to be able to run my tor-broswer and connect to my VPN and probe the hell of out the network using nmap. It seems those days are over.

But I can't accept that, so I immediately set about trying to figure out how to beat their new level of security and finally be able to torrent the newest release of Arch Linux to update my recovery USB (my school has impressively good bandwidth).

I quickly came across sshuttle, a service that allows you to redirect all of your internet traffic through ssh, which was an open port on this network that wouldn't let anything else get through. The only requirement is root access on the local machine and user access on the ssh destination.

sshuttle is available in the Arch community repository. It depends on iptables being property set up on the local machine.

In order to automate this process, I wrote two scripts. One to call sshuttle and one to kill it. I then saved these scripts to my /usr/bin directory in order to call these commands anywhere in my system.

Here's the script to start sshuttle:

#!/bin/bash
##Written by Brian Winkler
##Liscensed under the GPL
##Check out my blog at https://nuxview.blogspot.com/
##COntact me at <brianewinkler@gmail.com>


##Run sshuttle

##Replace [user@host] with your ssh login credentials
sshuttle -D -r [user@host] 0/0

And here's the script to kill the tunnel:

#!/bin/bash
##Wrttten by Brian Winkler
##Licensed unde the GPL
##Check out my blog at https://nuxview.blogspot.com/
##Contact me at <brianewinkler@gmail.com>


##Get process id
PROCESS=$(pgrep sshuttle)

##Store PID in kill command
##Not the most elegent solution but it gets the work done
KILL_PROCESS=$(kill -9 $PROCESS)

##Execute kill command
echo $KILL_PROCESS

Once sshuttle is running, I am fianlly able to connect my VPN and ensure the anonymity of my internet traffic whilst in public.


Both of these scripts are available on my github page. Hopefully, if you're having issues using a VPN on a public network, these work for you!

Please feel free to post any questions or comments!

i3Blocks PPTP Status Indicator

Here is yet another bash script for i3Blocks in the i3 Window Manager. This one is very similar to the VPN Status Indicator I posted previously except this applies to PPTP tunnels.

Read more about i3Blocks here and read my review of the 3 Window Manager here.

Here's the script:

#!/bin/bash
#Created by Brian Winkler
#Licensed under the GPL
#See more scripts at https://github.com/BrighBrigh/i3Blocks
#And check out my Linux blog at https://nuxview.blogspot.com/


##Check PPTP status
##Edit this file to show a unique output for when you have PPTP tunneling turned on
##Change "ppp0" in both places to fit your needs
GET_PPTP=$(ip addr show | grep pp0 | cut -d ' ' -f2 | cut -d ':' -f1)

##Store status in STATUS
if [[ $GET_PPTP == *"ppp0"* ]]
then   
    STATUS=ON
else
    STATUS=OFF
fi


#Print status
echo $STATUS
echo $STATUS



##Colors
if [[ "$STATUS" == "ON" ]]
then
    echo "#00ff00"
else
    echo "#ff0000"
fi

And once again, this script it available on my i3Blocks github page.

Please feel free to post any questions or comments!

i3Blocks VPN Status Notifier

I wrote a bash script to handle the status of my VPN. When disconnected, it displays "OFF" in red text and when connected, it displays "ON" in green.

Here's the script if you want to use it or modify it to fit your system!

#!/bin/bash



##Check VPN status
GET_VPN=$(nmcli con show | grep tun0 | cut -d ' ' -f1)

##Store status in STATUS
if [[ $GET_VPN == *"tun0"* ]]
then   
    STATUS=ON
else
    STATUS=OFF
fi



echo $STATUS
echo $STATUS



##Colors
if [[ "$STATUS" == "ON" ]]
then
    echo "#00ff00"
else
    echo "#ff0000"
fi

i3Blocks for the i3WM

I've recently removed GNOME entirely and am using the i3 Window Manager as my daily driver with pleasing results. You can read my review of the i3 Window Manager here.

Through utilizing the i3blocks-git package in the AUR, I've been able to achieve a level of customization for the i3 bar that I'm finding very satisfying.

I'm using both the default i3 blocks scripts along with Anachron's scripts and some personalized ones. Anachron's scripts provided me with the ability to increase and decrease my volume by clicking on the icon, increase and decrease my brightness by clicking on the icon, etc. Check out Anacron's scripts for some well written scripts to improve the already great i3 blocks!

Scripts can be added to /usr/lib/i3blocks/ and made executable using chmod +x. Then, these scripts can be called by adding them to the ~/.i3blocks.conf text file.

Please feel free to share your own i3 blocks set-up here!

Fix Steam using Alias

In an earlier post, I talked about utilizing aliases to shortcut commonly used commands. Today I'm going to share share my fix to a common error with Steam.

The error stems from the Steam run-time libraries  being older libraries than what are installed by default in Arch. More can be read about this error here. Every time Steam updates, it causes an error as it adds those out-of-date libraries back to the Steam run-time.

Now, to fix this, I chose to delete the libraries that steam adds. This can become a tedious task as Steam seems to update every two days. I fixed this problem by adding the following alias to my '~/.bash_aliases' file:

#Fix steam
alias fixsteam='find ~/.steam/root/ \( -name "libgcc_s.so*" -o -name "libstdc++.so*" -o -name "libxcb.so*" -o -name "libgpg-error.so*" \) -print -delete &&  find ~/.local/share/Steam/ \( -name "libgcc_s.so*" -o -name "libstdc++.so*" -o -name "libxcb.so*" -o -name "libgpg-error.so*" \) -print -delete'

So now, whenever Steam updates, I run the 'fixsteam' command afterwards to immediate fix this error and get right back into gaming!

Please feel free to post your thoughts/comments/hatred!

Using Swap and hibernate on an SSD: Why do it?

Taken from http://pcmag.com. I'm going to pretend the GPL covers this.

When setting up SSDs on Linux systems, it is generally recommended that you don't set up a swap file and in turn, don't set up hibernation. This is because the more writes to an SSD, the quicker the cells wear out and the more rapidly a SSD approaches failure. But when it comes down to it, how realistic and reasonable is this advice?

I started looking into this because I am zealous about preserving my laptop battery. Last time around, my laptop reached the point where it lasted about 30 minutes before dying on a full charge. This was only a year after replacing my battery. The problem was I had bad battery practices such as leaving it to charge overnight and letting my battery regularly fully discharge which is really harmful to Lithium-Ion batteries. Knowing what not to do, I set out setting up preventative measures so this wouldn't happen to my new Dell XPS 13.

The problem was that GNOME is set up to automatically shutdown at 5% battery, lower than the recommended 7% for Lithium-Ion batteries and the much safer 10%. While setting about changing this, I learned that the easiest and most efficient way to do this was setting up hibernate on my computer and making it hibernate at 10% battery. And this led me to my next problem, which was that hibernate is only available if you have swap, a process recommended against for SSDs, set up.

Lots of searching led me to two camps of thinking. The first being that Swap is a no-fly zone for those wishing not to break their hardware, and the second being that this is an over-cautionary suggestion with some actual merit but no actual practicality.

M.2 Type 2280 SSDs, like the one in my XPS 13, have an average estimated life of 380TB worth of writes. For a conservative estimate, I will say that it gets 300TB, or 300,000GB worth of writes. Since my Swap is the same size as my RAM (8GB), each time the computer hibernates, it writes 8GB (actually more like 2 or 3 GB but like I said earlier, conservative estimates) each time it hibernates.

So 300TB divided by 8GB each time it hibernates comes out to 37,500 writes due to hibernation before the SSD burns out. If I hibernate once a day (divide by 365), then it will take me 102 YEARS to burn out my SSD. In actuality, I only hibernate more like once a week due to my not paying attention to my battery life (divide 37,500 by 52) which means it will take 721 years to burn out my SSD. The longest I need this SSD to last is at most, 5 years. By then, I will want to upgrade anyways. But I also need my battery to last these 5 years and in my experience, they typically don't last that long. Its a trade I'm willing to make.

Recovery USBs

I am working on some longer articles but I wanted to throw this one out into the ether.

Something I've learned is to keep my Arch LiveUSB stick with me everywhere I go. I keep it in my laptop sleeve case. I can't count the amount of times I've broken my system in random public places and was so relieved to happen to have my LiveUSB with me. I've never ran into a problem I couldn't fix when breaking my system just by mounting my root and /boot partition and 'arch-chroot'-ing into them.

Its a simple thing you can do that will save you a lot of headache.