Mailing List Archive

On Sat, 20 May 2000, Simon Wilkinson wrote:

> I've taken the original patches and updated then to the OpenSSH portable
> 2.1.0 release, replaced the calls to Heimdal specific routines, so it
> builds with the MIT libraries as well, and bug fixed a number of problems
> with the code.

be very careful here.

i've not looked at heimdal, but the MIT krb5 code has historically had
very bad interactions with the ssh-1.2.2x implementation, such that an
unprivileged user could manually set their KRB5CCNAME environment variable
to use someone else's ticket file, and the setuid root ssh client would
happily comply (which is why tatu disabled krb5 support in the official
distribution). let me know if this still works? :-)

the KTH krb4 library used to provide krb4 support for ssh/OpenSSH never
had this problem, as they make an explicit check for the setuid root case.

we also need to find a way to make krb4 and krb5 support interoperate. in
my original krb4 patch, i added version information to the ticket
encoding, which glenn machin didn't use in his krb5 port to distinguish
Kerberos types. we may be able to support both versions with a simple
failover instead.

-d.

---
http://www.monkey.org/~dugsong/

> i've not looked at heimdal, but the MIT krb5 code has historically had
> very bad interactions with the ssh-1.2.2x implementation, such that an
> unprivileged user could manually set their KRB5CCNAME environment variable
> to use someone else's ticket file, and the setuid root ssh client would
> happily comply (which is why tatu disabled krb5 support in the official
> distribution). let me know if this still works? :-)

Yup. You need to check that the ticket file is owned by and readable by
the user who invoked ssh, not just that you can access it. I'm using a
check on the ticket file before I pass it to the krb5 libraries.

> we also need to find a way to make krb4 and krb5 support interoperate. in
> my original krb4 patch, i added version information to the ticket
> encoding, which glenn machin didn't use in his krb5 port to distinguish
> Kerberos types. we may be able to support both versions with a simple
> failover instead.

Yes. The code that I've built from appears to add two new message
types -

#define SSH_AUTH_KRB5 29
#define SSH_PASS_KRB5_TGT 30

which it uses for Kerberos 5 support. In its original state ticket granting
didn't work. I've now reworked this so that it works, but only if the TGT
message comes before the AUTH one. This is all rather nasty at the moment,
but it works.

Once I've got the simple case going, it would be nice to look at collapsing
back into a form that doesn't require protocol extensions like these. At
present, I can authenticate a session using credential passing, and forward
credentials. I'd quite like to add support for destroying forwarded
credentials at log out as well. I'll probably tidy up and post the patches
for review tomorrow.

Cheers,

Simon.

On Sat, 20 May 2000, Simon Wilkinson wrote:

> At present, I can authenticate a session using credential passing, and
> forward credentials. I'd quite like to add support for destroying
> forwarded credentials at log out as well. I'll probably tidy up and
> post the patches for review tomorrow.

Are you also adding support for Kerberos to password authentication?

--
Mike Fisk, RADIANT Team, Network Engineering Group, Los Alamos National Lab
See http://home.lanl.gov/mfisk/ for contact information

> Are you also adding support for Kerberos to password authentication?

Not yet. We currently use PAM to do this (as it means we can use a
common ticket granting mechanism across all of our login
authentication services). The patches that I'm working from do have a
krb5_auth_passwd routine, but this isn't linked in to the main
authentication routines anywhere.

Once I've got the credentials passing and ticket granting stuff down to
my, and those who get to add it to the release's, satisfaction, I'll look
into adding this as well.

Cheers,

Simon.

Yo All!

I just installed Openssh 2.1.0p2 on a Slackware 7.0 host (libc 2.1.2,
kernel 2.2.13).

Outbound ssh, sftp, and scp (v1 and v2) work OK to itself and to ssh 1.2.27
and 2.0.13.

Inbound ssh from ssh 1.2.27 and 2.0.13 also seem OK.

Inbound scp from 1.2.27 seems OK.

My problem is inbound scp from 2.0.13
scp2 user@openssh:/file .
hangs forever. See below for the opensshd debug output. Seems like
a problem with sftp. The compiled in path on the openssh side
is OK.

Any ideas?

RGDS
GARY
---------------------------------------------------------------------------
Gary E. Miller Rellim 20340 Empire Ave, Suite E-3, Bend, OR 97701
gem@rellim.com Tel:+1(541)382-8588 Fax: +1(541)382-8676


debug: sshd version OpenSSH-2.1
debug: Seeding random number generator
debug: read DSA private key done
debug: Seeding random number generator
debug: Bind to port 22 on 0.0.0.0.
Server listening on 0.0.0.0 port 22.
Generating 768 bit RSA key.
debug: Seeding random number generator
debug: Seeding random number generator
RSA key generation complete.
debug: Server will not fork when running in debugging mode.
Connection from 208.139.26.74 port 2420
debug: Client protocol version 1.99; client software version 2.0.13 (non-commercial)
datafellows: 2.0.13 (non-commercial)
Enabling compatibility mode for protocol 2.0
debug: Local version string SSH-1.99-OpenSSH-2.1
debug: Sending KEX init.
debug: done
debug: got kexinit string: diffie-hellman-group1-sha1
debug: got kexinit string: ssh-dss
debug: got kexinit string: 3des-cbc,blowfish-cbc,twofish-cbc,arcfour
debug: got kexinit string: 3des-cbc,blowfish-cbc,twofish-cbc,arcfour
debug: got kexinit string: hmac-md5,md5-8,none
debug: got kexinit string: hmac-md5,md5-8,none
debug: got kexinit string: none,zlib
debug: got kexinit string: none,zlib
debug: got kexinit string:
debug: got kexinit string:
debug: first kex follow == 1
debug: reserved == 0
debug: done read kexinit
debug: kex: client->server 3des-cbc hmac-md5 none
debug: kex: server->client 3des-cbc hmac-md5 none
debug: Wait SSH2_MSG_KEXDH_INIT.
debug: bits set: 543/1024
debug: bits set: 499/1024
debug: sig size 20 20
debug: datafellows
debug: send SSH2_MSG_NEWKEYS.
debug: done: send SSH2_MSG_NEWKEYS.
debug: Wait SSH2_MSG_NEWKEYS.
debug: GOT SSH2_MSG_NEWKEYS.
debug: done: KEX2.
debug: userauth-request for user gem service ssh-connection method none
Failed none for gem from 208.139.26.74 port 2420 ssh2
debug: userauth-request for user gem service ssh-connection method password
Accepted password for gem from 208.139.26.74 port 2420 ssh2
debug: Entering interactive session for SSH2.
debug: server_init_dispatch_20
debug: channel_input_open: ctype session rchan 0 win 100000 max 8192
debug: open session
debug: channel 0: new [server-session]
debug: session_new: init
debug: session_new: session 0
debug: session_open: channel 0
debug: session_open: session 0: link with channel 0
debug: confirm session
debug: callback start
debug: session_by_channel: session 0 channel 0
debug: session_input_channel_req: session 0 channel 0 request subsystem reply 1
subsystem request for sftp
debug: callback done
debug: channel 0: rcvd close
Connection closed by remote host.
debug: Calling cleanup 0x8057540(0x0)
debug: Calling cleanup 0x805c49c(0x0)

On Sun, 21 May 2000, Simon Wilkinson wrote:

> > Are you also adding support for Kerberos to password authentication?
>
> Not yet. We currently use PAM to do this (as it means we can use a
> common ticket granting mechanism across all of our login
> authentication services). The patches that I'm working from do have a
> krb5_auth_passwd routine, but this isn't linked in to the main
> authentication routines anywhere.
>
> Once I've got the credentials passing and ticket granting stuff down to
> my, and those who get to add it to the release's, satisfaction, I'll look
> into adding this as well.

I assume that PAM still isn't available on some older platforms. Even
when it is, it would be easier for our in-house distributions of SSH if we
could have this capability statically linked in.

Thanks again.
Sorry I can't help with the implementation from the US,
--
Mike Fisk, RADIANT Team, Network Engineering Group, Los Alamos National Lab
See http://home.lanl.gov/mfisk/ for contact information

> > Once I've got the credentials passing and ticket granting stuff down to
> > my, and those who get to add it to the release's, satisfaction, I'll look
> > into adding this as well.
>
> I assume that PAM still isn't available on some older platforms. Even
> when it is, it would be easier for our in-house distributions of SSH if we
> could have this capability statically linked in.

Now available from
http://www.dcs.ed.ac.uk/home/sxw/openssh/openssh-2.1.0-kerberosV.patch
is a patch which implements Kerberos 5 credential passing, ticket granting
and password authentication. I've built this, and tested it, with MIT
Kerberos, I believe that it should work with Heimdal, but I haven't (yet)
had a chance to test it.

This is probably _not_ compatible with some other implementations, in
particular those which overload the existing kerberos message types to
carry Kerberos 5 credentials (this patch currently uses a new set of
message types). I'd like to merge this code with the Kerberos 4 code
so that both can coexist on the same pair of types, if anyone's interested
in collaborating on this.

Please take a look and let me know what you think. I'd especially welcome
feedback on the ticket file checking code.

Cheers,

Simon.