Always receive error code 255 using passwordless SSH - it works though

Printable View

06-14-2011
mcclunyboy

Always receive error code 255 using passwordless SSH - it works though

Hi,

I am trying to set up passworldess login - I found this forum the most useful so hope someone can help.

I am trying to automate ssh to use send commands from a Red Hat el5.2 server to a solaris 9 server (I did get it working from solaris 10-9).

I have ran ssh-keygen -t rsa and then the ssh-copy-id and i can login passwordless via ssh. N HURRAH

Unfortunately when I use my scripts to automate the commands I ALWAYS receive an "Error Code - 255" - the command is successfully sent.

Red Hat uses ssh 4.3

Really need a quick answer for this please...
06-15-2011
atreyu

can you post a snippet of your code, and also whatever errors/messages are spewed to STDOUT, besides error code - 255 (which I don't recognize).

also, try ssh -v when debugging ssh.
06-15-2011
mcclunyboy

ssh -v results below (I have actually tried -vv and -vvv and can't see anything out of the ordinary). There are no unusual messages in /var/log/messages or /var/log/secure (didn't know if there should be.....)

Everything points to it working fine, I can see the results of the command working successfully on the destination server - however even so I recieve this error 255 - is there a way to supress errors (not wise, I know but maybe necessary)??

Code:

Command exited with Error Status = 255 OpenSSH_4.3p2, OpenSSL 0.9.8b 04 May 2006 debug1: Reading configuration data /etc/ssh/ssh_config debug1: Applying options for * debug1: Connecting to Ip address [ip address] port 22. debug1: Connection established. debug1: identity file /home/user/.ssh/identity type -1 debug1: identity file /home/user/.ssh/id_rsa type 1 debug1: identity file /home/user/.ssh/id_dsa type -1 debug1: loaded 3 keys debug1: Remote protocol version 2.0, remote software version Sun_SSH_1.0.1 debug1: match: Sun_SSH_1.0.1 pat Sun_SSH_1.0* debug1: Enabling compatibility mode for protocol 2.0 debug1: Local version string SSH-2.0-OpenSSH_4.3 debug1: SSH2_MSG_KEXINIT sent debug1: SSH2_MSG_KEXINIT received debug1: kex: server->client aes128-cbc hmac-md5 none debug1: kex: client->server aes128-cbc hmac-md5 none debug1: sending SSH2_MSG_KEXDH_INIT debug1: expecting SSH2_MSG_KEXDH_REPLY debug1: Host '192.168.129.2' is known and matches the RSA host key. debug1: Found key in /home/user/.ssh/known_hosts:1 debug1: ssh_rsa_verify: signature correct debug1: SSH2_MSG_NEWKEYS sent debug1: expecting SSH2_MSG_NEWKEYS debug1: SSH2_MSG_NEWKEYS received debug1: SSH2_MSG_SERVICE_REQUEST sent debug1: SSH2_MSG_SERVICE_ACCEPT received debug1: Authentications that can continue: publickey,password debug1: Next authentication method: publickey debug1: Trying private key: /home/user/.ssh/identity debug1: Offering public key: /home/user/.ssh/id_rsa debug1: Server accepts key: pkalg ssh-rsa blen 277 debug1: read PEM private key done: type RSA debug1: Authentication succeeded (publickey). debug1: channel 0: new [client-session] debug1: Entering interactive session. debug1: Sending environment. debug1: Sending env LANG = en_US.UTF-8 debug1: Sending command: mkdir thisfilenew debug1: channel 0: free: client-session, nchannels 1 debug1: fd 0 clearing O_NONBLOCK debug1: fd 1 clearing O_NONBLOCK debug1: Transferred: stdin 0, stdout 0, stderr 0 bytes in 11.1 seconds debug1: Bytes per second: stdin 0.0, stdout 0.0, stderr 0.0 debug1: Exit status -1
06-15-2011
atreyu

Quote:

Originally Posted by mcclunyboy

ssh -v results below (I have actually tried -vv and -vvv and can't see anything out of the ordinary). There are no unusual messages in /var/log/messages or /var/log/secure (didn't know if there should be.....)

Everything points to it working fine, I can see the results of the command working successfully on the destination server - however even so I recieve this error 255 - is there a way to supress errors (not wise, I know but maybe necessary)??

Perhaps you need to start the SSH server on the other side in debug mode, in order to troubleshoot further?

Anyway, for your client side, you can try this to disable the message maybe. Create (or append to) the file ~/.ssh/config:

Code:

host <SSH_SERVERNAME_OR_IPADDR> LOGLEVEL Quiet