ssh on trusted system??

[John McDen]

I download the ssh (a.03.10) from the hp site and tyring to get it run on a trusted system but so far I don't have any luck...

I am able to use ssh from the trusted system to the other server but not able to enter into the trusted system.. do anybody have sussess in using on a trusted system .. any kind of help will be really appreciated..

Thanks.

[Arockia Jegan]

Hi,

I'm running ssh on the trusted system. Is sshd daemon running on your trusted system? If it's not running start sshd daemon. It should be under //sbin/ . Can you also post the sshd_config file settings?

[Deshpande Prashant]

HI
I'm also running openssh 3.1 on trusted systems
so far no problems.
Give your error messages.
Prashant.

[John McDen]

Hello Arockia,

I did not make any changes to the ssh_config file or the sshd_config file.. and the sshd is running...

[John McDen]

Hello Deshpande,

The only message I get is ..

Connection to systemname closed.

I use the command ssh -l username systemname

[John McDen]

I also tried with openssh 3.1 and had the same problem...:-(

[Darrell Allen]

Hi John,

Be sure to use the "-v" option of ssh. You might want to post that output.

Also, ssh from the trusted system to itself. Again, use the "-v" option to see what's going on.

Darrell

[Craig Rants]

John,
please post the contents of your sshd_config on the server you are trying to connect TO, and the ssh_config from the server you are connecting FROM.

The only thing that running ssh on a trusted system that changes things is if the tcb database is updated or not.

GL,
C

[John McDen]

One thing I really can't under stand is that why is that it is still looking for openssh 3.1 and openssl infact I have already removed this from the system..

root@sys10:/> ssh -v -l mcden sys10
OpenSSH_3.1p1, SSH protocols 1.5/2.0, OpenSSL 0x0090603f
debug1: Reading configuration data /opt/ssh/etc/ssh_config
debug1: Rhosts Authentication disabled, originating port will not be trusted.
debug1: restore_uid
debug1: ssh_connect: getuid 0 geteuid 0 anon 1
debug1: Connecting to sys10 [4.36.33.33] port 22.
debug1: temporarily_use_uid: 0/3 (e=0)
debug1: restore_uid
debug1: temporarily_use_uid: 0/3 (e=0)
debug1: restore_uid
debug1: Connection established.
debug1: read PEM private key done: type DSA
debug1: read PEM private key done: type RSA
debug1: identity file /.ssh/id_rsa type -1
debug1: identity file /.ssh/id_dsa type -1
debug1: Remote protocol version 2.0, remote software version OpenSSH_3.1p1
debug1: match: OpenSSH_3.1p1 pat OpenSSH*
Enabling compatibility mode for protocol 2.0
debug1: Local version string SSH-2.0-OpenSSH_3.1p1
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: SSH2_MSG_KEX_DH_GEX_REQUEST sent
debug1: expecting SSH2_MSG_KEX_DH_GEX_GROUP
debug1: dh_gen_key: priv key bits set: 142/256
debug1: bits set: 1605/3191
debug1: SSH2_MSG_KEX_DH_GEX_INIT sent
debug1: expecting SSH2_MSG_KEX_DH_GEX_REPLY
debug1: Host 'sys10' is known and matches the RSA host key.
debug1: Found key in /.ssh/known_hosts:1
debug1: bits set: 1595/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
debug1: next auth method to try is publickey
debug1: try privkey: /.ssh/id_rsa
debug1: try privkey: /.ssh/id_dsa
debug1: next auth method to try is keyboard-interactive
debug1: authentications that can continue: publickey,password,keyboard-interactive
debug1: next auth method to try is password
mcden@sys10's password:
debug1: packet_send2: adding 48 (len 61 padlen 19 extra_pad 64)
debug1: ssh-userauth2 successful: method password
debug1: channel 0: new [client-session]
debug1: send channel open 0
debug1: Entering interactive session.
debug1: ssh_session2_setup: id 0
debug1: channel request 0: pty-req
debug1: channel request 0: shell
debug1: fd 4 setting TCP_NODELAY
debug1: channel 0: open confirm rwindow 0 rmax 32768
Last successful login for mcden: Thu Jun 20 14:16:43 EST5EDT 2002 on pts/17
Last unsuccessful login for mcden: Mon Jun 17 09:07:40 EST5EDT 2002
Last login: Thu Jun 20 14:16:44 2002 from sys10.averydenn
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
Connection to sys10 closed.
debug1: Transferred: stdin 0, stdout 0, stderr 29 bytes in 0.2 seconds
debug1: Bytes per second: stdin 0.0, stdout 0.0, stderr 120.2
debug1: Exit status 254

Also attached the ssh_config and sshd_config files...

[Darrell Allen]

Hi again,

Well, your ssh -v output looks like my ssh -v output from a successful connection with the exception of Exit Status 254 which is supposed to be the error code of the remote command. Check out:
http://support2.itrc.hp.com/service/cki/docDisplay.do?docLocale=en_US&docId=200000061597111#Q22

It says to add move 'v's to your command for more verbose messages. So try "ssh -vvv ..." to see what happens. You may also want to tweak the sysloging levels for ssh (see the above web page).

HP supports their Secure Shell if you have a support contract.

Darrell

[John McDen]

When I do ssh -V
OpenSSH_3.1p1, SSH protocols 1.5/2.0, OpenSSL 0x0090603f

why is that it is showing openssh 3.1 and openssl is it normal ???

[Darrell Allen]

Hi John,

I don't know if that's normal but it is what I see.

Darrell

[Keith Buck]

Can you telnet into the system?

The ssh -v output looks fine until the "received eof". I can reproduce simiar output by directing
I think I could reproduce this output by modifying .profile to exit immediately, but that would produce other problems. There are several files that usually run when ssh logs you into the system. If there is a problem with any of these, it could produce output similar to this.

Hope that helps.

[Daniel J. Doughty_1]

There's a difference in capitalization for the -v option. A capital V gives you the version number. A lower case gives you verbose. 2 lower case v's give you more verbose output. 3 lower case v's gives you the most verbose output.