ssh install on solaris question

[tony4704]

Thank you everyone, I am going to take a look at this when I get more time...thanks for the great detail that some have you have put into this post.

 

[tony4704]

Ok well i restored the system to the Solaris 9.1 version of ssh, re made the public/private key files as suggested, checked permissions on everything and this is what happens now when I try to ssh from the server to the client or even vice versa:

ssh -2 -l emsuser -i id_dsa103 172.23.108.99
Connection closed by 172.23.108.99

 

[QuixoticOne]

What happens when you don't try to use the key authentication?

ssh -2 -l emsuser 172.23.108.99

Did you set the firewall to allow SSH traffic in and out between the machines?

What happens when you ssh to the same PC you're already on (emsuser would have to be an actual enabled account on whatever PC you're going to of course):

ssh -2 -l emsuser 127.0.0.1
ssh -2 -l emsuser -i id_dsa103 127.0.0.1

Is sshd service daemon enabled to run on the host(s)?

Try -vvv to get some debug output and post it if you try these things briefly and can't get any clue as to why it's not working in the various scenarios.

Originally posted by: tony4704
Ok well i restored the system to the Solaris 9.1 version of ssh, re made the public/private key files as suggested, checked permissions on everything and this is what happens now when I try to ssh from the server to the client or even vice versa:

ssh -2 -l emsuser -i id_dsa103 172.23.108.99
Connection closed by 172.23.108.99

 

[tony4704]

Originally posted by: QuixoticOne
What happens when you don't try to use the key authentication?

ssh -2 -l emsuser 172.23.108.99

This lets me in after prompting me for a password


Did you set the firewall to allow SSH traffic in and out between the machines?

yes

What happens when you ssh to the same PC you're already on (emsuser would have to be an actual enabled account on whatever PC you're going to of course):

ssh -2 -l emsuser 127.0.0.1

ssh -2 -l emsuser 127.0.0.1
Secure connection to 127.0.0.1 refused.

ssh -2 -l emsuser -i id_dsa103 127.0.0.1

ssh -2 -l emsuser -i id_dsa103 127.0.0.1
Secure connection to 127.0.0.1 refused.

Is sshd service daemon enabled to run on the host(s)?
ps -ef |grep ssh
root 3394 29741 0 08:14:12 pts/2 0:00 grep ssh
hmm maybe not.


Try -vvv to get some debug output and post it if you try these things briefly and can't get any clue as to why it's not working in the various scenarios.

Any time I try using -vvv on this system it doesnt work:
ssh -2 -l emsuser -vvv -i id_dsa103 127.0.0.1
Usage: ssh [options] host [command]
Options:
-l user Log in using this user name.
-n Redirect input from /dev/null.
-A Enable authentication agent forwarding.
-a Disable authentication agent forwarding.
-X Enable X11 connection forwarding.
-x Disable X11 connection forwarding.
-i file Identity for RSA authentication(default: ~/.ssh/identity).
-t Allocate a tty even if a command is given.
-T Do not allocate a tty.
-v Verbose; display verbose debugging messages.
Multiple -v increases verbosity.
-V Display version number only.
-P Don't allocate a privileged port.
-q Quiet: don't display warning messages.
-f Fork into background after authentication.
-e char Set escape character; ``none'' = disable(default: ~).
-c cipher Select encryption algorithm: ``3des'', ``blowfish''
-m macs Specify MAC algorithms for protocol version 2.
-p port Connect to this port. Server must be on the same port.
-L listen-port:hostort Forward local port to remote address
-R listen-port:hostort Forward remote port to local address
These cause ssh to listen for connections on a port, and
forward them to the other side by connecting to hostort.
-C Enable compression.
-N Do not execute a shell or command.
-g Allow remote hosts to connect to forwarded ports.
-4 Use IPv4 only.
-6 Use IPv6 only.
-2 Force protocol version 2.
-o 'option' Process the option as if it was read from a configuration file.
-s Invoke command (mandatory) as SSHv2 subsystem.

 

[QuixoticOne]

Try this; login to a box that you want to be able to accept SSH connections, and to the account of the username to be receiving those connections (e.g. your emsuser on the SSH server):
cd /home/emsuser/.ssh
ssh-keygen -t rsa -f /home/emsuser/.ssh/id_rsa
don't use a key password

take the generated /home/emsuser/.ssh/id_rsa.pub and add it to a new line at the end of your /home/emsuser/.ssh/authorized_keys file just as you have done with the DSA type key, only this one will have the key in a slightly different format. Just preserve the key format intact as generated in the command above and prepend any desired
command="/bin/date"
followed by a space then the test of the RSA key.
All on a single new second (or new last) line with out permitting line-wrapping in the /home/emsuser/.ssh/authorized_keys file.

Change the permissions of /home/emsuser to 700 owned by emsuser and their group.
Change the permissions of /home/emsuser/.ssh to 700 owned by emsuser and their group.
Change the permissions of /home/emsuser/.ssh/authorized_keys to 600 owned by emsuser and their group.
Change the permissions of /home/emsuser/.ssh/id_rsa to 600 owned by emsuser and their group.
Change the permissions of /home/emsuser/.ssh/id_rsa.pub to 600 owned by emsuser and their group.

then once you've added the RSA format public key from /home/emsuser/id_rsa.pub to emsuser's authorized_keys file on the local machine(s) and set the permissions:
ssh -2 -i /home/emsuser/.ssh/id_rsa -l emsuser 127.0.0.1
...where you're already logged in as emsuser on the box that will be both initiating and receiving the test SSH connection.

Please post the output of this command from the system that will be initiating ssh, where I presume emsuser is the username of the user logged in to initiate the ssh test:
man ssh
ls -ld ~emsuser
ls -ld ~emsuser/.ssh

Please post the output of this command from the system that will be receiving the ssh connections from remote ssh clients, where I presume emsuser is the username of the user to be logged in to over ssh:
ls -ld ~emsuser
ls -ld ~emsuser/.ssh

It is possible (though seemingly unlikely) that your ssh client (or server??) doesn't support DSA format keys, but does support RSA format keys.
I suspect that possibility because of your continued problems getting it to work with the DSA keys, and because of this line in the previous post you made from SSH's output:

-i file Identity for RSA authentication(default: ~/.ssh/identity).

...where it doesn't mention DSA, though perhaps (I'd hope/expect anyway) that is just an error in the command's usage synopsis.


According to this Solaris 9 does seem to support RSA and DSA, though:
http://docs.sun.com/app/docs/d.../6jd6cjru1?l=en&a=view

 

[tony4704]

Well i would just like to note that this is the only server giving me trouble....All the others are running Solaris 10.1 and have no problem sshing back and forth and executing my script.

 

[QuixoticOne]

Glad to hear it is working on 10.1.
But DSA and RSA support have been in SSH for ... years and years. So I can't imagine that a correctly updated/patched 9.1 system's SSH even if it is a somewhat older release would fail to be able to interoperate with RSA/DSA pubkey authentication.

If it is limited in any way (other than just a bug), I'd guess that it supports RSA keys and not DSA keys, or has some more strict way of processing the command line arguments such that they're sensitive to being in a different order or something.

Originally posted by: tony4704
Well i would just like to note that this is the only server giving me trouble....All the others are running Solaris 10.1 and have no problem sshing back and forth and executing my script.