You spend all your waking time at a keyboard. This blog post is about keyboards, and can be summarized as: Buy quality, cry once.
I spend a lot of time typing on a keyboard, yet I have never looked into what keyboard would be best for me. There are natural keyboards and kinesis keyboards that people speak well of, but I spend a lot of time typing on laptops and don’t want a completely different setup for laptop and desktop.
I had the same concern before switching to Dvorak back when I was a consultant (thus often using other peoples managed machines), but happily switched after verifying that even on a locked down Windows machine as a non-admin user I could select Dvorak. Also there are adapters from Dvorak to Qwerty that I could use in extremely locked down environments such as the CCIE lab (they required a doctors note though, long story).
So it would have to be a keyboard that looks like a normal one. Preferably with Dvorak on the keycaps. It seems that mechanical keyboards are all the rage, so I thought I’d give that a go.
I ended up buying a 88 key Cherry MX brown-based Continue reading
I've previously blogged about a secure connection between browser and proxy. Unfortunately that doesn't work on Android yet, since except if you use Google for Work (an enterprise offering) you can't set Proxy Auto-Config.
This post shows you how to get that working for Android. Also it skips the stunnel hop since it doesn't add value and only makes Squid not know your real address. I'm here also using username and password to authenticate to the proxy instead of client certificates, to make it easier to set up.
Hopefully this feature will be added to Chrome for Android soon (bug here) but until then you'll have to use the Android app Drony.
This way you can port forward one port from the NAT box to the proxy, and not have to use different ports everywhere.
I'll call this proxy corp-proxy.example.com.
#!/bin/sh NAME=$1 COLOR=$2 DESC="Some random machine" QUALITY=h # or l for low, m for medium set -e dispcal -m -H -q $QUALITY -y l -F -t $COLOR -g 2.2 $NAME targen -v -d 3 -G -e 4 -s 5 -g 17 -f 64 $NAME dispread -v -H -N -y l -F -k $NAME.cal $NAME colprof -v -D $DESC -q m -a G -Z p -n c $NAME dispwin -I $NAME.icc
Let's say you don't have a TPM chip, or you hate them, or for some other reason don't want to use it to protect your SSH keys. There's still hope! Here's a way to make it possible to use a key without having access to it. Meaning if you get hacked the key can't be stolen.
No TPM, but key can't be stolen anyway? Surely this is an elaborate ruse? Well yes, it is. My idea is that you essentially bounce off of a Raspberry Pi.
But doing that straightforward is too easy. I've instead made an SSH proxy, and will show you how to automatically bounce off of it. You could do the same by setting up a second SSH server (or the same one), and hack around with PAM and a restricted shell. But this solution can be run as any user, with just the binary and the set of keyfiles. Very simple.
The goal here is to log in to shell.foo.com from your workstation via
a Raspberry Pi. The workstation SSH client presents its SSH client key to the SSH Proxy
on the Raspberry Pi, and if allowed will connect on and present the SSH Continue reading
The wonder of UNIX is that you can delete running binaries and loaded shared libraries. The drawback is that you get no warning that you're still actually running old versions. E.g. old heartbleed-vulnerable OpenSSL.
Server binaries are often not forgotten by upgrade scripts, but client binaries almost certainly are. Did you restart your irssi? PostgreSQL client? OpenVPN client?
Find processes running with deleted OpenSSL libraries:
$ sudo lsof | grep DEL.*libssl apache 17179 root DEL REG 8,1 24756 /usr/lib/x86_64-linux-gnu/libssl.so.1.0.0
Or if you're extra paranoid, and want to make sure everything is using the right OpenSSL version:
!/bin/sh
set -e
LIB="/usr/lib/x86_64-linux-gnu/libssl.so.1.0.0"
if [ ! "$1" = "" ]; then
LIB="$1"
fi
INODE="$(ls -i "$LIB" | awk '{print $1}')"
lsof | grep libssl.so | grep -v "$INODE"
In my last blog post I described how to set up SSH with TPM-protected keys. This time I'll try to explain how it works.
The SRK is a public key pair that is the main secret inside the TPM chip. It is always generated by the chip, and the private key cannot be read or migrated.
In order to use the SRK key with any operation, the SRK password must be supplied. The SRK password is just an access password. It's not related to the key itself. The SRK password is usually set to the Well Known Secret (20 null characters), or sometimes the empty string, or something silly like "12345678".
There is not much point in having a good SRK password, since you probably have to store it on disk somewhere anyway, to allow TPM operations by daemons.
If you want a password then you probably want to set that per key, not chip-wide like the SRK password is.
The stpm-keygen binary asks the TPM to generate a key, and the TPM
hands back the public portion of the key, and a "blob" that has no meaning to
anyone except the TPM. The blob is encrypted Continue reading
In my last blog post I described how to set up SSH with TPM-protected keys. This time I'll try to explain how it works.
The SRK is a public key pair that is the main secret inside the TPM chip. It is always generated by the chip, and the private key cannot be read or migrated.
In order to use the SRK key with any operation, the SRK password must be supplied. The SRK password is just an access password. It's not related to the key itself. The SRK password is usually set to the Well Known Secret (20 null characters), or sometimes the empty string, or something silly like "12345678".
There is not much point in having a good SRK password, since you probably have to store it on disk somewhere anyway, to allow TPM operations by daemons.
If you want a password then you probably want to set that per key, not chip-wide like the SRK password is.
The stpm-keygen binary asks the TPM to generate a key, and the TPM
hands back the public portion of the key, and a "blob" that has no meaning to
anyone except the TPM. The blob is encrypted Continue reading
Not long after getting my TPM chip to protect SSH keys in a recent blog post, it started to become obvious that OpenCryptoKi was not the best solution. It's large, complicated, and, frankly, insecure. I dug in to see if I could fix it, but there was too much I wanted to fix, and too many features I didn't need.
So I wrote my own. It's smaller, simpler, and more secure. This post is about this new solution.
A Hardware Security Module (HSM) is any hardware that you can use for crypto operations without revealing the crypto keys. Specifically I'm referring to the Yubikey NEO and TPM chips, but it should apply to other kinds of special hardware that does crypto operations. I'll refer to this hardware as the "device" as the general term, below.
When describing the Yubikey NEO I'm specifically referring to its public key crypto features that I've previously blogged about, that enable using Yubikey NEO for GPG and SSH, not its OTP generating features.
To generate keys for these devices you have two options. Either you tell the device to generate a key using a built in random number generator, or generate the key yourself and "import" it to the device. In either case you end up with some handle to the key, so that you command the device to do a crypto operation using the key with a given handle.
This "handle" is often the key itself, but encrypted with a key that has never existed outside the device, and never will. For TPMs they are encrypted (wrapped) with the SRK key. The SRK is always generated inside Continue reading
Update 2: I have something I think will be better up my sleeve for using the TPM chip with SSH. Stay tuned. In the mean time, the below works.
Finally, I found out how to use a TPM chip to protect SSH keys. Thanks to Perry Lorier. I'm just going to note down those same steps, but with my notes.
I've written about hardware protecting crypto keys and increasing SSH security before:
but this is what I've always been after.
Update: you need to delete /var/lib/opencryptoki/tpm/your-username/*.pem,
because otherwise your keys will be migratable. I'm looking into how to either never generating
these files, or making them unusable by having the TPM chip reject them. Update to come.
When I run this again on a completely blank system I'll add Continue reading
Recently some time ago (this blog post has also been lying in draft for a while)
someone came to me with a problem they had with a Cisco 7600.
It felt sluggish and "show proc cpu" showed that the weak CPU was very loaded.
This is how I fixed it.
"show proc cpu history" showed that the CPU use had been high for quite a while, and too far back to check against any config changes. The CPU use of the router was not being logged outside of what this command can show.
"show proc cpu sorted" showed that almost all the CPU time was spent in interrupt mode. This is shown after the slash in the first row of the output. 15% in this example:
Interrupt mode CPU time is (a bit simplified and restricted to the topic at hand) used when the router has to react to some user traffic. Now why would the 7600 use the Continue readingRouter# show proc cpu sorted CPU utilization for five seconds: 18%/15%; one minute: 31%; five minutes: 42% PID Runtime(ms) Invoked uSecs 5Sec 1Min 5Min TTY Process 198 124625752 909637916 137 0.87% 0.94% 0.94% 0 IP Input [...]
I had this blog post lying around as a draft for a long time. I didn't think it was was "meaty" enough yet, but since I'm no longer a network consultant I don't think it'll become any meatier. So here it goes.
Here I will describe the process of L3-to-L2 mapping, or next-hop resolution and how it works with point-to-point circuits like PPP, ATM and Frame relay. It's the process of finding out what to actually do with a packet once the relevant routing table entry has been identified.
It's deceptively simpler than on a LAN segment, but since people generally learn Ethernet before they learn point-to-point nowadays I'm writing it anyway.
When a packet is to be sent to an address on the same subnet a L3-to-L2 mapping is done to look up the L2 destination address (if any) to apply.
The packet is then encapsulated in a L2 frame and sent out the interface.
On a normal Ethernet LAN segment ARP is used to look up L3-to-L2, and the frame will then have that (L2) MAC address as its destination. The frame will then be received by (and only by) the intended destination.
In a point-to-point interface there Continue reading