Michael Stapelberg: Using your TPM for SSH authentication
Thomas Habets has blogged
about using your TPM (Trusted Platform Module) for SSH authentication a few
weeks ago. We worked together to get his package simple-tpm-pk11 into
Debian, and it has just arrived in unstable :-).
Using simple-tpm-pk11, you can let your TPM generate a key, which you then can
use for SSH authentication. This key will never leave the TPM, so it is safer
than having your key on the filesystem (e.g.
~/.ssh/id_rsa), since
file system access is not enough to steal your key anymore. Instead, you ll
need remote code execution.
To use this software, first make sure your TPM is enabled in the BIOS. In my
ThinkPad X200 from 2008, the TPM is called Security Chip .
Afterwards, claim ownership of your TPM using tpm_takeownership -z
(from the tpm-tools package) and enter a password. You will
not need to enter this password for every SSH authentication
later (but you may choose to set a separate password for that).
Then, install simple-tpm-pk11, create a key, set it as your
PKCS11Provider and install the public key on the host(s) where you want to use
it:
mkdir ~/.simple-tpm-pk11 stpm-keygen -o ~/.simple-tpm-pk11/my.key echo key my.key > ~/.simple-tpm-pk11/config echo -e "\nHost *\n PKCS11Provider libsimple-tpm-pk11.so" >> ~/.ssh/config ssh-keygen -D libsimple-tpm-pk11.so ssh shell.example.com tee -a .ssh/authorized_keysYou ll now be able to ssh into shell.example.com without having the key for that on your file system :-). In case you have any feedback about/troubles with the software, please feel free to contact Thomas directly.
Writing this because there seems to be no correct documentation on the
relevant google websites and it turns out to be non-trivial. Our goal
here is to unsubscribe from a ordinary google group.
Mails from the google group contain the quoted footer:
I really like to read code written by different people.
I've always been the type of learner that can cover a lot of ground by looking
at examples. A few of the programming tricks I acquired over time have definitely
been learnt by reading programs written by other people. There are of course
cases of disagrement with coding style (lets put that very mildly), so not every
project is fun to read. But I tend to find projects I like enough to actually
look at their source code.
Now, if you get into this habit, there is also the occasional spotting of a bug.
Many are really cosmetic, like typos in comments or documentation.
Others are maybe more serious, who knows what can happen if you read a few
lines of code written by someone you have never met in person.
This is one of the original arguments of open source and free software.
It basically goes like: "People will read your code and report problems."
I know that happens, but I also know that there are cases of people finding
relatively minor things during a small code review, which they don't
report, or which get lost in some developers INBOX.
I remember waiting months to see memory corruption fixes for a particular
project I submitted by email to actually appear in the development repository.
In some cases you really need to track your patches and prod someone to
remind them about your contribution if need be.
True, some of these issues are probably minor enough to not really
hurt if they get lost, but I have a feel that a lot of minor things also
sort of add up.
This is where 
Let s assume you are a sysadmin and have to debug a daemon giving bad performance on one machine, but not on the other. Of course, you did not setup either machine, have only basic knowledge of the said daemon and would really love to watch that awesome piece of cinematographic art with a bunch of friends and a couple of beers. So it s like every day, right?
The problem with understanding running setups is that you often have to read configuration files. And when reading one is not enough, you have to compare two or more of them. Suddenly, a wild problem occurs: order and indentation do not matter (unless they do), comments are often just beautiful noise and why the hell did that guy smoke/drink/eat while explicitly setting ALL THE OPTIONS to their defaults before actually setting them as he wanted.
If you are using 
In case you are using busybox-static like me to create custom initramfses, here a little warning:
The current busybox-static in unstable lost its ability to find builtins with no /proc/self/exe,
so if you use it make sure you either have all builtins you need up until mount /proc (including mount)
and after you umount all file systems as explicit symlinks or simply create a /proc/self/exe -> /bin/busybox
symlink...
AltOS 1.3.2 Bug fixes and improved APRS support
Bdale and I are pleased to announce the release of
After so many attempts to have my shiny Movistar Peru (Internet M vil) 3G ZTE MF193 modem to work out-of-the-box in Debian jessie (unstable) with NetworkManager, the word frustration was hitting on my head. Even trying to do 
I ve been hacking (on and off) on a small bit of code (written in 
Graph Databases and Config management was crazy, JavaScript as well ) and there might be some cool new things to come soon, which we discussed there 
A new release 0.2.11 of
It has been all over the place. The Debian CTTE has chosen systemd over
upstart as default init system by chairman call. This decision was
overdue, as it was pretty clear that the tie will not change, and thus it will
be up to chairman. There were no new positions presented, and nobody was being
convinced of a different preference. The whole discussion had been escalating,
and had started to harm Debian.
Some people may not want to hear this, but another 10 ballots and options
would not have changed this outcome. Repating essentially the same decision
(systemd, upstart, or "other things nobody prefers") will do no good, but turn
out the same result, a tie. Every vote counting I saw happen would turn out this
tie. Half of the CTTE members prefer systemd, the other half upstart.
The main problems, however, are these:
