[Techtalk] ssh with no password (the debian way?)

[John Clarke]

On Tue, Mar 02, 2004 at 11:46:39AM +1100, Mary wrote:
> On Mon, Mar 01, 2004, Angelina Carlton wrote:
> > Why didnt I just hit enter to get a blank passphrase during the
> > ssh-keygen session? Because everyone tells me thats a no-no
> 
> You can do this, but if anyone gets hold of your private key they can
> log into any host that you put your public key on. Private key theft is

That's why you create a key specifically for this job and don't use the
same keypair anywhere else.  Change the keypair regularly, once a month
or even more often, depending upon your level of paranoia and the
importance of the remote site.  If you have even the slightest
suspicion that the private key has been stolen, change keys
immediately.

You can also impose access controls in the remote authorized_keys files
to limit exposure if the private key is stolen.  See the sshd man page
for an explanation of the file format and the access controls it
supports.

> The alternative is to use ssh-agent. I don't know it that well, but I
> think the man page was reasonably helpful.

ssh-agent isn't really the right way to do what Angelina wants.  It
simply saves you from typing your passphrase every time you start an
ssh session, and is really meant for interactive sessions.  You load
your key into the agent, entering your passphrase once, and then any
future ssh/scp/etc commands read the key from the agent.  Great if, for
example, you use cvs over ssh all day, but not ideal for
non-interactive jobs, unless you use it to load a key without a
passphrase.

The programs find the agent using SSH_AUTH_SOCK environment variable,
so I suppose you could start an ssh-agent for cron jobs and set
SSH_AUTH_SOCK in your crontab, but you'd still have the problem of
getting the key into the agent, which means entering the passphrase. 
If you scripted that somehow, it's no more secure than having no
passphrase if the box is hacked.  You'd also have to change your
crontab [1] if the box is rebooted or the agent restarted because the
name of the socket changes each time.


Cheers,

John

[1] OK, this is not strictly correct.  You can probably guess the
    socket name from the pid of the agent and a search for files called
    /tmp/ssh-*/agent.*, but if there's more than one agent running
    under the same uid, you can't guarantee finding the right one.  You
    also can't guarantee finding a match between socket name and agent
    pid, because the pid in the socket name is the pid of the original
    ssh-agent process before it forks, and you can't rely on the child
    pid being one more than the parent.
-- 
whois !JC774-AU at whois.aunic.net
GPG key id: 0xD59C360F
http://kirriwa.net/john/