SBNelson@thermeon.com wrote:
>
> > I'd actually be very interested in this. Have you written any code,
> > would you like some help?
> >
> Nothing written yet; I'm just in the thinking stage at the moment --
> I wanted to be sure that I was thinking straight. And sure, I'd love some
> help as this would be my first pam module.
>
> I wonder which telnetd source code to start with; I have two: The
> one that RedHat ships, and the other is the one that Tom Wu ships with his
> SRP. I did a quick diff and it appears that the source is quite different.
Apologies in advance for tooting my own horn here.
A good question might be why there are two codebases to begin with. If
you sit the two telnet's down next to each other, you'll find that SRP
Telnet is light-years ahead in terms of functionality. For example, try
the following commands in a Telnet session with SRP Telnet:
telnet> auth status
Authentication enabled
SRP: enabled
KERBEROS_V5: enabled
KERBEROS_V4: enabled
telnet> encrypt enable ?
Usage: encrypt enable <type> [input|output]
Valid encryption types:
DES3_CFB64 (3)
DES3_OFB64 (4)
CAST128_CFB64 (10)
CAST128_OFB64 (11)
DES_CFB64 (1)
DES_OFB64 (2)
CAST5_40_CFB64 (8)
CAST5_40_OFB64 (9)
telnet> tls status
TLS: enabled
TLSv1 session is active
TLS cipher: ADH-DES-CBC3-SHA (168 bits)
TLS using authenticated DH key exchange
If you try the same thing with stock RH Telnet, you get:
telnet.old> auth status
?Invalid command
telnet.old> encrypt enable ?
?Invalid command
telnet.old> tls status
?Invalid command
As of version 1.7.2 of SRP Telnet, which was recently released, SRP
Telnet supports all of the Telnet Encryption RFCs, along with several of
the more popular authentication methods, plus START_TLS Telnet session
security and X11 session forwarding. SRP Telnet also integrates with
OpenSSL, and has configurable support for other crypto libraries. The
code base is more mature, current, and portable, because it has received
a lot of attention over the past few years from developers worldwide.
The idea of closer coupling between telnetd and PAM is a good one; I
plan to update telnetd so that is has the option of handling the
login/password dialogue with the user on its own, without requiring
/bin/login to perform this operation. Your suggestion would dovetail
nicely with this enhancement.
Tom
> > SBNelson@thermeon.com wrote:
> > >
> > > I've been thinking about modifying telnetd to use PAM to control which
> > > authentication methods telnetd should offer the client. This is to get
> > > around the fact that the telnet protocol says that the server supplies
> > the
> > > list, but the client gets to choose one from the list. I'm also
> > thinking
> > > about doing the same for FTP.
> > >
> > > Example:
> > > auth required
> > /lib/security/pam_telnetd_auth.so
> > > choices=srp,krb5,none
> > > auth sufficient /lib/security/pam_telnetd_auth.so
> > > used=srp,krb5
> > > auth required /lib/security/pam_unix.so ...
> > >
> > > Can anyone see problems in what I would like to do?
> >
>
> _______________________________________________
>
> Pam-list@redhat.com
> https://listman.redhat.com/mailman/listinfo/pam-list
--
Tom Wu
Principal Software Engineer
Arcot Systems
(408) 969-6124
"The Borg? Sounds Swedish..."
