Re: Permission denied, please try again



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:

root@gateway:/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 bryanc@xxxxxxxxxxxxx
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.