Operating System - HP-UX
1830779 Members
12254 Online
110016 Solutions
New Discussion

Re: sshd problem after "cloning" server

 
David Connolly
Regular Advisor

sshd problem after "cloning" server

Hi folks,

I am configuring a pair of servers to be identical except for their hostname and network. I built and hardened server 1 and then used ignite's make_tape_recovery command to "clone" the server. The server's hostname and IP address were changed and I regenerated the SSH keys. I can connect to the server using ssh no problem. However, after about 5 minutes, the SSH session dies and I cannot establish another. I started SSHD in debug mode and reproduced, but it didn't log anything specific.
Any thoughts on where I should look? All help appreciated.
9 REPLIES 9
RAC_1
Honored Contributor

Re: sshd problem after "cloning" server

Can you post sshd -ddd and ssh -vvv
There is no substitute to HARDWORK
Arunvijai_4
Honored Contributor

Re: sshd problem after "cloning" server

Do you see anything in /var/adm/syslog/syslog.log and try starting sshd with maximum debug mode and post your o/p here.

-Arun
"A ship in the harbor is safe, but that is not what ships are built for"
David Connolly
Regular Advisor

Re: sshd problem after "cloning" server


Output of sshd -ddd

(serv3240 root) /home/q009/.ssh $ /opt/ssh/sbin/sshd -ddd
debug3: Seeding PRNG from /opt/ssh/libexec/ssh-rand-helper
debug2: load_server_config: filename /opt/ssh/etc/sshd_config
debug2: load_server_config: done config len = 289
debug2: parse_server_config: config /opt/ssh/etc/sshd_config len 289
debug1: sshd version OpenSSH_3.9 [ HP-UX Secure Shell-A.03.91.002 ]
debug3: Not a RSA1 key file /opt/ssh/etc/ssh_host_rsa_key.
debug1: read PEM private key done: type RSA
debug1: private host key: #0 type 1 RSA
debug3: Not a RSA1 key file /opt/ssh/etc/ssh_host_dsa_key.
debug1: read PEM private key done: type DSA
debug1: private host key: #1 type 2 DSA
debug1: rexec_argv[0]='/opt/ssh/sbin/sshd'
debug1: rexec_argv[1]='-ddd'
debug2: fd 4 setting O_NONBLOCK
debug1: Bind to port 22 on 0.0.0.0.
Server listening on 0.0.0.0 port 22.


Output of ssh -vvv
OpenSSH_3.9, OpenSSL 0.9.7d 17 Mar 2004
HP-UX Secure Shell-A.03.91.002, HP-UX Secure Shell version
debug1: Reading configuration data /opt/ssh/etc/ssh_config
debug3: Seeding PRNG from /opt/ssh/libexec/ssh-rand-helper
debug2: ssh_connect: needpriv 0
debug1: Connecting to serv3240 [10.233.41.208] port 22.
debug1: connect to address 10.233.41.208 port 22: Connection refused
ssh: connect to host serv3240 port 22: Connection refused

David Connolly
Regular Advisor

Re: sshd problem after "cloning" server

Nothing SSH related in syslog.log.
Arunvijai_4
Honored Contributor

Re: sshd problem after "cloning" server

May be you can try upgrading to A.04.10.004 and see what happens there, it could be a bug with your SSH version.

http://h20293.www2.hp.com/portal/swdepot/displayProductInfo.do?productNumber=T1471AA

-Arun
"A ship in the harbor is safe, but that is not what ships are built for"
David Connolly
Regular Advisor

Re: sshd problem after "cloning" server

Thanks - but bear in mind the SSHD server works perfectly on the original system, it's only on the clone that the session dies. BTW: The server is patched to June 2005 Goldpack.
RAC_1
Honored Contributor

Re: sshd problem after "cloning" server

debug1: connect to address 10.233.41.208 port 22: Connection refusedssh: connect to host serv3240 port 22: Connection refused

anything in /etc/hosts.allow or /etc/hosts.deny and /var/adm/inetd.sec that denies ssh connection?? Can you ssh from some other machine to this server??
There is no substitute to HARDWORK
Arunvijai_4
Honored Contributor

Re: sshd problem after "cloning" server

http://www.openssh.com/faq.html#2.12

You can enable ClientAliveInterval in the server's sshd_config, or enable ServerAliveInterval in the client's ssh_config (the latter is available in OpenSSH 3.8 and newer).

-Arun
"A ship in the harbor is safe, but that is not what ships are built for"
David Connolly
Regular Advisor

Re: sshd problem after "cloning" server

Folks,

My apologies - poor TCPIP management here resulted in a duplicated IP address (with a Windows box) and hence the weird behaviour. Sorry for the wild-goose-chase.