Yes. I am completely at a loss. The Linux kernel version I updated to is 2.6.15.3. After chmoding 666 on /dev/tty, I changed it back to 777 because it is definitely a directory. Evidence below:
[EMAIL PROTECTED]:/dev/tty# ls -l total 0 crw------- 1 root root 3, 10 2007-03-21 00:58 s crw------- 1 root root 3, 0 2007-03-21 00:58 s0 crw------- 1 root root 3, 1 2007-03-21 00:58 s1 crw------- 1 root root 3, 2 2007-03-21 00:58 s2 crw------- 1 root root 3, 3 2007-03-21 00:58 s3 crw------- 1 root root 3, 4 2007-03-21 00:58 s4 crw------- 1 root root 3, 5 2007-03-21 00:58 s5 crw------- 1 root root 3, 6 2007-03-21 00:58 s6 crw------- 1 root root 3, 7 2007-03-21 00:58 s7 crw------- 1 root root 3, 8 2007-03-21 00:58 s8 crw------- 1 root root 3, 9 2007-03-21 00:58 s9 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.
