I'm trying to run a command over ssh to AIX 5.2, something like:
ssh machine ls
but it just hangs. I can ssh into the machine and run a command, but can't pass it like above. Is there a security setting that disables this by default? If so, how do I change it?
Thanks!
look at (and post) the output of
$ ssh -vvv <machine> ls
Here it is:
OpenSSH_3.5p1, SSH protocols 1.5/2.0, OpenSSL 0x0090701f
debug1: Reading configuration data /etc/ssh/ssh_config
debug1: Applying options for *
debug1: Rhosts Authentication disabled, originating port will not be trusted.
debug1: ssh_connect: needpriv 0
debug1: Connecting to beckman [192.168.1.148] port 22.
debug1: Connection established.
debug1: identity file /home/tai/.ssh/identity type -1
debug1: identity file /home/tai/.ssh/id_rsa type -1
debug3: Not a RSA1 key file /home/tai/.ssh/id_dsa.
debug2: key_type_from_name: unknown key type '-----BEGIN'
debug3: key_read: no key found
debug3: key_read: no space
debug3: key_read: no space
debug3: key_read: no space
debug3: key_read: no space
debug3: key_read: no space
debug3: key_read: no space
debug3: key_read: no space
debug3: key_read: no space
debug3: key_read: no space
debug3: key_read: no space
debug2: key_type_from_name: unknown key type '-----END'
debug3: key_read: no key found
debug1: identity file /home/tai/.ssh/id_dsa type 2
debug1: Remote protocol version 1.99, remote software version OpenSSH_3.8.1p1
debug1: match: OpenSSH_3.8.1p1 pat OpenSSH*
debug1: Enabling compatibility mode for protocol 2.0
debug1: Local version string SSH-2.0-OpenSSH_3.5p1
debug1: SSH2_MSG_KEXINIT sent
debug1: SSH2_MSG_KEXINIT received
debug2: kex_parse_kexinit: diffie-hellman-group-exchange-sha1,diffie-hellman-group1-sha1
debug2: kex_parse_kexinit: ssh-rsa,ssh-dss
debug2: kex_parse_kexinit: aes128-cbc,3des-cbc,blowfish-cbc,cast128-cbc,arcfour,aes192-cbc,aes256-cbc,rijndael-cbc@lysator.liu.se
debug2: kex_parse_kexinit: aes128-cbc,3des-cbc,blowfish-cbc,cast128-cbc,arcfour,aes192-cbc,aes256-cbc,rijndael-cbc@lysator.liu.se
debug2: kex_parse_kexinit: hmac-md5,hmac-sha1,hmac-ripemd160,hmac-ripemd160@openssh.com,hmac-sha1-96,hmac-md5-96
debug2: kex_parse_kexinit: hmac-md5,hmac-sha1,hmac-ripemd160,hmac-ripemd160@openssh.com,hmac-sha1-96,hmac-md5-96
debug2: kex_parse_kexinit: none,zlib
debug2: kex_parse_kexinit: none,zlib
debug2: kex_parse_kexinit:
debug2: kex_parse_kexinit:
debug2: kex_parse_kexinit: first_kex_follows 0
debug2: kex_parse_kexinit: reserved 0
debug2: kex_parse_kexinit: diffie-hellman-group-exchange-sha1,diffie-hellman-group1-sha1
debug2: kex_parse_kexinit: ssh-rsa,ssh-dss
debug2: kex_parse_kexinit: aes128-cbc,3des-cbc,blowfish-cbc,cast128-cbc,arcfour,aes192-cbc,aes256-cbc,rijndael-cbc@lysator.liu.se,aes128-ctr,aes192-ctr,aes256-ctr
debug2: kex_parse_kexinit: aes128-cbc,3des-cbc,blowfish-cbc,cast128-cbc,arcfour,aes192-cbc,aes256-cbc,rijndael-cbc@lysator.liu.se,aes128-ctr,aes192-ctr,aes256-ctr
debug2: kex_parse_kexinit: hmac-md5,hmac-sha1,hmac-ripemd160,hmac-ripemd160@openssh.com,hmac-sha1-96,hmac-md5-96
debug2: kex_parse_kexinit: hmac-md5,hmac-sha1,hmac-ripemd160,hmac-ripemd160@openssh.com,hmac-sha1-96,hmac-md5-96
debug2: kex_parse_kexinit: none,zlib
debug2: kex_parse_kexinit: none,zlib
debug2: kex_parse_kexinit:
debug2: kex_parse_kexinit:
debug2: kex_parse_kexinit: first_kex_follows 0
debug2: kex_parse_kexinit: reserved 0
debug2: mac_init: found hmac-md5
debug1: kex: server->client aes128-cbc hmac-md5 none
debug2: mac_init: found hmac-md5
debug1: kex: client->server aes128-cbc hmac-md5 none
debug1: SSH2_MSG_KEX_DH_GEX_REQUEST sent
debug1: expecting SSH2_MSG_KEX_DH_GEX_GROUP
debug1: dh_gen_key: priv key bits set: 125/256
debug1: bits set: 1611/3191
debug1: SSH2_MSG_KEX_DH_GEX_INIT sent
debug1: expecting SSH2_MSG_KEX_DH_GEX_REPLY
debug3: check_host_in_hostfile: filename /home/tai/.ssh/known_hosts
debug3: check_host_in_hostfile: match line 13
debug3: check_host_in_hostfile: filename /home/tai/.ssh/known_hosts
debug3: check_host_in_hostfile: match line 13
debug1: Host 'beckman' is known and matches the RSA host key.
debug1: Found key in /home/tai/.ssh/known_hosts:13
debug1: bits set: 1570/3191
debug1: ssh_rsa_verify: signature correct
debug1: kex_derive_keys
debug1: newkeys: mode 1
debug1: SSH2_MSG_NEWKEYS sent
debug1: waiting for SSH2_MSG_NEWKEYS
debug1: newkeys: mode 0
debug1: SSH2_MSG_NEWKEYS received
debug1: done: ssh_kex2.
debug1: send SSH2_MSG_SERVICE_REQUEST
debug1: service_accept: ssh-userauth
debug1: got SSH2_MSG_SERVICE_ACCEPT
debug1: authentications that can continue: publickey,password,keyboard-interactive
debug3: start over, passed a different list publickey,password,keyboard-interactive
debug3: preferred publickey,keyboard-interactive,password
debug3: authmethod_lookup publickey
debug3: remaining preferred: keyboard-interactive,password
debug3: authmethod_is_enabled publickey
debug1: next auth method to try is publickey
debug1: try privkey: /home/tai/.ssh/identity
debug3: no such identity: /home/tai/.ssh/identity
debug1: try privkey: /home/tai/.ssh/id_rsa
debug3: no such identity: /home/tai/.ssh/id_rsa
debug1: try pubkey: /home/tai/.ssh/id_dsa
debug3: send_pubkey_test
debug2: we sent a publickey packet, wait for reply
debug1: input_userauth_pk_ok: pkalg ssh-dss blen 433 lastkey 0x8090280 hint 2
debug2: input_userauth_pk_ok: fp 06:c4:57:20:81:db:f4:27:b5:3c:8f:54:75:a2:04:47
debug3: sign_and_send_pubkey
debug1: read PEM private key done: type DSA
debug1: ssh-userauth2 successful: method publickey
debug1: channel 0: new [client-session]
debug3: ssh_session2_open: channel_new: 0
debug1: send channel open 0
debug1: Entering interactive session.
debug2: callback start
debug1: ssh_session2_setup: id 0
debug1: Sending command: ls
debug1: channel request 0: exec
debug2: callback done
debug1: channel 0: open confirm rwindow 0 rmax 32768
debug2: channel 0: rcvd adjust 131072
It hung, and I hit Ctrl-C:
debug1: channel_free: channel 0: client-session, nchannels 1
debug3: channel_free: status: The following connections are open:
#0 client-session (t4 r0 i0/0 o0/0 fd 4/5)
debug3: channel_close_fds: channel 0: r 4 w 5 e 6
Killed by signal 2.
debug1: Calling cleanup 0x805b060(0x0)
debug1: Calling cleanup 0x80674d0(0x0)
At this point, I think it crashes and reboots... it doesn't even respond to a ping.
OpenSSH_3.5p1, SSH protocols 1.5/2.0, OpenSSL 0x0090701f
debug1: Reading configuration data /etc/ssh/ssh_config
debug1: Applying options for *
debug1: Rhosts Authentication disabled, originating port will not be trusted.
debug1: ssh_connect: needpriv 0
debug1: Connecting to beckman [192.168.1.148] port 22.
debug1: connect to address 192.168.1.148 port 22: No route to host
ssh: connect to host beckman port 22: No route to host
Are the keys exchanged and do you have to enter a password/passphrase? It does look like you have not exchanged the keys between the two machines.
A common gotcha is that ssh assumes the user to be named the same on both machines until told otherwise. That means "user@machine1" issuing "ssh machine2" will implicitly try to connect as "user@machine2". This is not always what is intended. Many times you want to connect to machine2 as "root" or so. You willl have to explicitly tell this to ssh by using one of the two syntaxes:
user@machine1 # ssh anotheruser@machine2
user@machine1 # ssh machine2 -l anotheruser
If the user "user" would not exist on machine2 ssh won't tell you so (by issuing an error like "no such user") because this would be a way to find out which users exist and which don't on machine2 without even connecting to it.
I hope this helps.
bakunin
I have handshaking set up between the two machines, and they're both using the same username.
So "ssh tai@beckman" works, but "ssh tai@beckman ls" doesn't.
Your ssh connection appears to work but at three occasions in your debug output it seems like you simply don't get what the target node returns. The ping not returning to your node does not necessarily imply that your target node is dead/rebooting (check with who -b). There may be a problem with the routing. Do both nodes have a route defined to the other node? Can you connect to the originating node from node "beckman"?
Connecting from beckman to the originating machine works fine. I can connect normally over ssh to beckman and run commands (and receive a response) when I'm logged in, so it seems to me like it wouldn't be a routing issue...
I also checked who -b, and the last boot was just after I attempted the "ssh tai@beckman ls" command.
Thanks for your suggestions so far... hopefully we can figure this out.
I tried running "ssh root@beckman ls", and that worked fine, so it looks like a permissions issue. Does anyone know where a setting would be to enable/disable passing a command over ssh for a normal user?
In this case compare the two users environment settings (in the .profile and .kshrc or .bashrc). You could try to exchange those settings files with root's for a test.