For the sake of all who have been following this thread, and anyone who may experience this problem in the future, this appears to be an issue with the default udev.rules on slackware. Now, I am off to figure out what needs to be changed. Thanks to all who responded. Here are the helpful URLs which put me on the right track:
http://www.ussg.iu.edu/hypermail/linux/kernel/0408.2/0627.html http://www.ussg.iu.edu/hypermail/linux/kernel/0408.2/0628.html http://www.ussg.iu.edu/hypermail/linux/kernel/0408.2/0770.html http://www.ussg.iu.edu/hypermail/linux/kernel/0408.2/0771.html Bryan On Wed, 2006-04-19 at 08:11 -0400, Greg Wooledge wrote: > On Tue, Apr 18, 2006 at 09:58:24AM -0500, Christ, Bryan wrote: > > Most of the suggestions I have read say to chmod 666 /dev/tty, but > > my /dev/tty is a directory. > > That's bad. That's very, very bad. I'd suggest you get in touch with > one of the support forums (mailing lists, IRC channels, etc.) for your > operating system. > > > ssh [EMAIL PROTECTED] > > Permission denied, please try again. > > Permission denied, please try again. > > Permission denied (publickey,gssapi-with-mic,password). > > If you did indeed issue "chmod 666" on a directory, that might explain > part of the problem -- a directory which lacks the "execute" bit would > be untraversable. > > > debug1: read_passphrase: can't open /dev/tty: Is a directory > > debug3: packet_send2: adding 8 (len 51 padlen 5 extra_pad 64) > > debug2: we sent a password packet, wait for reply > > debug1: Authentications that can continue: > > publickey,gssapi-with-mic,password > > Permission denied, please try again. > > *nod* Whatever your Linux distribution has done, fixing it is probably > outside the scope of this mailing list. /dev/tty is supposed to be a > character device node. Shell scripts and other Unix programs have *always* > been able to count on "read foo < /dev/tty" working. If /dev/tty is a > directory, that will break a *lot* of stuff. > > I'm hesitant to suggest even something as simple as "man MAKEDEV", for > fear that any attempt to fix this snafu (without understanding the > primary cause) will just make it worse.
