[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: Future of kerberised telnet, login, rsh, ftp?
>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.