Custom Query (1145 matches)

Reported by jmorzins, 15 years ago.

Hi,

When trying out a debathena machine today, I noticed that the behavior of ssh has changed.

On an Athena 9 computer, if I "ssh" to another kerberized system, ssh does not ask for my password. It uses my kerberos tickets, and I connect.

On the machine I tried today, ssh seemed not to use my kerberos tickets. I had to type a password in order to connect to the remote host.

For ssh to require passwords is a fairly visible behavior change, at least to the people who use ssh. If a lot of people use ssh, I anticipate getting a lot of questions about the change.

(I commented about my observations on zephyr today, and was told that this ssh change may have been a deliberate choice, but was asked to file a ticket in trac.)

Regards,

-Jacob Morzinski

Reported by jdreed, 15 years ago.

A desire has been expressed to change how zwgc behaves for remote logins. Specifically, there is a debate about whether or not it is desirable for zwgc to run when connecting to a Debathena machine with SSH and X11 forwarding. Some people expect this behavior and either like it or configure it to their needs, others find it intrusive and wish to disable it.

For the history surrounding this, see #137

Reported by geofft, 15 years ago.

There are a couple of problems with machines that don't have network access and try to do network login.

First, there's no clear error explaining what's wrong when the machine isn't connected and you try to log in. One possible solution to this is a PAM module that tries to access the network and displays a fatal message if it can't, although we'd have to be very sure it doesn't have any false positives. (For instance, if some but not all of the Kerberos servers go down, we shouldn't deny login.)

Second, if the machine goes offline, it's possible for an AFS access to time out and make the AFS client sad until "fs checks" is run. Other services like zhm can also become unhappy. Again, we could hack a PAM module to address this; there might be cleaner solutions. An Xsession.d script, for instance, is slightly cleaner.

aseering on testers@:

Hey,

The DebAthena computer adjacent to M12-182-4 (it doesn't have a label

and I can't log in to check) is currently sad. Its Ethernet cable was unplugged when I walked up to it. I plugged it back in, and tried to log in; the login hung while trying to render my applications bar. I killed X (ctrl-alt-bksp); the machine is now sitting at a text console.

mitchb's reply:

You didn't try rebooting it? If the network cable has been out for a length of time, a whole bunch of things on the machine are going to have noticed (among them, AFS, zhm, syslogd, aptitude, etc.), and while they may recover given time, assuming that the machine will immediately be fine upon reinserting the cable is generally not accurate.