Long-term Memory » links

Hopping from host to host with SSH, automatically

Niobos — Wed, 20 Oct 2010 08:16:03 +0000

I usually don’t just repost other people’s posts, but this one really deserves some extra attention. It explains a very elegant way to hop using SSH.

In every network setup with some level of security, there are hosts that can’t be reached directly. Instead, you need to connect to some intermediate machine first, and hop further from there. If you have set up public key authentication, SSH can do all of this for you in the background, just add a few config lines to .ssh/config:

Host IP.or.fqdn.only.reachable.from.intermediate-host
ProxyCommand ssh intermediate-host nc %h %p

This will issue an SSH connection to intermediate host, launch a netcat process to realize the hop, and connect to your unreachable host. Obviously, netcat or similar is required on intermediate-host.

DNS(SEC) – Firewall issues

Niobos — Wed, 10 Feb 2010 18:03:25 +0000

I just read this message by Mark Andrews on the BIND mailing list. It explains the possible issues with DNSSEC and over-protective firewalls, giving test-commands to verify your setup. This post is also interesting for regular DNS traffic, since a firewall doesn’t know the difference.

Here is the most interesting part:

First, you should verify that you can talk to L.ROOT-SERVERS.NET using plain DNS. This will ensure that failures in the subsequent tests are meaningful.

e.g.

dig +nodnssec +norec +ignore ns . @L.ROOT-SERVERS.NET

; <<>> DiG 9.3.6-P1 <<>> +nodnssec +norec +ignore ns . @L.ROOT-SERVERS.NET
;; global options:  printcmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 39974
;; flags: qr aa; QUERY: 1, ANSWER: 13, AUTHORITY: 0, ADDITIONAL: 15

;; QUESTION SECTION:
;.				IN	NS

;; ANSWER SECTION:
.			518400	IN	NS	a.root-servers.net.
.			518400	IN	NS	b.root-servers.net.
.			518400	IN	NS	c.root-servers.net.
.			518400	IN	NS	d.root-servers.net.
.			518400	IN	NS	e.root-servers.net.
.			518400	IN	NS	f.root-servers.net.
.			518400	IN	NS	g.root-servers.net.
.			518400	IN	NS	h.root-servers.net.
.			518400	IN	NS	i.root-servers.net.
.			518400	IN	NS	j.root-servers.net.
.			518400	IN	NS	k.root-servers.net.
.			518400	IN	NS	l.root-servers.net.
.			518400	IN	NS	m.root-servers.net.

;; ADDITIONAL SECTION:
a.root-servers.net.	518400	IN	A	198.41.0.4
b.root-servers.net.	518400	IN	A	192.228.79.201
c.root-servers.net.	518400	IN	A	192.33.4.12
d.root-servers.net.	518400	IN	A	128.8.10.90
e.root-servers.net.	518400	IN	A	192.203.230.10
f.root-servers.net.	518400	IN	A	192.5.5.241
g.root-servers.net.	518400	IN	A	192.112.36.4
h.root-servers.net.	518400	IN	A	128.63.2.53
i.root-servers.net.	518400	IN	A	192.36.148.17
j.root-servers.net.	518400	IN	A	192.58.128.30
k.root-servers.net.	518400	IN	A	193.0.14.129
l.root-servers.net.	518400	IN	A	199.7.83.42
m.root-servers.net.	518400	IN	A	202.12.27.33
a.root-servers.net.	518400	IN	AAAA	2001:503:ba3e::2:30
f.root-servers.net.	518400	IN	AAAA	2001:500:2f::f

;; Query time: 189 msec
;; SERVER: 2001:500:3::42#53(2001:500:3::42)
;; WHEN: Mon Feb  8 13:05:49 2010
;; MSG SIZE  rcvd: 492

Next we will see whether you can receive an answer that is greater than 512 bytes. This test simulates how named makes its initial queries. Most signed responses fit between 512 bytes and 1500 bytes and are returned in a single un-fragmented UDP packet. This test is designed to check this case.

e.g.

dig +dnssec +norec +ignore ns . @L.ROOT-SERVERS.NET

; <<>> DiG 9.3.6-P1 <<>> +dnssec +norec +ignore ns . @L.ROOT-SERVERS.NET
;; global options:  printcmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 381
;; flags: qr aa; QUERY: 1, ANSWER: 14, AUTHORITY: 0, ADDITIONAL: 21

;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 4096
;; QUESTION SECTION:
;.				IN	NS

;; ANSWER SECTION:
.			518400	IN	NS	a.root-servers.net.
.			518400	IN	NS	b.root-servers.net.
.			518400	IN	NS	c.root-servers.net.
.			518400	IN	NS	d.root-servers.net.
.			518400	IN	NS	e.root-servers.net.
.			518400	IN	NS	f.root-servers.net.
.			518400	IN	NS	g.root-servers.net.
.			518400	IN	NS	h.root-servers.net.
.			518400	IN	NS	i.root-servers.net.
.			518400	IN	NS	j.root-servers.net.
.			518400	IN	NS	k.root-servers.net.
.			518400	IN	NS	l.root-servers.net.
.			518400	IN	NS	m.root-servers.net.
.			518400	IN	RRSIG	NS 8 0 518400 20100214000000 20100206230000 23763 . JWEPSBVBz37WV/cvjxtlBGGLFe88ojhBM3ZZW+ZC2umpQq5lMSnE/3vO WGVWq8gOFs/mlmXttk80WxwZfUvgDXddNtqbNoNWZaGPbH9F2O+B6yDX n6jE4EcMRcjoL752uZTDMZ8WHEiEorjxsVYr1ae1MYZO5K0CqzX/qkUW 1DY=

;; ADDITIONAL SECTION:
a.root-servers.net.	518400	IN	A	198.41.0.4
b.root-servers.net.	518400	IN	A	192.228.79.201
c.root-servers.net.	518400	IN	A	192.33.4.12
d.root-servers.net.	518400	IN	A	128.8.10.90
e.root-servers.net.	518400	IN	A	192.203.230.10
f.root-servers.net.	518400	IN	A	192.5.5.241
g.root-servers.net.	518400	IN	A	192.112.36.4
h.root-servers.net.	518400	IN	A	128.63.2.53
i.root-servers.net.	518400	IN	A	192.36.148.17
j.root-servers.net.	518400	IN	A	192.58.128.30
k.root-servers.net.	518400	IN	A	193.0.14.129
l.root-servers.net.	518400	IN	A	199.7.83.42
m.root-servers.net.	518400	IN	A	202.12.27.33
a.root-servers.net.	518400	IN	AAAA	2001:503:ba3e::2:30
f.root-servers.net.	518400	IN	AAAA	2001:500:2f::f
h.root-servers.net.	518400	IN	AAAA	2001:500:1::803f:235
j.root-servers.net.	518400	IN	AAAA	2001:503:c27::2:30
k.root-servers.net.	518400	IN	AAAA	2001:7fd::1
l.root-servers.net.	518400	IN	AAAA	2001:500:3::42
m.root-servers.net.	518400	IN	AAAA	2001:dc3::35

;; Query time: 191 msec
;; SERVER: 2001:500:3::42#53(2001:500:3::42)
;; WHEN: Mon Feb  8 12:51:28 2010
;; MSG SIZE  rcvd: 801

If you get a response like this then your firewall passes UDP responses greater than 512 bytes.

If you did not get a response like this, you need to fix your firewall.

Next we will test to see whether you can get a response greater than 1500 bytes. Such responses are normally fragmented, and this test will find out whether your firewall will pass fragmented UDP packets. Failure to pass such responses will force named to fall back to using queries which are likely to trigger the use of TCP, which should be avoided. Failure to pass such answers will also slow up the resolution process.

e.g.

dig +dnssec +norec +ignore any . @L.ROOT-SERVERS.NET

; <<>> DiG 9.3.6-P1 <<>> +dnssec +norec +ignore any . @L.ROOT-SERVERS.NET
;; global options:  printcmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 57084
;; flags: qr aa; QUERY: 1, ANSWER: 21, AUTHORITY: 0, ADDITIONAL: 21

;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 4096
;; QUESTION SECTION:
;.				IN	ANY

;; ANSWER SECTION:
.			86400	IN	NSEC	ac. NS SOA RRSIG NSEC DNSKEY
.			86400	IN	RRSIG	NSEC 8 0 86400 20100214000000 20100206230000 23763 . haTtgLwOQ9Bm2F9BRqMtAzahIuUWrjcmRjFGI5s5jGUVpjgq/MOl7wRi IJ1nLQkXThzc8hn6b3faXXIhHE/8MShzOG4wFbHwJyltx8IT9E8XP4P5 Fz9TuE3EEElNE6GZNAg8UM4r8hyv/PSM8e7offdh7pg32kfW6fgoLsHy 8yQ=
.			86400	IN	DNSKEY	256 3 8 AwEAAa1Lh++++++++++++++++THIS/IS/AN/INVALID/KEY/AND/SHOU LD/NOT/BE/USED/CONTACT/ROOTSIGN/AT/ICANN/DOT/ORG/FOR/MOR E/INFORMATION+++++++++++++++++++++++++++++++++++++++++++ +++++++8
.			86400	IN	DNSKEY	257 3 8 AwEAAawBe++++++++++++++++THIS/IS/AN/INVALID/KEY/AND/SHOU LD/NOT/BE/USED/CONTACT/ROOTSIGN/AT/ICANN/DOT/ORG/FOR/MOR E/INFORMATION+++++++++++++++++++++++++++++++++++++++++++ ++++++++++++++++++++++++++++++++++++++++++++++++++++++++ ++++++++++++++++++++++++++++++++++++++++++++++++++++++++ ++++++++++++++++++++++++++++++++++++++++++++++++++++++++ ++++++++++8=
.			86400	IN	RRSIG	DNSKEY 8 0 86400 20100214235959 20100131000000 19324 . v2DVoP16w3dqsOooCxAb393ExF6p1t3d3qJsYPkeV96/t3HIuVLnxpbV 02Wx+BR7dwLiURASmebvEhZrR4gNqO15M5gerrzDdY0IXA0q0xVAUj/J NvkdiniXjoQYGUwjJsdfqxvD7NQPtSz4YTuOvMlVffV1F2Bc6Woid7AK JGkb24MeQlAMy/gQqcLPs6c3a9RvZEwofMul66bUswGS+YsL8x9A6Cbt 1bdyhRUNYSl7AifA4++Pu+0MLpbrxH7DLI8O9ZfCA3LsEQUOFjYA+2jJ mzgFqZAU0HvxeQyStnLF3/bf7qifRegrn6+cTKjKtUZ52/kUFiaqgT2t 9TemTg==
.			518400	IN	NS	a.root-servers.net.
.			518400	IN	NS	b.root-servers.net.
.			518400	IN	NS	c.root-servers.net.
.			518400	IN	NS	d.root-servers.net.
.			518400	IN	NS	e.root-servers.net.
.			518400	IN	NS	f.root-servers.net.
.			518400	IN	NS	g.root-servers.net.
.			518400	IN	NS	h.root-servers.net.
.			518400	IN	NS	i.root-servers.net.
.			518400	IN	NS	j.root-servers.net.
.			518400	IN	NS	k.root-servers.net.
.			518400	IN	NS	l.root-servers.net.
.			518400	IN	NS	m.root-servers.net.
.			518400	IN	RRSIG	NS 8 0 518400 20100214000000 20100206230000 23763 . JWEPSBVBz37WV/cvjxtlBGGLFe88ojhBM3ZZW+ZC2umpQq5lMSnE/3vO WGVWq8gOFs/mlmXttk80WxwZfUvgDXddNtqbNoNWZaGPbH9F2O+B6yDX n6jE4EcMRcjoL752uZTDMZ8WHEiEorjxsVYr1ae1MYZO5K0CqzX/qkUW 1DY=
.			86400	IN	SOA	a.root-servers.net. nstld.verisign-grs.com. 2010020701 1800 900 604800 86400
.			86400	IN	RRSIG	SOA 8 0 86400 20100214000000 20100206230000 23763 . KA46XFSIJT3xKdvlo2av5FmeFl5R8etArvA9PLJb4JUz2jioqYTjhDbT 6L5kJQaiavMF1Lic5spulaHlCHmVy+gLetI49Nc8htnd0QPWTn/MG3do isDlv9nh6uCR6cJj5W/anIkubiLHBmO11QLwVNa1IybTgTCKHNwefxG0 i/M=

;; ADDITIONAL SECTION:
a.root-servers.net.	518400	IN	A	198.41.0.4
b.root-servers.net.	518400	IN	A	192.228.79.201
c.root-servers.net.	518400	IN	A	192.33.4.12
d.root-servers.net.	518400	IN	A	128.8.10.90
e.root-servers.net.	518400	IN	A	192.203.230.10
f.root-servers.net.	518400	IN	A	192.5.5.241
g.root-servers.net.	518400	IN	A	192.112.36.4
h.root-servers.net.	518400	IN	A	128.63.2.53
i.root-servers.net.	518400	IN	A	192.36.148.17
j.root-servers.net.	518400	IN	A	192.58.128.30
k.root-servers.net.	518400	IN	A	193.0.14.129
l.root-servers.net.	518400	IN	A	199.7.83.42
m.root-servers.net.	518400	IN	A	202.12.27.33
a.root-servers.net.	518400	IN	AAAA	2001:503:ba3e::2:30
f.root-servers.net.	518400	IN	AAAA	2001:500:2f::f
h.root-servers.net.	518400	IN	AAAA	2001:500:1::803f:235
j.root-servers.net.	518400	IN	AAAA	2001:503:c27::2:30
k.root-servers.net.	518400	IN	AAAA	2001:7fd::1
l.root-servers.net.	518400	IN	AAAA	2001:500:3::42
m.root-servers.net.	518400	IN	AAAA	2001:dc3::35

;; Query time: 191 msec
;; SERVER: 2001:500:3::42#53(2001:500:3::42)
;; WHEN: Mon Feb  8 13:15:19 2010
;; MSG SIZE  rcvd: 1906

If you get a reponse like this then your firewall passes UDP responses greater than 1500 bytes.

If you did not get a response like this, you need to fix your firewall.

Next we need to see whether your firewall passes outbound TCP queries. Even when using EDNS, some answers will not fit into a UDP packet. Such responses require queries to be performed over TCP.

e.g.

dig +dnssec +norec +vc any . @L.ROOT-SERVERS.NET

; <<>> DiG 9.3.6-P1 <<>> +dnssec +norec +vc any . @L.ROOT-SERVERS.NET
;; global options:  printcmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 20036
;; flags: qr aa; QUERY: 1, ANSWER: 21, AUTHORITY: 0, ADDITIONAL: 21

;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 4096
;; QUESTION SECTION:
;.				IN	ANY

;; ANSWER SECTION:
.			86400	IN	NSEC	ac. NS SOA RRSIG NSEC DNSKEY
.			86400	IN	RRSIG	NSEC 8 0 86400 20100214000000 20100206230000 23763 . haTtgLwOQ9Bm2F9BRqMtAzahIuUWrjcmRjFGI5s5jGUVpjgq/MOl7wRi IJ1nLQkXThzc8hn6b3faXXIhHE/8MShzOG4wFbHwJyltx8IT9E8XP4P5 Fz9TuE3EEElNE6GZNAg8UM4r8hyv/PSM8e7offdh7pg32kfW6fgoLsHy 8yQ=
.			86400	IN	DNSKEY	256 3 8 AwEAAa1Lh++++++++++++++++THIS/IS/AN/INVALID/KEY/AND/SHOU LD/NOT/BE/USED/CONTACT/ROOTSIGN/AT/ICANN/DOT/ORG/FOR/MOR E/INFORMATION+++++++++++++++++++++++++++++++++++++++++++ +++++++8
.			86400	IN	DNSKEY	257 3 8 AwEAAawBe++++++++++++++++THIS/IS/AN/INVALID/KEY/AND/SHOU LD/NOT/BE/USED/CONTACT/ROOTSIGN/AT/ICANN/DOT/ORG/FOR/MOR E/INFORMATION+++++++++++++++++++++++++++++++++++++++++++ ++++++++++++++++++++++++++++++++++++++++++++++++++++++++ ++++++++++++++++++++++++++++++++++++++++++++++++++++++++ ++++++++++++++++++++++++++++++++++++++++++++++++++++++++ ++++++++++8=
.			86400	IN	RRSIG	DNSKEY 8 0 86400 20100214235959 20100131000000 19324 . v2DVoP16w3dqsOooCxAb393ExF6p1t3d3qJsYPkeV96/t3HIuVLnxpbV 02Wx+BR7dwLiURASmebvEhZrR4gNqO15M5gerrzDdY0IXA0q0xVAUj/J NvkdiniXjoQYGUwjJsdfqxvD7NQPtSz4YTuOvMlVffV1F2Bc6Woid7AK JGkb24MeQlAMy/gQqcLPs6c3a9RvZEwofMul66bUswGS+YsL8x9A6Cbt 1bdyhRUNYSl7AifA4++Pu+0MLpbrxH7DLI8O9ZfCA3LsEQUOFjYA+2jJ mzgFqZAU0HvxeQyStnLF3/bf7qifRegrn6+cTKjKtUZ52/kUFiaqgT2t 9TemTg==
.			518400	IN	NS	a.root-servers.net.
.			518400	IN	NS	b.root-servers.net.
.			518400	IN	NS	c.root-servers.net.
.			518400	IN	NS	d.root-servers.net.
.			518400	IN	NS	e.root-servers.net.
.			518400	IN	NS	f.root-servers.net.
.			518400	IN	NS	g.root-servers.net.
.			518400	IN	NS	h.root-servers.net.
.			518400	IN	NS	i.root-servers.net.
.			518400	IN	NS	j.root-servers.net.
.			518400	IN	NS	k.root-servers.net.
.			518400	IN	NS	l.root-servers.net.
.			518400	IN	NS	m.root-servers.net.
.			518400	IN	RRSIG	NS 8 0 518400 20100214000000 20100206230000 23763 . JWEPSBVBz37WV/cvjxtlBGGLFe88ojhBM3ZZW+ZC2umpQq5lMSnE/3vO WGVWq8gOFs/mlmXttk80WxwZfUvgDXddNtqbNoNWZaGPbH9F2O+B6yDX n6jE4EcMRcjoL752uZTDMZ8WHEiEorjxsVYr1ae1MYZO5K0CqzX/qkUW 1DY=
.			86400	IN	SOA	a.root-servers.net. nstld.verisign-grs.com. 2010020701 1800 900 604800 86400
.			86400	IN	RRSIG	SOA 8 0 86400 20100214000000 20100206230000 23763 . KA46XFSIJT3xKdvlo2av5FmeFl5R8etArvA9PLJb4JUz2jioqYTjhDbT 6L5kJQaiavMF1Lic5spulaHlCHmVy+gLetI49Nc8htnd0QPWTn/MG3do isDlv9nh6uCR6cJj5W/anIkubiLHBmO11QLwVNa1IybTgTCKHNwefxG0 i/M=

;; ADDITIONAL SECTION:
a.root-servers.net.	518400	IN	A	198.41.0.4
b.root-servers.net.	518400	IN	A	192.228.79.201
c.root-servers.net.	518400	IN	A	192.33.4.12
d.root-servers.net.	518400	IN	A	128.8.10.90
e.root-servers.net.	518400	IN	A	192.203.230.10
f.root-servers.net.	518400	IN	A	192.5.5.241
g.root-servers.net.	518400	IN	A	192.112.36.4
h.root-servers.net.	518400	IN	A	128.63.2.53
i.root-servers.net.	518400	IN	A	192.36.148.17
j.root-servers.net.	518400	IN	A	192.58.128.30
k.root-servers.net.	518400	IN	A	193.0.14.129
l.root-servers.net.	518400	IN	A	199.7.83.42
m.root-servers.net.	518400	IN	A	202.12.27.33
a.root-servers.net.	518400	IN	AAAA	2001:503:ba3e::2:30
f.root-servers.net.	518400	IN	AAAA	2001:500:2f::f
h.root-servers.net.	518400	IN	AAAA	2001:500:1::803f:235
j.root-servers.net.	518400	IN	AAAA	2001:503:c27::2:30
k.root-servers.net.	518400	IN	AAAA	2001:7fd::1
l.root-servers.net.	518400	IN	AAAA	2001:500:3::42
m.root-servers.net.	518400	IN	AAAA	2001:dc3::35

;; Query time: 380 msec
;; SERVER: 2001:500:3::42#53(2001:500:3::42)
;; WHEN: Mon Feb  8 13:18:19 2010
;; MSG SIZE  rcvd: 1906

If you did not receive a answer like this, you need to fix your firewall.

If all the above tests succeeded, then you should have no issues when all the root servers are responding with signed versions of the root zone.

Web-based RSS-reader

Niobos — Tue, 29 Dec 2009 19:32:30 +0000

A half year ago, I blogged about a web-based RSS-reader. Recently I found an alternative product, tt-rss. It has an AJAX-based user interface which is of course much slicker, but it also gives more features, such as:

Categories
Scoring: use regular expressions to hide/highlight certain posts

FeedOnFeeds – Web-based RSS aggregator

Niobos — Sat, 27 Jun 2009 10:52:02 +0000

Since I like to follow up on my RSS-feeds from multiple locations and computers, a regular desktop-based aggregator does not fit my needs. I played around in Google’s Reader, which is a very nice tool. Personally I don’t like my data to be in someone’s cloud. Although unlikely, Google can decide to sell your RSS-ing habits to the highest bidder or vaporize your hard-gathered collection of feeds.

That’s why I wanted to host a Reader-like interface on my own server. Some Googling around – yes, they do have a very good search engine – I found this wonderful, open source, PHP application: feed on feeds. Some highlights:

Keyboard shortcuts: read your feeds with only the keyboard, no clicking around
Shared items: Create an RSS-feed of interesting posts you read
Tagging: tag items with custom tags (manually or automatically)

The journey of an IP packet through a Linux iptables firewall

Niobos — Wed, 22 Apr 2009 17:30:22 +0000

When doing some research on the different tables in iptables, I was trying to figure out in what order what tables are traversed. Obviously PREROUTING happens before POSTROUTING, but it becomes more difficult to figure out if mangle happens before are after nat.

I found a post which links to this overview:

Connecting a serial port from VMware Fusion to a unix socket

Niobos — Sat, 18 Apr 2009 08:19:12 +0000

When I’m debugging serial communications, it’s very useful to run the standard application inside a VM. This allows me to connect the virtual RS232 port to the physical one with socat, which provides me with a detailed log of every byte.

The VMware products under Windows and linux have the option to connect their serial port to a “named pipe“, although it’s more a socket, since they allow bidirectional communication. Strangely enough, VMware Fusion, the Mac product, does not have this option.

Some Googling turned up the answer. Apparently it also works on Fusion, but there is no GUI to set it. Here are the relevant configuration items in the .vmx file:

serial0.fileType: Set this to “pipe” instead of “file”
serial0.pipe.endPoint = “client”: Add this if there is already a server

Turning webpage updates into RSS feeds

Niobos — Tue, 14 Apr 2009 15:22:15 +0000

I was bored of constantly looking for updates on a website. A little googling turned up this nice site. It turns (a part of) a webpage into an RSS feed. Here are the ones I created:

OpenID

Niobos — Tue, 31 Mar 2009 19:27:52 +0000

Up until now, I logged into my blog using the standard username/password. Since my blog is hosted as a vhost, setting up SSL (https) is a pain: You either need a dedicated IP:port per ssl-vhost, or need to work with certificates that list multiple domains (Update 2009-04-18: SNI). Running SSL on a non-standard port works pretty well, but most firewalls don’t like that. Conclusion: the only widely available way to log into my blog is over plain http. Needless to say, I don’t like my password going in plaintext over the Internet.

After doing some research, I learned that OpenID is capable of doing just that (an much more). The concept behind OpenID is fairly simple. Note that I’m cutting corners here.

A website wants to be able to identify who you are. The normal way to do this is to prompt the user for an identifier (name, nickname, email-address, handle, …) and a proof that he owns that identifier (usually a password).
The user provides the website with his OpenID identifier (usually in the form of a website-address). Note that only an identifier is supplied, no proof yet.
The original website (called relying party in OpenID jargon) surfs to the provided website (OpenID identifier) and asks that site (called the OpenID provider) to verify that the user actually owns this website.
The OpenID provider verifies the user in whatever way it wants (username/password, SSL-certificate, retinal scan, …) and asserts to the relying party that the current user does (or does not) own the specified website.
The original website accepts this assertion as a proof that the user owns the identifier.

The big difference is that the verification happens at another website than the login. This website can use SSL, even if the original website can’t. AOL’s developer network has a more detailed, but still simplified, explanation on OpenID. True geeks can just read the specs.

I currently use myOpenID as provider. They provide a detailed audit log, and allow fairly detailed settings. To test things out, I used the checkup tool at openidenabled.com. To actually make things work, I’m using the OpenID plugin for WordPress, together with its compation plugin XRDS-Simple.

Remap keys under Windows

Niobos — Fri, 27 Mar 2009 17:42:10 +0000

My previous system was a Linux-box. I made some adjustments to my keyboard in order to make it “better”. Since I use Vim a lot (apologies to Emacs-fans), the escape-key is doing overtime. On a normal keyboard however, the escape-key is located at the top left. Other keys are very near the main keyboard, but are hardly used. I almost never use the CapsLock key at all. So I switched both keys around, giving the CapsLock key the escape-function and the other way around.

Under Linux, you can remap keys using xmodmap. It seems that Windows has a similar feature, although much less documented. Here is a short summary of this article.

Windows has two levels to change the keyboard. The system-level is configured through the [HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\Keyboard Layout] registry key; the user-level one is located at [HKEY_CURRENT_USER\Keyboard Layout].

By adding (or editing) the “Scancode Map” value of type Binary Value, one can control the mapping of scancodes. Since we are at a scancode level, this operation is preformed very early in the stack (VMware only gets to see the scancodes after this mapping).

The content of the value is a bit of a mistery:

It must start with 8 bytes of 0×00
The next byte indicates how many mappings are following, PLUS 1
The mappings themselves, 4 bytes each. First 2 bytes indicate the new scancode to map to; the next 2 bytes indicate the original scancode to map from.
It must end with 4 bytes of 0×00

For my examle the binary value ended up being (line breaks are for clarity only):

00 00 00 00 00 00 00 00
03
3a 00 01 00
01 00 3a 00
00 00 00 00

Useful things to do with Bluetooth

Niobos — Sun, 08 Mar 2009 12:01:21 +0000

I just found a very nice post describing nice things to do with Bluetooth. By using the Proximity tool, my MacBook Pro can monitor the precense of my cell phone. Proximity will run an AppleScript when a selected device enters and/or leaves Bluetooth range. Most phones are class 2 Bluetooth devices, which gives a range of 10m (outdoors). This allows you to automatically lock your desktop when you leave and unlock when you come back.

Here are the scripts I ended up using on my Leopard (10.5) setup. When entering proximity:

tell application "System Events"
    tell security preferences
        set require password to wake to false
    end tell
end tell
#try
#    tell application id "com.apple.ScreenSaver.Engine" to quit
#end try

When leaving proximity:

tell application "System Events"
    tell security preferences
        set require password to wake to true
    end tell
end tell
tell application id "com.apple.ScreenSaver.Engine" to activate

I combined these scripts with the ones that I use when the MacBook goes to sleep and wakes up. I added “killall Proximity” to the sleep-script and “open /Applications/Utilities/Proximity.app” to the wakeup-script. This way, the proximity is checked right after wakeup.

Update 2009-10-29

The unlock-script doesn’t seem to work on Snow Leopard (10.6)…