When security and integrity of a file is critical, such as with x509 certificates or other important documents, OpenSSL or other variant can be used to secure the file. With strong encryption and -hopefully- a strong password.
OpenSSL is generally available on all UNIX variants, downloadable as an executable for Windows and is also used with many other applications through the LibCrypto library.
If you need help picking a strong password, I’d recommend StrongPasswordGenerator.Com. Never share the password with the receiving party over the same medium as the file transmission. Send it Out-Of-Band over a SMS or Telephone Call or similar.
In the following example, we take a file and encrypt it using AES-256-CBC, protecting it using a password and adding a salt for extra randomness. The output is added to a newly created file.
~$ openssl enc -salt -aes-256-cbc -in TuxPics.tgz -out TuxPics.tgz.enc
enter aes-256-cbc encryption password: q55Tc9Hp68-Ry4d
Verifying - enter aes-256-cbc encryption password: q55Tc9Hp68-Ry4d
The content of TuxFiles.tgz.enc is perceived as a random binary string to EVE when in transit on the open network.
In the next example, we do the reverse action. Decrypting the file using the same password and appending the output to a new file.
~$ openssl enc -aes-256-cbc -d -in TuxFiles.tgz.enc > TuxFiles.tgz
enter aes-256-cbc decryption password: q55Tc9Hp68-Ry4d
In case the file type is not known from the decrytion result (stdout), the “file” command can be used when running Linux.
~$ file TuxPics
TuxPics: gzip compressed data
When working in a clustered Linux environment containing two or more servers, it is not uncommon to switch back and forth between the hosts. Even if it’s running one command.
SSH is a powerful tool, it can do allot more than act as remote shell or tunnel traffic. One of those features is sending a command string to the server and fetching the output.
Assuming that you have access and privileged user on the remote server, the command works as follows
~$ ssh firstname.lastname@example.org "netstat -tulpna|grep -i established"
email@example.com's password: *****
For an even more awesome experience, consider authenticating using ssh-key’s.
Ever wanted to see whats going through Squid’s cache right at the moment? But get immediately discouraged with all the timestamps, SWAPOUT, RELEASE and other cache variables?
I have a one-line for you!
~ # tail -f /var/log/squid/store.log|grep -oE '\b(http?)://[-A-Za-z0-9+&@#/%?=~_|!:,.;]*[-A-Za-z0-9+&@#/%=~_|]'
This will print out visited links that passes by squid in real time, it can be added to a bash alias for quick access:
alias squidcache="tail -f /var/log/squid/store.log|grep -oE '\b(http?)://[-A-Za-z0-9+&@#/%?=~_|!:,.;]*[-A-Za-z0-9+&@#/%=~_|]'"
Or simply run as-is for whatever reason..
~ # grep -oE '\b(http?)://[-A-Za-z0-9+&@#/%?=~_|!:,.;]*[-A-Za-z0-9+&@#/%=~_|]' /var/log/squid/store.log
Using only a username and password for authentication is no longer secure. With user-database dumps reaching millions of exposed, albeit hashed and salted, passwords. Secure authentication should include not only something you know, but also something you have (in your pocket… always).
There have been several OTP and general 2FA solutions for Linux. From SMS (Text-me-a-password) to Yubikeys. There exists a Free (so far) TOTP (Time-Based One Time Password) solution from Google, called Google Authenticator.
It uses an App called Authenticator for iOS (and Android i presume) to “show” you the tokens, who live for 30 seconds each. There exists an even more awesome package for Debian and Ubuntu called google-authenticator, which allows you to easily set it up! The package also includes the necessary PAM module.
I have made the following steps on a Raspberry Pi, running Raspian.
- Install Google Authenticator
pi@awesomebox ~ $ sudo apt-get install libpam-google-authenticator
- Run Google Authenticator
pi@awesomebox ~ $ google-authenticator
Do you want authentication tokens to be time-based (y/n) y
Your new secret key is: ZZZZZZZZZZZZZZZZ
Your verification code is 123456
Your emergency scratch codes are:
- Scan the QR-CODE on screen with the Authenticator App
- Answer yes (y)
Do you want me to update your "/home/pi/.google_authenticator" file (y/n) y
Do you want to disallow multiple uses of the same authentication token? (y/n) y
By default, tokens are good for 30 seconds and in order to compensate for possible time-skew between the client and the server, we allow an extra token before and after the current time. Do you want to do so (y/n) y
Do you want to enable rate-limiting (y/n) y
- Add PAM module
pi@awesomebox ~ $ sudo echo "auth required pam_google_authenticator.so" >> /etc/pam.d/sshd
- Enable “Challenge-Response Authentication” in SSH
pi@awesomebox ~ $ sudo vi /etc/ssh/sshd_config
Change entry ChallengeResponseAuthentication from no to yes.
- Restard SSH
pi@awesomebox ~ $ service ssh restart
- Test it out
Open up a new terminal window and ssh to your box as you normally would
user@lazybox ~ $ ssh pi@awesomebox
Password: [Enter password]
Verification code: [Enter TOTP-token from App]
Happy TOTP-ing :)
I’ve been using my Raspberry Pi as a replacement for another bulky server/heating element I used two years ago. Since then, the Credit Card sized hardware with it’s 8 Gigabyte SD-card, has endured the role of a NTP, DNS, OpenVPN, HTTP and SSH-terminal server. With no crashes or slowdowns (within expectable limits) to speak of, I recently tapped into it’s gracious GPIO.
With no previous electronics experience, I acquired the following:
- Smallest breadboard I could find (tiny!)
- Arduino-like color-coded hobby cables
- Keyes DS18b20 1-Wire (“Classic” DS18b20 not available locally)
- 4.7k Ohm resistor
I wired it all up according To This Diagram (Again, no experience)
Expectations were high, once booted up, modules loaded. The directory /sys/bus/w1/devices/ contained… Nothing.
After a quick browse through the Keyes DS18b20 Data sheet, I noticed that the Signal and Power pins was reversed in relation to the “Classic” sensor. A quick poweroff-pinchange-poweron-modprobe later fixed the issue. Luckily, nothing fried :)
Google provided me with a perl -and shell script. I added RRDtool, Lighttpd, a Crontab entry and some HTML.
Usefulness: Questionable (At least it detects “Window Open” events)