Open MPI logo

Open MPI User's Mailing List Archives

  |   Home   |   Support   |   FAQ   |   all Open MPI User's mailing list

Subject: Re: [OMPI users] password-less ssh
From: Mark Hahn (hahn_at_[hidden])
Date: 2010-02-20 18:14:09


> Okay, yes, setting SSH_AUTH_SOCK is the right thing to do, but this strikes
> me as clumsy.

normally, you should run ssh-agent only on the machine where you sit.
it operates until you logout (you can also tell it to discard keys).
ssh-agent is normally part if your X startup sequence, so that all
terminals/etc inherit SSH_AUTH_SOCK and can do agent-based operations.

> I'm trying to understand how things should be set up so that I
> don't have to take special action each time I log in. Do I do some
> .login/.logout magic?

no, that would be very clumsy.

> Or, why not just go without a DSA passphrase? The passphrase only protects
> me from root, before whom I am rather powerless anyhow.

unencrypted keys are the moral equivalent of putting your password
into a file, in the clear. anyone who gains access to the file _owns_
your accounts.

> Also, the OMPI FAQ says authorized_keys should have 644 protection. Out on
> the web, it appears people advise 600, which doesn't make sense to me since
> it just has public keys in it anyhow. (My head is starting to spin.)

it shouldn't be 644, since there's no reason for unrelated users to know
what keys permit login to your account. the answer is also wrong about
permissions for home and .ssh directories: there's no ssh reason for
either to be readable by group or other. what ssh is most picky about
is that it doesn't want ~, .ssh or .ssh/authorized_keys to be writable,
even by group. that is, no one but the user should be able to alter
what keys permit login. but I can't think of any reason to permit
anyone, even in your group, to read .ssh, either.

>>> This is with regards to http://www.open-mpi.org/faq/?category=rsh#ssh-keys

this page is not wonderful.

a pretty common structure for clusters is that both login and compute nodes
are in the same administrative domain. that is, the same definition of valid
users, shared home directory, etc. as such, the most robust, least-effort
use of ssh is to make the compute nodes trust (via hostbased shosts.equiv)
the login nodes.

>>> Also, it appears that I do *NOT* have an ssh-agent running automatically
>>> for me. How often do I have to start one up? It appears that if I start

many desktop distos will start ssh-agent automatically - for instance,
.Xclients might do
           exec ssh-agent startkde
(this means that X starts ssh-agent as a parent to your window manager,
the main point of which is that the WM and all the apps it starts will
inherit your SSH_AUTH_SOCK setting. you'll want to run ssh-add as well
to actually provide the agent with keys. when you logout, the agent
goes away as it should.

>>> one up and log out and then log back in again, the old ssh-agent is still

ssh-agent should run on your desktop, since you fundamentally must trust
the machine you sit at. you should avoid starting a remote ssh-agent
(and should avoid agent forwarding if possible.)

>>> there but not usable. I have to start up a new one. So, do I have to
>>> start an ssh-agent each time I log in?
>>>
>>> Or, I could use no DSA passphrase, but that seems to be frowned upon.

it's just hazardous. if the unencrypted private key file never leaves
your desktop, it's not entirely stupid, but putting an unencrypted priv key
on remote machine or fileserver is just asking to be owned. (though it is
useful to note that the authorized_keys file format can express some pretty
powerful restrictions on how the key can be used - only from certain hosts,
only to do a certain command, etc.)

regards, mark hahn.