Need Help Setting Up Keys For Users and Machines (Using Solaris NIS)
Hello; OK, this may make more than a few of you cringe, but here goes: I am having difficulties setting up ssh (ossh4.3p2 with PAM-enabled - NIS -Solaris8/Sparc) to authenticate and allow users passwordless entry based solely on one or more of the following: 1. User is a member of an NIS 'group', say group1, and this group has been setup within sshd_config using "AllowGroup group1". 2. User and/or host is a valid member of NIS 'netgroup', whereby the client host has been defined as being a part of netgroup named netgroup1 or the user from 'any' machine as being a part of netgroup netgroup2. In this case I am using "AllowGroup netgroup1 netgroup2". Aside from creating a public key for each machine/user combination and placing this information within an authorized_keys file, how else can I do this? Using pass-phrases is not an option, I must be able to allow users free access, of course only after already gaining access to one machine in the first place. All of my machines are within a trusted environment :-) Many thanks in advance, .vp
Re: Permission denied - check you console
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: > > > >[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. > >> > >> >
RE: SCO OpenServer 5.0.5 authenticates locked accounts
This older version of SCO doesn't support PAM. However, I was able to finally get this working. Basically the issue was that the configure.ac file had defined DISABLE_SHADOW, but we are indeed using shadow passwords. I caught this early on but if I removed this definition I could never get ssh to compile due to errors in xcrypt.c. Finally, I added the following two lines to the top of auth.c, leaving the DISABLE_SHADOW definition in place in configure.ac. #define USE_SHADOW #define LOCKED_PASSWD_PREFIX "*LK*" Locked accounts are now getting receiving permission denied which is expected. -Original Message- From: Venkatachalam, Saravanakumar [mailto:[EMAIL PROTECTED] Sent: Wednesday, April 19, 2006 12:58 AM To: Powell, Scott Cc: secureshell@securityfocus.com Subject: Re: SCO OpenServer 5.0.5 authenticates locked accounts Scott, How about using PAM ? I'm not sure if SCO OpenServer 5.0.5 has PAM support. regards, saravan Powell, Scott wrote: > I have noticed that SSH compiled for SCO OpenServer 5.0.5 is > authenticating locked accounts. I have tried re-compiling the latest > portable version, 4.3p2, as well as some older versions. I also tried a > Skunkware version supplied by SCO. All of these are authenticating > locked accounts. I even messed around in configure.ac and added > AC_DEFINE(LOCKED_PASSWD_STRING, "*LK*") to the *-*-sco3.2v5* definitions > (locked accounts have a *LK* in the shadow file as a prefix to the > encrypted password hash. > > Does anyone have any recommendations or workarounds? > > Thanks, > Scott > >
Re: X11 tuneling: a hard to fix problem
No, don't use xhost + The entire point of using ssh for X11 forwarding is that the ssh connection comes from a local process - you don't have to accept outside X11 connections. xhost + is used specifically for accepting X11 connections that _don't_ come from a local process (e.g not over your SSH session). If for some reason the X11 connections are failing to be forwarded over the SSH tunnel, xhost + will fix X11 functionally, but it will do it by bypassing the entire SSH tunnel. Mark On 4/18/06, Jason Mitchell <[EMAIL PROTECTED]> wrote: > Hi Nader, > > on the host you're ssh'ing from try issuing "xhost +" prior to ssh'ing, eg: > > yourdesktop # xhost + > yourdesktop # ssh -X [EMAIL PROTECTED] > > Regards, > > Jason > > Nader Amadeu wrote: > > >Hi all, I've googled for more than a week trying to > >fix this SSH X11 tuneling problem. > >I appreciate some help and thank you in advance. > > > >I have a remote Solaris 9 with the following options in /etc/ssh/sshd_config: > >X11Forwarding yes > >X11DisplayOffset 10 > >ForwardX11Trusted yes > > > >Then I ssh it from my local desktop: (only most important lines here) > > > >[localdesktop]% ssh -vvv -XY [EMAIL PROTECTED] > >OpenSSH_4.2p1 FreeBSD-20050903, OpenSSL 0.9.7e-p1 25 Oct 2004 > >debug1: Reading configuration data /etc/ssh/ssh_config > >debug2: ssh_connect: needpriv 0 > >debug1: Connecting to remoteserver [ip.address.here] port 22. > >debug1: Connection established. > >debug1: Remote protocol version 1.99, remote software version OpenSSH_4.2 > >debug1: match: OpenSSH_4.2 pat OpenSSH* > >debug1: Enabling compatibility mode for protocol 2.0 > >debug1: Local version string SSH-2.0-OpenSSH_4.2p1 FreeBSD-20050903 > >debug2: fd 3 setting O_NONBLOCK > >debug1: Authentication succeeded (publickey). > >debug1: channel 0: new [client-session] > >debug3: ssh_session2_open: channel_new: 0 > >debug2: channel 0: send open > >debug1: Entering interactive session. > >debug2: callback start > >debug2: x11_get_proto: /usr/X11R6/bin/xauth list :0.0 . 2>/dev/null > >debug1: Requesting X11 forwarding with authentication spoofing. > >debug2: channel 0: request x11-req confirm 0 > >debug2: client_session2_setup: id 0 > >debug2: channel 0: request pty-req confirm 0 > >debug2: channel 0: request shell confirm 0 > >debug2: fd 3 setting TCP_NODELAY > >debug2: callback done > >debug2: channel 0: open confirm rwindow 0 rmax 32768 > >debug2: channel 0: rcvd adjust 131072 > > > >Now in the remoteserver: > > > >[EMAIL PROTECTED] % echo $DISPLAY > > DISPLAY: Undefined variable > >[EMAIL PROTECTED] % netstat -a > > remoteserver.sshlocaldesktop.51899 66608 47 66608 0 > > ESTABLISHED > > > >Even if i setenv DISPLAY to localhost:10, 11, 12 ... it does not work. > >And from this netstat output I cannot find the X11 tuneling channel. > >In another attempt below I have the following different debug messages: > > > > > >[localdesktop]% ssh -vvv -o "ForwardX11Trusted no" [EMAIL PROTECTED] > >debug2: x11_get_proto: /usr/X11R6/bin/xauth -f /tmp/ssh-9xszkw26hB/xauthfile > >generate :0.0 MIT-MAGIC-COOKIE-1 untrusted timeout 1200 2>/dev/null > >debug2: x11_get_proto: /usr/X11R6/bin/xauth -f /tmp/ssh-9xszkw26hB/xauthfile > >list :0.0 . 2>/dev/null > >debug1: Requesting X11 forwarding with authentication spoofing. > >debug2: channel 0: request x11-req confirm 0 > > > > > >and again DISPLAY is an undefined variable. > >Could anyone help me to get this X11 tunelling work? > >Thanks all very much, > >nader > > > > > > > > > > > >
FW: v4.3 VPN Tunneling for windows clients?
I have a working VPN tunnel between Linux boxes working great! I am tunneling between the networks using the TUN interfaces which is quick, simple, secure, and easy. However, I have a need to use this for windows laptops on the go. This means that a Linux box running as a gateway for the client is not a solution. I like the ease and convenience of the setup with OpenSSH vs. OpenVPN. Lastly, it doesn't appear that their is a solution yet using cygwin for this setup. What solution is their for windows clients? Thanks to all of those that have contributed to this awesome project! -JGR
Re: openssh: Limiting bandwidth on ssh (stdin-to-dd)
Mark Holden wrote: Thanks everyone for the help! I will definitely check all of these out. I've started with trickle and have successfully limited the bandwidth in the data transfer from the local machine to the remote backup server using the command as given by Igor (limiting, for now, at 5 MB/sec). tar -cf - ./test_dir | trickle -s -d 5000 -u 5000 ssh [EMAIL PROTECTED] dd of=test_dir.tar Now I'm trying to go the other way (restoring at 5 MB/sec), using: ssh [EMAIL PROTECTED] dd if=test_dir.tar | trickle -s -d 5000 -u 5000 tar -P -xf - In this second one, trickle doesn't seem to have any effect. The speed is still the raw speed (without trickle) of 10 MB/sec. Do I have some error in the command string? Hello again... The command string is wrong because you are applying trickle to the tar command... You must do: trickle -s -d 5000 -u 5000 ssh [EMAIL PROTECTED] dd if=test_dir.tar | tar -P -xf - So that trickle runs the ssh command... Thanks again, Mark -Original Message- From: Igor Hjelmstrom Vinhas Ribeiro [mailto:[EMAIL PROTECTED] Sent: Monday, April 17, 2006 2:22 PM To: Holden, Mark [RICH1:B670:EXCH] Cc: secureshell@securityfocus.com Subject: Re: openssh: Limiting bandwidth on ssh (stdin-to-dd) Hello! Mark Holden wrote: I'm looking at using "ssh" from the openssh package, to perform secure backups of large directories from a local server to a remote server as in the following command executed on the local server. tar -cf - ./test_dir | ssh [EMAIL PROTECTED] dd of=test_dir.tar Ie., I don't want to first create the tar file on the local system then use scp to copy it off, as there may not be enough disk storage on the local system to create the tar file. However, I cannot seem to find any way, for the above style of transfer using ssh, to do something like the "-l" option of scp to limit the amount of bandwidth used during the transfer. Does anybody know of a way? You could use trickle. From the homepage at http://monkey.org/~marius/pages/?page=trickle "trickle is a portable lightweight userspace bandwidth shaper. It can run in collaborative mode (together with trickled) or in stand alone mode." To limit the down bandwidth to 20 kbytes/sec and the upload to 10 kbytes/sec you could do something like: tar -cf - ./test_dir | trickle -d 20 -u 10 ssh [EMAIL PROTECTED] dd of=test_dir.tar Thanks, Mark Regards, Igor.
Re: X11 tuneling: a hard to fix problem
Hi François, yes i have the options below in my /etc/ssh/sshd_config AllowTcpForwarding yes GatewayPorts yes I ran out of ideas where could be the problem... Thanks anyway and i still apreciate some tips. I dont want to use xhost because of security problems. nader > You need to also have this line in the sshd_config: > AllowTcpForwarding yes > > François > > -Nader Amadeu <[EMAIL PROTECTED]> wrote: - > > I have a remote Solaris 9 with the following options in > /etc/ssh/sshd_config: > X11Forwarding yes > X11DisplayOffset 10 > ForwardX11Trusted yes > > Then I ssh it from my local desktop: (only most important lines here) > > [localdesktop]% ssh -vvv -XY [EMAIL PROTECTED] > OpenSSH_4.2p1 FreeBSD-20050903, OpenSSL 0.9.7e-p1 25 Oct 2004 > debug1: Reading configuration data /etc/ssh/ssh_config > debug2: ssh_connect: needpriv 0 > debug1: Connecting to remoteserver [ip.address.here] port 22. > debug1: Connection established. > debug1: Remote protocol version 1.99, remote software version OpenSSH_4.2 > debug1: match: OpenSSH_4.2 pat OpenSSH* > debug1: Enabling compatibility mode for protocol 2.0 > debug1: Local version string SSH-2.0-OpenSSH_4.2p1 FreeBSD-20050903 > debug2: fd 3 setting O_NONBLOCK > debug1: Authentication succeeded (publickey). > debug1: channel 0: new [client-session] > debug3: ssh_session2_open: channel_new: 0 > debug2: channel 0: send open > debug1: Entering interactive session. > debug2: callback start > debug2: x11_get_proto: /usr/X11R6/bin/xauth list :0.0 . 2>/dev/null > debug1: Requesting X11 forwarding with authentication spoofing. > debug2: channel 0: request x11-req confirm 0 > debug2: client_session2_setup: id 0 > debug2: channel 0: request pty-req confirm 0 > debug2: channel 0: request shell confirm 0 > debug2: fd 3 setting TCP_NODELAY > debug2: callback done > debug2: channel 0: open confirm rwindow 0 rmax 32768 > debug2: channel 0: rcvd adjust 131072 > > Now in the remoteserver: > > [EMAIL PROTECTED] % echo $DISPLAY > DISPLAY: Undefined variable > [EMAIL PROTECTED] % netstat -a > remoteserver.sshlocaldesktop.51899 66608 47 66608 0 > ESTABLISHED > > Even if i setenv DISPLAY to localhost:10, 11, 12 ... it does not work. > And from this netstat output I cannot find the X11 tuneling channel. > In another attempt below I have the following different debug messages: > > > [localdesktop]% ssh -vvv -o "ForwardX11Trusted no" [EMAIL PROTECTED] > debug2: x11_get_proto: /usr/X11R6/bin/xauth -f > /tmp/ssh-9xszkw26hB/xauthfile generate :0.0 MIT-MAGIC-COOKIE-1 untrusted > timeout 1200 2>/dev/null > debug2: x11_get_proto: /usr/X11R6/bin/xauth -f > /tmp/ssh-9xszkw26hB/xauthfile list :0.0 . 2>/dev/null > debug1: Requesting X11 forwarding with authentication spoofing. > debug2: channel 0: request x11-req confirm 0 > > > and again DISPLAY is an undefined variable. > Could anyone help me to get this X11 tunelling work? > Thanks all very much,
RE: X11 tuneling: a hard to fix problem
Let me be the first (of probably many) to say this... Don't. This opens up a gaping security hole, and won't help one iota with SSH tunneling. -Original Message- From: Jason Mitchell [mailto:[EMAIL PROTECTED] Sent: Tuesday, April 18, 2006 5:20 PM To: [EMAIL PROTECTED] Cc: secureshell@securityfocus.com Subject: Re: X11 tuneling: a hard to fix problem Hi Nader, on the host you're ssh'ing from try issuing "xhost +" prior to ssh'ing, eg: yourdesktop # xhost + yourdesktop # ssh -X [EMAIL PROTECTED]
Re: Permission denied, please try again
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.
Re: X11 tuneling: a hard to fix problem
Use xhost +;ssh -l once you are done use xhost -; ./thanks ilaiy On 4/18/06, Nader Amadeu <[EMAIL PROTECTED]> wrote: > Hi all, I've googled for more than a week trying to > fix this SSH X11 tuneling problem. > I appreciate some help and thank you in advance. > > I have a remote Solaris 9 with the following options in /etc/ssh/sshd_config: > X11Forwarding yes > X11DisplayOffset 10 > ForwardX11Trusted yes > > Then I ssh it from my local desktop: (only most important lines here) > > [localdesktop]% ssh -vvv -XY [EMAIL PROTECTED] > OpenSSH_4.2p1 FreeBSD-20050903, OpenSSL 0.9.7e-p1 25 Oct 2004 > debug1: Reading configuration data /etc/ssh/ssh_config > debug2: ssh_connect: needpriv 0 > debug1: Connecting to remoteserver [ip.address.here] port 22. > debug1: Connection established. > debug1: Remote protocol version 1.99, remote software version OpenSSH_4.2 > debug1: match: OpenSSH_4.2 pat OpenSSH* > debug1: Enabling compatibility mode for protocol 2.0 > debug1: Local version string SSH-2.0-OpenSSH_4.2p1 FreeBSD-20050903 > debug2: fd 3 setting O_NONBLOCK > debug1: Authentication succeeded (publickey). > debug1: channel 0: new [client-session] > debug3: ssh_session2_open: channel_new: 0 > debug2: channel 0: send open > debug1: Entering interactive session. > debug2: callback start > debug2: x11_get_proto: /usr/X11R6/bin/xauth list :0.0 . 2>/dev/null > debug1: Requesting X11 forwarding with authentication spoofing. > debug2: channel 0: request x11-req confirm 0 > debug2: client_session2_setup: id 0 > debug2: channel 0: request pty-req confirm 0 > debug2: channel 0: request shell confirm 0 > debug2: fd 3 setting TCP_NODELAY > debug2: callback done > debug2: channel 0: open confirm rwindow 0 rmax 32768 > debug2: channel 0: rcvd adjust 131072 > > Now in the remoteserver: > > [EMAIL PROTECTED] % echo $DISPLAY > DISPLAY: Undefined variable > [EMAIL PROTECTED] % netstat -a > remoteserver.sshlocaldesktop.51899 66608 47 66608 0 > ESTABLISHED > > Even if i setenv DISPLAY to localhost:10, 11, 12 ... it does not work. > And from this netstat output I cannot find the X11 tuneling channel. > In another attempt below I have the following different debug messages: > > > [localdesktop]% ssh -vvv -o "ForwardX11Trusted no" [EMAIL PROTECTED] > debug2: x11_get_proto: /usr/X11R6/bin/xauth -f /tmp/ssh-9xszkw26hB/xauthfile > generate :0.0 MIT-MAGIC-COOKIE-1 untrusted timeout 1200 2>/dev/null > debug2: x11_get_proto: /usr/X11R6/bin/xauth -f /tmp/ssh-9xszkw26hB/xauthfile > list :0.0 . 2>/dev/null > debug1: Requesting X11 forwarding with authentication spoofing. > debug2: channel 0: request x11-req confirm 0 > > > and again DISPLAY is an undefined variable. > Could anyone help me to get this X11 tunelling work? > Thanks all very much, > nader > > >
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: [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.
