Ethical Hacking Learn to find vulnerabilities before the bad guys do! Gain real world hands on hacking experience in our state of the art hacking lab. Course designed and taught by expert instructors with years of penetration testing experience. 12 student maximum in every class. Certification attempt included in every package. | Computer Forensics Training at InfoSec Institute Gain the in-demand skills of a certified computer examiner, learn to recover trace data left behind by fraud, theft, and cybercrime perpetrators. Discover the source of computer crime and abuse at your organization so that it never happens again. All of our class sizes are guaranteed to be 12 students or less to facilitate one-on-one interaction with one of our expert instructors. |

| Subject: | Re: Permission denied, please try again |
|---|---|
| Date: | Wed, 19 Apr 2006 11:01:58 -0500 |
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 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 Thread] | Current Thread | [Next in Thread> |
|---|---|---|
| ||
| Previous by Date: | Re: X11 tuneling: a hard to fix problem, ilaiy |
|---|---|
| Next by Date: | RE: X11 tuneling: a hard to fix problem, Patrick Morris |
| Previous by Thread: | Re: Permission denied - check you console, Christ, Bryan |
| Next by Thread: | New site about security conferences : www.security-briefings.com, newslist@security-briefings.com |
| Indexes: | [Date] [Thread] [Top] [All Lists] |