Weblog entry #32 for dkg

on limiting damage from a compromised ssh host
Posted by dkg on Tue 20 May 2008 at 20:06
Tags: ,
An interesting thread on openssh-unix-dev points out a way that a compromised remote ssh account or host could potentially trick users into divulging the passphrase for their local secret key. Given that we're all dealing with the potential for compromised ssh hosts lately, i think this is an important consideration. (this has apparently been raised on openssh-unix-dev as far back as 8 years ago).

Unfortunately, a couple messages with mangled headers seem to have broken the thread into two chunks in the archive, severing the start of the thread from the part where it starts getting really good: In particular, Damien Miller's suggestion is to forbid in-terminal key-based authentication entirely, and rely instead on ssh-agent. My impression of this strategy is that it's analogous to forcing an out-of-band verification process -- since the in-channel communication is happening in the tty, and the remote host will have some level of control over the tty once authentication succeeds, it's important that any locally-divulged secrets (e.g. the passphrase for the local secret key) are not transmitted over the tty in question.

Of course, disabling in-terminal key-based authentication creates something of a usability problem for users who aren't using X11 (and who don't have some other method for an out-of-band ssh-askpass). And it also points out the additional problems with X11 forwarding (e.g. a compromised host allowed to forward X connections could trigger a mimicry of a standard ssh-askpass password prompt). This is something that debian might want to consider, as we've diverged from upstream on the default settings for ForwardX11Trusted.

I'm uncomfortable with how Damien's suggestion raises the bar to key-based authentication in general, since users will now have to understand both keys and agents in order to effectively authenticate this way. But maybe that's what's needed, since we desperately need to phase out password-based authentication (and all the security pitfalls associated with it) in this brave new networked world.

At any rate, i've adopted the suggestion for now:

[0 dkg@squeak ~]$ tail -n1 .ssh/config
IdentityFile none
[0 dkg@squeak ~]$ 
I'm curious to know if other people have adopted this strategy, or have other mitigating techniques.

 

Comments on this Entry

Posted by ajt (85.211.xx.xx) on Tue 20 May 2008 at 22:10
[ Send Message | View Weblogs ]
Where does the balance fall between between being secure and unusable..?

I know this is a hard one to answer...

At work the SOX auditors want all sorts of silly password restrictions on the boxes on which SAP runs. Normally none of us actually ever use a password to login to any of the boxes since I persuaded everyone to use SSH and keys. On my work and home boxes most SSH login is via key exchange only and I normally use an ssh-agent and Gnome-ask-pass just because it's easier to do, but not always..

--
"It's Not Magic, It's Work"
Adam

[ Parent | Reply to this comment ]

Posted by kapil (117.193.xx.xx) on Wed 21 May 2008 at 03:00
[ Send Message | View kapil's Scratchpad ]
One way around this would be to allow each user to customise the
message that SSH uses to prompt for passphrase (or password).

Regarding the use of ssh-agent. I think what is intended is not that
the prompting for passphrase happens at the start of the ssh session
but before that. So it will work even for those who don't have X as
follows.

eval `ssh-agent`
ssh-add -i $HOME/.ssh/id_rsa

Then, when you want to use ssh you can do so without typing in
any password or passphrase.


[ Parent | Reply to this comment ]

User Login

Username:

Password:

[ Advanced Login ]

Register Account

Quick Site Search