Re: request for comments : slush
From: Nico Kadel-Garcia (nkadel_at_comcast.net)
Date: 02/23/04
- Next message: Per Hedeland: "Re: SSH: trying the simplest configuration with no success"
- Previous message: Chris Skelsey: "Re: SSH: trying the simplest configuration with no success"
- In reply to: Mark Borgerding: "Re: request for comments : slush"
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ] [ attachment ]
Date: Sun, 22 Feb 2004 19:40:37 -0500
"Mark Borgerding" <mborgerding@cinci.rr.com> wrote in message
news:40393C17.4070501@cinci.rr.com...
> Nico Kadel-Garcia wrote:
> > Given the
> > high session start-up costs of SSH, which your technique would seem to
also
> > have,
>
> Only the first slush client (from local host&user to remote host&user )
> incurs the same startup costs as ssh.
>
> That first slush client connects to the remote host via ssh and starts a
> slushd process, which listens on a port and generates 1000 keys. Slushd
> prints the port # and keys to stdout(thru ssh). Slushd forks off a
> daemon process and continues listening on that port (with an idle
> timeout).
>
> The first slush client, as well as the next 999, authenticate themselves
> by connecting a socket to the remote port and providing a one-time
> password, followed by the command to execute.
>
> The amortized cost per session is very low.
*HMMM*. OK, I see how you're doing this, and the overall bandwidth/CPU
benefits for a 1000 following connections. But what kind of service are you
running where either host-based access to a non-encrypted port is not
sufficient, but automated logins are usable?
> I am currently researching Kerberos to this end. As I learn more about
> it, I can better comment on how it would balance performance,
> simplicity, and security.
As an old compiler and installer of it from roughly 7 years back, I can
vouch that most clever hacks against it were thought of many years ago and
dealt with then. Setting it up is a bit of a pain, but it's really quite
robust for centralized user authentication and key management.
> In favor of slush & one-time keys passed thru ssh tunnel:
> * It can use any auth method that ssh can, including kerberos.
> * In PK or password mode; ssh, and therefore slush, does not require any
> central server.
> * It can be installed by an unprivileged user in their home directories.
>
> In favor of Kerberos:
> * The security of Kerberos is well scrutinized. For security, known
> limitations are cartainly better than unknown ones.
* It's integrated into publicly available versions of telnet, rsh, ftp, and
AFS, so just about every remote access tool you might want to use becomes
available for that start-up cost.
* It's integrated into or publicly available for all major operating systems
written in the last 5 years or so.
- Next message: Per Hedeland: "Re: SSH: trying the simplest configuration with no success"
- Previous message: Chris Skelsey: "Re: SSH: trying the simplest configuration with no success"
- In reply to: Mark Borgerding: "Re: request for comments : slush"
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ] [ attachment ]
Relevant Pages
|