On 5/1/07, Robert Freeman <robertgfreeman@xxxxxxxxx> wrote:
I switched the StrictModes to no just to see if it might be a permissions issue. It made no difference. RF
In that case, I'd suggest posting the output from running ssh with a dummy command in verbose mode. Something like: $ ssh -vvv -t node1 /bin/true If that doesn't yield anything helpful, you may need to run sshd in debugging mode in order to determine what's failing... ideally, your sysadmin would assist in this endeavor. If necessary, however, you can run a private copy of sshd (with somewhat limited functionality) on an alternate port. In this situation it would only be able to authenticate your own userid, and then only by public-key (because it can't read /etc/shadow, etc.)... this is likely adequate to troubleshoot this sort of issue. 1. Generate a temporary set of password-less server keypairs (i.e. ssh-keygen -b 1024 -t rsa -N '' -f ./ssh_host_rsa_key). 2. Make a copy of sshd_config. Change the HostKey entry to point to your temporary keypair (comment out the extra entries, if any), and Port to something unused (such as 2222). 3. Launch sshd on node1 using your debug configuration (sshd -ddd -e -f ./sshd_config). 4. Attempt to connect to your alternate sshd from node2 (ssh -p 2222 node1) Between the client and server debugging output, it's should be possible to determine what's wrong. -- "I'm too sexy for my code." - Awk Sed Fred.