Re: Future of kerberised telnet, login, rsh, ftp?

[Gémes Géza <geza@kzsdabas.sulinet.hu>]

Brian May írta:

>>>>>>"Andrew" == Andrew Bartlett <abartlet@samba.org> writes:
>>>>>>            
>>>>>>
>
>    Andrew> I note that recent security advisories for both
>    Andrew> distributions were in these 'utility' programs (telnet,
>    Andrew> ftpd etc) rather than in the core kerberos code.
>
>I don't use telnet, rsh, ftpd any more. I generally use ssh, sftp, etc
>instead. I feel safer using these tools, because I think security bugs
>will be found faster in ssh, as it gets more use, and hence more
>inspection, then the tools in Heimdal (not that openssh doesn't get
>its fair share of security bugs).
>
>There is also the pop server. It is the only server I know of that
>supports Kerberos, at least in Debian. However, I only know of one
>client in Debian that supports Kerberos (or so it claims[1]), a client
>I don't use myself, and I tend to use courier-imap anyway.
>
>I do think accessing mail via Kerberos would be a good idea, instead
>of entering a password each time... Not to mention being able to
>authenticate to web servers using Kerberos a Kerberos ticket already
>obtained at log in. Then again i am getting off topic.
>
>  
>
Just my 2c:
For a lot cleaner codebase this tools should be removed from the core 
distribution.
BTW:
Cyrus IMAP and POP servers support Kerberos login via GSSAPI via SASL. 
The biggest issue is with the fact that few clients are able of using it 
(Evolution claims support, Mozilla suite, or Thunderbird not).

Cheers

Geza

>Notes:
>[1] apt-cache show balsa
>
>
>    Andrew> Do these tools still have wide use?  Is there a plan to
>    Andrew> phase them out, or maintain them separately to the main
>    Andrew> kerberos distribution?
>
>I would personally like to see Kerberos support merged into the
>mainstream packages and removed from Heimdal.
>
>There is no good reason why we need separate {telnet,rsh,ftp} clients
>and servers in Heimdal when the functionality can be merged into the
>mainstream packages and used instead.
>
>However, I am not volunteering...
>  
>