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: Jeff Squyres (jsquyres_at_[hidden])
Date: 2010-02-22 09:27:18

I took a few of the points from this thread and updated the rsh faq entry (I almost fell out of my chair when I saw "lamboot" and "recon" still listed in that entry -- yoinks!). More updates would be greatly appreciated; could you send a diff against:

On Feb 20, 2010, at 6:14 PM, Mark Hahn wrote:

> > 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
> 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.
> _______________________________________________
> users mailing list
> users_at_[hidden]

Jeff Squyres
For corporate legal information go to: