"Eric J. Schwertfeger" <[EMAIL PROTECTED]> writes:
> As an interrum measure before we have passphrase-protected keys, how hard
> would it be to set lshd to require both an authorized key, and a password?
Hmm. think the client can do that already. And the protocol os
obviously designed to support that. What is needed is a little more
flexibility and logic on the server side.
What should the user interface for that (i.e. lshd command line flags)
look like?
> And as to passphrase-protected keys, is there any tentative timeframe for
> that? And just how is it planned to work. I don't know how ssh handles
> it from a technical point of view, only that a daemon is run, the
> passphrase is only input once, etc.
Basic passphrase protected keys does not involve any daemon (I'm
assuming that you are referring to ssh-agent). You simply have to type
the passphrase to lsh so that it can decrypt the key and use it to
login.
> If there are any plans, what are they? How are you planning to pass around
> the passphrase or decrypted key?
lsh doesn't do anything special with the data in its process memory
space. The assumption is that the memory space is protected (including
the swap). I usually encrypting the swap device rather than trying to
avoid data being swapped out.
As for ssh-agent, the version I use with ssh1 uses a unix domain
socket located under /tmp/ssh-my-name/, which is protected using the
file system's permisison bits. Any ssh-agent like functionality for
lsh will probably use a similar method.
However, I will probably implement gateway before ssh agent. This is
quite different from ssh-agent, but it can also let you login to your
favourite machines without typing a password. Instead of creating a
new network connection, it will just create a new tunnel inside a
previous connection. You will have to login as usual when you create
the first connectin to each remote machine.
> I'm curious as to how this will impact my current security plans
> (favorably, I'd hope :-) Preferably this could be done in such a way
> that only children of the shell that ran the daemon in will be
> authorized, without passing the actual data in an environmental
> variable. just that.
Earlier versions of ssh1 tried to do this. It used an open fd that was
inherited only to the process's children. I don't know the details of
the protocol (it ought to be tricky to handle simultaneous connections
to the daemon, so if anybody knows the details, I'm curious to hear
about it). Anyway, It didn't always work well, in particular when
using programs like make and screen.
I don't think you gain much security by using an inherited fd instead
of a unix-socket /tmp/personal-dir/foo. Anybody who has managed to
circumvent the file permissions on the /tmp filesystem can probably
also screw with your running processes as well. For example, attach a
debugger and have it execute
!fork() && execlp("xterm", "xterm", "-display", "somehost:0", NULL);
and get (i) a shell running with your uid, and (ii) full access to the
special inherited fd. The difference is even smaller on systems with a
/proc filesystem; why would it be harder to circumvent permissions on
/tmp/personal-dir/foo than on /proc/your-process/fd?
/Niels
