ssh_exchange_identification: Connection closed by remote host

[CFI-beheer]

Hi Folks,

Since about two weeks we are having problem with our ssh connection from one
server(ServerA) to another server (Server B).
Both servers are identical server, rx2620, hp-ux 11.23.

The concurrent ssh connection is being established through ssh publickey authentication which means that
user account db12@serverA connects to useraccount db01@serverB without a password.
The connection is being used to run shell scripts.

Normally the connection goes mainly well but recently the connection is closed giving the
following message: (The message was generated at the 12 ssh-connection).

"ssh_exchange_identification: Connection closed by remote host"


I don't have a /etc/hosts.allow nor do I have a /etc/hosts.deny files.
I have google the message but I haven't find any solution yet.

Is there anyone who has come across this problem and was able to fix this.

Kinds Regards,

Frank

[Steven E. Protter]

Shalom Frank,

Probably an expired password or the user id was deactivated due to bad logins. See lastb output for details.

SEP

[OldSchool]

other potential issues:

make sure that, on serverB, nslookup returns the results you expect for both the name and ip of serverb.

on serverb, check that /.ssh/known_hosts file is correct, and the there are no permissions issues.

you might try doing:

ssh -v -v -v db01@serverb

from the command line and see if that sheds any light.

has either IP or name changed recently, or are you using DHCP?

[Kevin Wright]

That is just the standard connection closed message. You should check the syslog.log file on the server, it should provide more details. If not, you can enable debug mode on the server (sshd -d) and enable versobe logging on your client connection with ssh -vvv

[rajdev]

Hi,

The ssh verbose option (ssh -vvv ... ), is the bestway to start the troubleshooting.

see the syslogs on both servers. have you put any new patches or upgraded the ssh etc...

any changes in the keys or permission of the key files.

Regards
RD

[skt_skt]

Does any other connection/telnet works at the same time you have ssh issue?

IF you wanted to do further trouble shooting if it repeats.

On recurrence start sshd on an alternate port and use the "port" box of your PuTTY configuration to point to the alternate. See if ssh to this additional sshd is functioning.
hp-ux# /usr/sbin/sshd -p 2222
PuTTY open profile, plug in 2222 in port.

Does this work?

Logged into hp-ux server try logging into sshd through the loopback.

hp-ux# ssh root@localhost ....can be account other than root account

Attach tusc to the failing sshd running on the default port and attempt login from somewhere.

hp-ux# ps -ef|grep sshd
root 11285 16632 0 16:16:52 ? 0:19 sshd: root@pts/0
root 16632 1 0 Jun 26 ? 0:00 /opt/ssh/sbin/sshd
root 11329 16632 0 16:19:18 ? 0:19 sshd: root@pts/2

hp-ux# /usr/local/bin/tusc -Eeaf -p -v -rall -wall -vall -T '' -o /tmp/tusc_sshd.txt 16632

...run for 30 seconds

hp-ux# CTL-C

[CFI-beheer]

Folks,

The problem is also that the connection does not always fails. Most of the times it works well but something it does not.

I have followed the advice some of you and added the verbose option to the cronjob ssh for db12 users en pipe the output to logfiles
Crontab -l db12

53 00 * * 2-6 ssh -v -v -v db01@ServerB /prod1/oradata/beheer/batch/scripts/maak.sh vmcp_brin.Allow >>/home/db12/brin_batch.log 2>&1
54 00 * * 2-6 ssh -v -v -v db01@ServerB /prod1/oradata/beheer/batch/scripts/maak.sh vmcp_trs.Allow >>/home/db12/trs_batch.log 2>&1
55 00 * * 2-6 ssh -v -v -v db01@ServerB /prod1/oradata/beheer/batch/scripts/maak.sh vspp_stf.Allow >>/home/db12/staf_batch.log 2>&1


I have attached the output of the logsfile here( trs_batch.log)

Can anyone see strange things in the logfile that could help me out.

The strange think that I see is "

debug2: key_type_from_name: unknown key type '-----BEGIN'
debug3: key_read: missing keytype
debug3: key_read: missing whitespace

"

I wonder if that could cause the problem.


Greetings

Frank

[rajdev]

Hi Frank,

Looks like your key is not correct, but i am not sure why it works sometimes and other times it doesn't.

are you changing the keys etc....
if you have done some cut and paste of the key , check that there is no additional white space or control characters etc.
cksum the key file with a good one ( may be copied when it is working ...)
if i am not wrong, you should not include the BEGIN AND END lines in the key..., you have to include everything between those lines.

-- try recreating the key files

Regards,
RD

[CFI-beheer]

Could the problem also exist because of the maximum allowable ssh-connection?

I have attached my sshd_config files of both servers just in case.

Greetings,

Frank

[CFI-beheer]

rajdev,

Here is the result of cksum of the publickey
#cksum id_rsa.pub.db12
3386138690 397 id_rsa.pub.cfidb12

#grep db12 authorized_keys >/tmp/k2
#cd /tmp
#cksum k2
3386138690 397 k2

As you can see they a both identical keys are identical.