[19249] in Kerberos
ssh to/from unix and microsoft platforms
daemon@ATHENA.MIT.EDU (Cesar Garcia)
Wed May 14 19:19:00 2003
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Message-ID: <16066.52869.88236.944539@limus.ms.com>
Date: Wed, 14 May 2003 19:17:25 -0400 (EDT)
From: Cesar Garcia <Cesar.Garcia@morganstanley.com>
To: kerberos@mit.edu
Errors-To: kerberos-bounces@mit.edu
I am planning to investigate solutions for kerberos-enabled ssh
for both unix/linux platforms and microsoft platforms. This includes
ssh clients and ssh daemons for both sets of platforms.
Before spending too much time searching, I figured I would probe folks
on this mailing list for pointers to implementations that are out
there as well as experiences they may have with these implementations.
We have a fairly good grasp of (and experience with) what is available
for unix/linux, and would like to explore solutions (which may be
different ones) for microsoft platforms.
On unix/linux, we are already experimenting with openssh with simon
wilkinson's kerberos/gssapi patch.
What I'm more interested in (information-wise) is a solutions for ssh
clients and daemons that run on windows.
I've seen (but I'm not familiar with)
- openssh on cygwin (client and daemon)
- certified security solutions for putty with kerberos/gssapi (client
only, I believe)
Requirements are not yet refined, my interest is mostly exploratory at
the moment. Of course, interoperability between unix/linux and
microsoft is key. We would also like to have consistency in usage
semantics (particularly with the client) This would make use of an ssh
client from say a cygwin environment consistent our use on unix/linux,
where scripts may be shared (although, we can probably write portable
scripts without too much trouble, I would rather not have to do this).
Cygwin is very likely going to be part of our windows platform, so
anything that depends on Cygwin is probably OK. We would expect to run
ssh in both interactive and non-interactive modes, so a GUI only
solution (for clients) would be too prohibitive.
Also, we currently maintain separate (two) kerberos realms for the
unix/linux platforms and the microsoft platform, so it would be
necessary for any solution we adopt to work in a kerberos cross-realm
environment (there may be issues with mapping principals in a foreign
realm to local unix accounts, but I think we can handle this).
Any information/experiences on this subject would be greatly appreciated.
Please - no vendor calls for now :)
________________________________________________
Kerberos mailing list Kerberos@mit.edu
https://mailman.mit.edu/mailman/listinfo/kerberos
