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

[Ken Hornstein <kenh@cmf.nrl.navy.mil>]

>Thinking back, I perhaps didn't make this clear. Both client and server 
>error messages should be readily available on their respective machines. 
>Server side GSSAPI errors currently go into the debug logs - you should 
>be able to see these by running the server with the '-d' option. It's 
>arguable that these should go into the system logs, although when they 
>did, people complained about the verbosity.

I wasn't aware of that, but it wouldn't have helped me in this case; the
systems in question weren't under our control, and it was easier to tell
the person to use a non-ssh client that to get the admin involved.  I know
this sounds weird, but the systems were in a timezone relatively far from
mine and the admin was hard to reach; we had to do a lot of coordination
to get ahold of each other, and it was a problem that had to be solved
within a relatively short time period.

>Errors on the client are either sent to stdout, or will be visible when 
>the client is run with the '-v' option.

We _did_ try that, but nothing useful came back.

>The issue is with transmitting server errors back to the client for 
>display. As well as being a religous issue (how much information should 
>a server provide to the client about why their authentication failed), 
>doing so is also complicated by the internal architecture of OpenSSH.

Right, this is what I was thinking of.  The majority of problems that I
see involved errors from processing the AP_REQ; _those_ are the
important ones to get back to the client.  All of those "obsolete"
Kerberos programs send back any errors encountered on the server, which
is invaluable for debugging.

--Ken