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)
For me, SSH has replaced three very flaky protocols. Telnet (true story) for an networked shell, FTP handling simple file transfers and finally NFS mounting network attached storage.
SSH provides the -encrypted- networked shell, handles simple file transfers using SCP or SFTP, and has the power to mount filesystems using SSHFS. All in one protocol!
~$ sshfs USER@HOST:DIR mountpoint [options]
- USER Remote user
- HOST Remote host
- DIR Remote directory to mount
- mountpoint Local mountpoint
- -p PORT Specify alternate port to use
- -C Enable compression
- -F FILE Specify alternate ssh config file
sshfs is available on most Linux package repositories and can also be found on the fuse project page: http://fuse.sourceforge.net/sshfs.html