sshfp dns

I've set up DNSSEC, so I'm on the path to trusting DNS more. I can put SSH key fingerprints for my hosts into DNS, and SSH clients can check those.

Even with insecure DNS, this is probably better than what you do now, which is to just to choose 'yes' to the following prompt without actually checking: (seriously, do you ever bother?)

The authenticity of host 's0.barwen.ch (192.168.55.55)' can't be established.
RSA key fingerprint is 9e:81:ab:cb:2a:ad:26:2f:10:ed:dd:5c:55:dd:ea:58.
No matching host key fingerprint found in DNS.
Are you sure you want to continue connecting (yes/no)? 

SSH can check s0's DNS record to see if a fingerprint is stored there, and tell you if it matches. So lets set that up.

I need to add an SSHFP record to the DNS for s0.barwen.ch.

On host fubar (without needing to be root):

$ ssh-keygen -r s0.barwen.ch
s0.barwen.ch IN SSHFP 1 1 560f08c1687a60e62a65ef427e63698ae1797d6f
s0.barwen.ch IN SSHFP 2 1 4ef38fd457d0afec50ca21eacb771f724e6d7236

So those are the records to add to barwen.ch's DNS.
(btw, vim on my machine doesn't like SSHFP records and highlights everythign red - eww)

Now wait for DNS to settle, and when I connect for the first time, I get a different message (my emphasis).

The authenticity of host 's0.barwen.ch (192.168.55.55)' can't be established.
RSA key fingerprint is 9e:81:ab:cb:2a:ad:26:2f:10:ed:dd:5c:55:dd:ea:58.
Matching host key fingerprint found in DNS.
Are you sure you want to continue connecting (yes/no)? 

Cool.

You might need to set the client option VerifyHostKeyDNS ask in your ~/.ssh/config - if you really trust DNS, you can set it to yes instead, and it won't even ask you when there's an SSHFP record present.

You can try this yourself, even without a user account, because host key verification happens before user authentication: ssh -o 'VerifyHostKeyDNS ask' s0.barwen.ch

ASCII

An ASCII character walks into a bar.
The bartender says "What's the problem?"
The ASCII character says, "I have a parity error."
The bartender nods, and says, "Yeah, I thought you looked a bit off."

time for visa transaction dispute!

so I took my laptop back to a-mac utrecht, as its still got its crash-every-three-days problem. They refused to either refund the money or replace the laptop with a new one. Whilst they said they would talk to apple about a replacement, this has gone far enough for a product that was defective as sold, so I'm going to take advantage of the transaction protections I apparently get from the consumer credit act (and Visa), and dispute the transaction.

I got a lovely comment from the manager of the store when I said that I would expect a kernel crash every one to two years not every three days, that he would expect it to never happen. Which is funny in a "yes we sold you crap but we won't fix it" way.

numbering commits

svn gives each commit a unique number. mercurial does somethign similar. CVS doesn't. git has commit IDs btu they are big and dont' have an intrinsic order (if you dehash two commit IDs you can figure out relative order but its not apparent from the IDs themselves)

I'm interested in numbering the commits on a git branch that is imported from CVS, so there's a well defined linear order (unlike in git in general).

I hacked together this script:

#!/bin/bash

COMMITCOUNT=$( git rev-list origin | wc -l)

echo There are $COMMITCOUNT commits on the origin branch

# this strips whitespace
export COUNT=$(($COMMITCOUNT))

git rev-list origin | while read commitid ; do
  echo numbering $commitid as $COUNT
  TAG=cvs$COUNT
  git tag $TAG $commitid
  COUNT=$(( $COUNT -1))
done

which works like this:

$ ./number-cvs 
There are 205 commits on the origin branch
numbering fea9db3bc7b3e36f82a97d3bb194eb60ecb3b57f as 205
numbering aedbfe81cc1dbf3d6f833225aa41826854398a3c as 204
numbering f040d23565211acb637d3325d240d675fe1e61a6 as 203
numbering eef4a46ce30de2836402a373e8eae49fc1b75935 as 202
numbering 2bb5b931be9beb0d90a2796b85585149465f8fc3 as 201
numbering a4372569c60bcb6d92a63b258389b5f1a210dd40 as 200
fatal: tag 'cvs200' already exists
numbering bbd6af71ef17fcb05a9cf86a372837dcf470e30b as 199
fatal: tag 'cvs199' already exists
numbering 6e1dc4d7d59b3515a3f46c17517c1bb85172c7bc as 198
fatal: tag 'cvs198' already exists
numbering 87c59d4b1bf4c7b1bcb64af078a66290d74f6ebf as 197
fatal: tag 'cvs197' already exists
[...]

This being a hack, I don't attempt to handle previously tagged revisions and instead let git tag give a fatal error that isn't really fatal...

Now I end up with commit tags that look like cvs200, cvs201, ...

last repair attempt which pretty much says they did nothing actually seems to have done nothing

Well, it took about 46h from my Mac being returned to me for it to crash again. I won't be in Utrecht until next Thursday so I can't take it back to a-mac to grumble some more until then.

result of 2nd repair

after the previous failed attempt to make my new mac work, the 2nd repair attempt of my new mac is reported as:

Uitvoerig getest . weer waren er kleine problemen op de schijf
ditmaal konden ze wel hersteld worden
Ik zie aan de log files dat de kernel panic puur om software gaan en
niet hardware.
deze problemen zijn hersteld , en de Macbook werkt weer prima
voor een goede test zal ik de mac nog door testen 
 Na diverse testen werkt de Macbook prima geen verdere problemen

07-03-2011 Aan de log files van de machine te zien heeft het probleem
te maken met het feit dat er een Backup is terug gezet , waarvan de
fouten waarschijnlijk mee over zijn gekopieerd
Na herstel van de Harddisk * software ( werkt hij prima

which in a one-liner is "we found some corrupted files and repaired them. this is a software problem. it works fine now."

To be honest, that sounds like complete BS given the symptoms and the actions taken for previous repair (meaning its had at least two separate OS installs on two different hard-drives)... plus yes "it works fine" most of the time - just it crashes every 3 or 4 days. As the mac has been in their possession for repair for only 3 days, and I'm sure they haven't been using it as much as I do during that time, I don't think they can accurately state that it works now. The next week should tell, though.

In the meantime, Apple sent me a questionnaire about the previous repair attempt which gave me the opportunity for further grumbling (can you tell I'm English?).

-- later --

got laptop back - total result of repair: some screen dumps of them running the disk repair utility, and they wiped some fingerprints off the screen. lets see if that fixed the problem. <cough;>

ssh over CONNECT over port 80

I run an ssh server on port 443 (the https port) of one of my machines. That's good when I want to get ssh from a network which bans "everything but web-browsing" - once I have ssh I can tunnel pretty much what I want.

But the other day I ran across a network (at an airport) which allowed only port 80 - the regular http port. Even port 443 was banned (so not only could I not connect to my ssh server, but no facebook, gmail, etc...)

I already have stuff on port 80 - my webserver - so what could I do? I know ssh can be tunnelled through the http CONNECT method. Could I set that up so that my web server would serve web traffic as usual but allow me to CONNECT to the ssh server?

Turns out yes.

In the http server config - enable mod_proxy and mod_proxy_connect. Then this config in proxy.conf (or the main server config, I guess):

<IfModule mod_proxy.c>
         ProxyRequests On
        <Proxy *>
                AddDefaultCharset off
                Order deny,allow
                Deny from all
        </Proxy>
        <Proxy localhost>
          Allow from all
        </Proxy>
        AllowCONNECT 22
        ProxyVia On
</IfModule>

(If you're doing this yourself - be careful about what you allow - if you are too liberal you turn your server into an open spamming and hacking engine for the world to exploit. And it will be found. Automatically, and within days or maybe hours.)

On the client side, use netcat as a proxy command in SSH: (you can also put the proxy command in ~/.ssh/ssh_config)

ssh -o 'ProxyCommand nc -X connect -x myhost.example.com:80 localhost 22' myhost.example.com

Tada.

Note that the ssh server now sees you connecting from localhost, and the http server is the one who logs the real IP address. A caveat here is if you have IP-based security policies that make localhost special, then anyone connecting through this proxy is also special.

Lots of the config for this came from http://mariobrandt.de/archives/technik/ssh-tunnel-bypassing-transparent-proxy-using-apache-170/

So that gets me a CONNECT proxy.

But does it work at the airport? No.

Turns out the airport is also running everything through a transparent proxy: when I connect to s0.barwen.ch port 80, I'm actually connected to the airport's transparent proxy. So an http CONNECT command to localhost:22 both points to the wrong place and is administratively prohibits.

It turns out I can http CONNECT to s0.barwen.ch port 80, though, and there issue another CONNECT command to get to localhost:22:

$ nc -4 -X connect -x s0.barwen.ch:80 s0.barwen.ch 80 
CONNECT localhost:22
HTTP/1.0 200 Connection Established
Proxy-agent: Apache/2.2.14 (Ubuntu)

SSH-2.0-OpenSSH_5.3p1 Debian-3ubuntu5

So I can get to the server this way.

How can I get the ssh commandline to talk to the remote server, with the extra proxy step added?

Like this:

$ cat t.sh 
( echo "CONNECT localhost:22" ; cat ) | nc -X connect -x s0.barwen.ch:80 s0.barwen.ch 80 | ( read ; read ; read; cat)

$ ssh -o 'ProxyCommand ./t.sh' s0.barwen.ch

Now once that's done, I can run a SOCKS proxy over the same ssh connection, and route my normal web browsing through that - giving me access to https sites, and anything else that can use SOCKS.

disappointing new mac

Well my last mac died, as they do every now and then. So I activated my usual replacement behaviour: go to nearest mac store (in this case, Amac in Utrecht) and buy a new macbook.

Alas this new macbook started BSODing every few days, usually after a resume. So I took it back to the shop. They took it off for repair and diagnosed it with a faulty hard drive (?) and returned it after a week with a new HD.

Macbook still BSODs ever few days.

So back to the shop again. I thought maybe this time they'd give me a real replacement. No they want to take it off for repair again. I wonder if some dude has to sit in a room repeatedly suspending it and unsuspending it for a week to try to reproduce? Presumably it'll come back in a week with "cannot reproduce" and then it will continue crashing for me and then I will have to go argue with them lots?

This is a disappointingly slow and lame process which is not what I expected from either a Mac or from a Premium Reseller. grumble.