Future of kerberised telnet, login, rsh, ftp?
kenh at cmf.nrl.navy.mil
Wed Jul 6 11:45:51 EDT 2005
>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.
More information about the krbdev