[prev in list] [next in list] [prev in thread] [next in thread] 

List:       secure-shell
Subject:    Re: Permission denied  - check you console
From:       "Christ, Bryan" <bryan.christ () hp ! com>
Date:       2006-04-20 16:45:50
Message-ID: 1145551550.18140.13.camel () tuxdev ! americas ! hpqcorp ! net
[Download RAW message or body]

Mike,

Here is the solution.  Apparently this is a particular problem with
slackware 10.0...
http://www.pocketace.net/pocketace.php?pg=articles&ar=slackware)

(excerpt)
"The Slackware udev.rules included with Slackware 10 needs to be altered
for the man, less and ssh commands to work properly. To fix this problem
you need to edit the /etc/udev/rules.d/udev.rules file. The change is in
the pty devices section, you need to change
KERNEL="tty[p-za-e][0-9a-f]*", NAME="tty/s%n", SYMLINK="%k"  to read
KERNEL="tty[p-za-e][0-9a-f]*", NAME="pty/s%n", SYMLINK="%k".  Thats it
just change the t to a p, and everything should work."

Bryan

On Thu, 2006-04-20 at 09:32 -0700, Mike Ireton wrote:
> Bryan,
> 
>     This problem also drove me absolutely bonkers once also, and what 
> the deal was had to do with the fact that the 'console' device was 
> invalid. There is some interaction which I still to this day don't fully 
> understand, between ssh and /dev/console. This stuff the list is 
> suggesting regarding /dev/tty* is in the same vein but only applies if 
> you're logged in thru ssh already, and I suspect you're on your vga 
> console.
> 
>     Would you humor me and do the following?
>    
>     ls -l /dev/console
>     cat /proc/cmdline
>     uname -a
> 
>     Also, your ttys all do look funky as the list noted. Have you tred:
> 
>     cd /dev
>     ./MAKEDEV tty
> 
>     (MAKEDEV is the standard script which populates /dev with device 
> entries)
> 
> 
>      Also, is devfsd running perchance?
> 
> Mike-
> 
> 
> 
> 
> Christ, Bryan wrote:
> 
> >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@192.168.0.103
> >>>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.
> >>    
> >>
> 
[prev in list] [next in list] [prev in thread] [next in thread]