[cap-talk] MinorFs & ssh secret keys
capibara at xs4all.nl
Mon Jul 7 06:07:57 CDT 2008
Possibly an example of MinorFs and 2rulethemall would be usefull in order
for you all to understand the practical use and usage.
I would be very interested in any comments or feedback, both positive
and negative, and also would be interested to hear other people's
perspective on this approach versus the usage of powerbox constructs, and
as to if and when what approach would be more suitable in user
This text is a small walktruegh approach to using MinorFs for storing ssh
private keys. The concept behind using MinorFs for ssh private key storage
is that MinorFs provides private storage for pseudo persistent processes.
Normaly when storing an ssh private key, not only ssh, but any process
running with the same uid will be able to read the private key file.
People end up setting passwords on their private key files, just to protect
the private key from the software they run themselves. With MinorFs, the
ssh client is promoted to the status of a pseudo persistent process with
its own private disk storage.
Before we can start using Minorfs, we will need to set an administration
password for the 2rulethemall tool. 2rulethemall is a priviledged program
that has a capability to the top level CapFs directory for the invoking
user. On validation of the password, 2rulethemall will delegate this
capability to the user by disclosing the strong path to this top node.
So lets first protect the top level node from malware by setting a
password for 2rulethemall:
2rulethemall NO PASSWORD SET !!!
Now we will need to introduce minorfs to our pseudo persistent ssh process
by invoking ssh. We will let ssh try to use the non existing private key
in order to let MinorViewFs gain knowledge about our new pseudo persistent
process. ssh will ask for a password, but pressing CTRL-C at that point
will be ok.
~> ssh rob at bogus.polacanthus.net -i /mnt/minorfs/priv/home/id_rsa
Warning: Identity file /mnt/minorfs/priv/home/id_rsa not accessible: No
such file or directory.
For security purposes you may want to disable your history at this point,
in order to avoid putting powerfull strongpaths into the history file.
Now that MinorViewFs has created the private storage for our pseudo
persistent ssh process, we must use our admin tool to locate and disclose
~> grep ssh
We have found that in our case,
is a path that gives access to 'all' instances of ssh (with the same
parent chain and the same uid). For our '1st' instance we will need to use
the 'inst1' sud directory.
We can now run the ssh-keygen in order to generate the private key. Dont
provide any passphrase!
Generating public/private rsa key pair.
Enter file in which to save the key (/home/rob/.ssh/id_rsa):
Enter passphrase (empty for no passphrase):
Enter same passphrase again:
Your identification has been saved in
Your public key has been saved in
Now we are done with the powerfull administration strongpaths, so its safe
to turn the history back on.
We can now move the id_rsa.pub file to the server
~> scp id_rsa.pub rob at bogus.polacanthus.net:
id_rsa.pub 100% 395 0.4KB/s 00:00
~> ssh rob at bogus.polacanthus.net
rob at bogus:~% cp id_rsa.pub .ssh/authorized_keys
rob at bogus:~% cp id_rsa.pub .ssh/authorized_keys2
rob at bogus:~% logout
Now we are done, and we can now invoke ssh without a password and without
a passhprase on our private key.
~> ssh rmeijer at xs2.xs4all.nl -i /mnt/minorfs/priv/home/id_rsa
rob at bogus:~%
You can check with ls that /mnt/minorfs/priv/home/id_rsa is not available
if any other process tries to access it,
only (the first instance of) ssh, and only with this particular chain of
parents can access the secret key.
More information about the cap-talk