SSH syntax error

Applications Cybersecurity
1

I have been asked to look at a problem with implementing SSH on an HP-UX server which a colleague has set up. Users connect through PuTTY. When I try to establish a connection I see the following message:

 Usage: -ssh [options] host [command]
  Options:
    -l user     Log in using this user name.
    -n          Redirect input from /dev/null.
    -F config   Config file (default: ~/.ssh/config).
    -A          Enable authentication agent forwarding.
    -a          Disable authentication agent forwarding (default).
    -X          Enable X11 connection forwarding.
    -x          Disable X11 connection forwarding (default).
    -i file     Identity for public key authentication (default: ~/.ssh/identity)
    -t          Tty; allocate a tty even if command is given.
    -T          Do not allocate a tty.
    -h          Display basic help message .
    -k          Disables forwarding (delegation) of GSSAPI credentials.
    -v          Verbose; display verbose debugging messages.
                Multiple -v increases verbosity.
    -V          Display version number only.
    -q          Quiet; don't display any warning messages.
    -f          Fork into background after authentication.
    -e char     Set escape character; ``none'' = disable (default: ~).
    -c cipher   Select encryption algorithm
    -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:host:port   Forward local port to remote address
    -R listen-port:host:port   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 host:port.
    -D port     Enable dynamic application-level port forwarding.
    -C          Enable compression.
    -Y          Enables trusted X11 forwarding.
    -M          Place ssh into master mode for connection Sharing.
    -N          Do not execute a shell or command.
    -g          Allow remote hosts to connect to forwarded ports.
    -1          Force protocol version 1.
    -2          Force protocol version 2.
    -4          Use IPv4 only.
    -6          Use IPv6 only.
    -o 'option' Process the option as if it was read from a configuration file.
    -s          Invoke command (mandatory) as SSH2 subsystem.
    -S ctl      Specifies control socket for connection sharing.
    -b addr     Local IP address.

I have tried setting up traces on the server and running PuTTY interactively from a command line but no trace information is being generated. I think the client is passing authentication but whatever command is being issued on the server to start the shell is incorrectly formed.

Can anyone please advise where I can find this command or how I can go about amending it? This is an area about which I know almost nothing.

Thank you.

2

Can you try another ssh protocol-using command - sftp or scp?

That will verify the remote sshd_config is set up at least somewhat correctly. If that works, then we will have to have somebody here with more HPUX experience than me help you.

3

I ran scp from a SUN box with debug, It doesn't seem to have copied anything:here is the output.

=~=~=~=~=~=~=~=~=~=~=~= PuTTY log 2013.10.01 13:32:49 =~=~=~=~=~=~=~=~=~=~=~=
^[
/opt/techdev/cyborg61/61UK/work>ls -lscp -v -P2222 defact42@10.210.1.42:tmp1 tmp1
/opt/techdev/cyborg61/61UK/work>
Executing: program /usr/bin/ssh host 10.210.1.42, user defact42, command scp -v -f tmp1
Sun_SSH_1.1, SSH protocols 1.5/2.0, OpenSSL 0x0090704f
debug1: Reading configuration data /etc/ssh/ssh_config

debug1: Rhosts Authentication disabled, originating port will not be trusted.

debug1: ssh_connect: needpriv 0

debug1: Connecting to 10.210.1.42 [10.210.1.42] port 2222.

debug1: Connection established.

debug1: identity file /home/cyborg/.ssh/identity type -1

debug1: identity file /home/cyborg/.ssh/id_rsa type -1

debug1: identity file /home/cyborg/.ssh/id_dsa type -1

debug1: Remote protocol version 2.0, remote software version OpenSSH_3.9

debug1: match: OpenSSH_3.9 pat OpenSSH*

debug1: Enabling compatibility mode for protocol 2.0

debug1: Local version string SSH-2.0-Sun_SSH_1.1

debug1: Failed to acquire GSS-API credentials for any mechanisms (No credentials were supplied, or the credentials were unavailable or inaccessible
Unknown code 0
)

debug1: SSH2_MSG_KEXINIT sent

debug1: SSH2_MSG_KEXINIT received

debug1: kex: server->client aes128-ctr hmac-md5 none

debug1: kex: client->server aes128-ctr hmac-md5 none

debug1: Peer sent proposed langtags, ctos:

debug1: Peer sent proposed langtags, stoc:

debug1: We proposed langtags, ctos: i-default

debug1: We proposed langtags, stoc: i-default

debug1: SSH2_MSG_KEX_DH_GEX_REQUEST sent

debug1: expecting SSH2_MSG_KEX_DH_GEX_GROUP

debug1: dh_gen_key: priv key bits set: 123/256

debug1: bits set: 1033/2048

debug1: SSH2_MSG_KEX_DH_GEX_INIT sent

debug1: expecting SSH2_MSG_KEX_DH_GEX_REPLY

debug1: Host '10.210.1.42' is known and matches the RSA host key.

debug1: Found key in /home/cyborg/.ssh/known_hosts:5

debug1: bits set: 990/2048

debug1: ssh_rsa_verify: signature correct

debug1: newkeys: mode 1

debug1: SSH2_MSG_NEWKEYS sent

debug1: expecting SSH2_MSG_NEWKEYS

debug1: newkeys: mode 0

debug1: SSH2_MSG_NEWKEYS received

debug1: done: ssh_kex2.

debug1: send SSH2_MSG_SERVICE_REQUEST

debug1: got SSH2_MSG_SERVICE_ACCEPT

debug1: Authentications that can continue: publickey,password,keyboard-interactive

debug1: Next authentication method: publickey

debug1: Trying private key: /home/cyborg/.ssh/identity

debug1: Trying private key: /home/cyborg/.ssh/id_rsa

debug1: Trying private key: /home/cyborg/.ssh/id_dsa

debug1: Next authentication method: keyboard-interactive

Password:
debug1: Authentication succeeded (keyboard-interactive)

debug1: fd 5 setting O_NONBLOCK

debug1: fd 6 setting O_NONBLOCK

debug1: channel 0: new [client-session]

debug1: send channel open 0

debug1: Entering interactive session.

debug1: ssh_session2_setup: id 0

debug1: Sending command: scp -v -f tmp1

debug1: channel request 0: exec

debug1: channel 0: open confirm rwindow 0 rmax 32768

Unknown cipher type 'scp -v -f tmp1'
debug1: channel 0: rcvd eof

debug1: channel 0: output open -> drain

debug1: channel 0: obuf empty

debug1: channel 0: close_write

debug1: channel 0: output drain -> closed

debug1: client_input_channel_req: channel 0 rtype exit-status reply 0

debug1: channel 0: rcvd close

debug1: channel 0: close_read

debug1: channel 0: input open -> closed

debug1: channel 0: almost dead

debug1: channel 0: gc: notify user

debug1: channel 0: gc: user detached

debug1: channel 0: send close

debug1: channel 0: is dead

debug1: channel 0: garbage collecting

debug1: channel_free: channel 0: 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 0.9 seconds

debug1: Bytes per second: stdin 0.0, stdout 0.0, stderr 0.0

debug1: Exit status 1

/opt/techdev/cyborg61/61UK/work>

4

Ok. I understand ssh to some degree - it looks like there is something, on the remote side, that has an issue. I do not get the cipher error at all.

Do not test with the root account, use a non-superuser, maybe create one:

  1. put up a vanilla sshd_config file on the HPUX box - the one that comes with the distribution. It may not fit your security model, but this is just testing.

  2. check protections on the new remote account
    .ssh directory 700
    all files in .ssh 600 or 700
    login directory 755

  3. See if you can ssh from HPUX back to the sun box (not as root):

ssh j_walleans@sunbox

If that goes, try from sun to hpux. --as the new user

ssh newuser@hpux

This is about as far as I can go on this one.

5

Thanks for that - it may take time to dig out the vanilla file (I'm in UK, box is in US, don't know where the media might be) but I will give that a go.

6

I have tried the above using every sshd_config file I could find on the machine, including some dated as far back as 2004. None have made any difference.

7

Ugh. Don't know enough HPUX.

Are there other functioning, ssh-wise, HPUX boxes in the network? In the OSes I know well, /etc/ssh... has several important files: keys, an ssh config file, and the sshd_config file. Ignoring keys, I would look to see diffs in ssh_config and sshd_config among servers. If they are all the same, including the problem child, something else is wrong, possibly the ssh service startup. Restart the service correctly. Check to be sure the account you use does not have a "personal" ssh config file, unless that is standard company-wide.

When you are doing the diffs be sure to compare systems with equivalent patch levels.
Note patch discrepancies.

What I am doing is trying to rule out issues: config files, patch levels, service startup.
I cannot imagine that there is an issue with the TCP stack - ndd settings, but that would be the next thing to try.

I am assuming you tried to

ssh myusername@localhost

on the rogue host (not as root) to eliminate some transport issues/hardware. This bypasses the NIC and uses the TCP stack in the kernel. At least it does everywhere I've worked with it.

Do you guys implement LDAP or AD authentication?