topic Re: ssh reseting in Operating System - HP-UX

ssh reseting

mwagiru — Sun, 01 Apr 2007 09:40:05 GMT

ssh user@hostname
@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@
@ WARNING: POSSIBLE DNS SPOOFING DETECTED! @
@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@
The RSA host key for hostname has changed,
and the key for the according IP address 172.31.100.120
is unknown. This could either mean that
DNS SPOOFING is happening or the IP address for the host
and its host key have changed at the same time.
@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@
@ WARNING: REMOTE HOST IDENTIFICATION HAS CHANGED! @
@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@
IT IS POSSIBLE THAT SOMEONE IS DOING SOMETHING NASTY!
Someone could be eavesdropping on you right now (man-in-the-middle attack)!
It is also possible that the RSA host key has just been changed.
The fingerprint for the RSA key sent by the remote host is
75:a7:a5:d0:16:03:e2:0b:6a:2a:cd:75:1a:56:fe:0b.
Please contact your system administrator.
Add correct host key in /root/.ssh/known_hosts to get rid of this message.
Offending key in /root/.ssh/known_hosts:2
RSA host key for hostname has changed and you have requested strict checking.
Host key verification failed.

Re: ssh reseting

mwagiru — Sun, 01 Apr 2007 09:45:26 GMT

i can connect when i delete /root/.ssh/known_host.
But i am soon disconnected...
my /root/known_hosts file :

|1|W6Lk6W+KZvEKb16ERn85fmhbYKE=|4UAGxA7TiFL0PTI/kWkApe6Izrk= ssh-rsa AAAAB3NzaC1yc2EAAAABIwAAAQEA5qHr8lFmegMewySeOC9WyijSY7MirGbiUKHw6Vkfl9sOG+18xiVyUUL63bScJox5MxjzJgqT+0Q01sB2eesAR3kjV/NBsKO8grd0Cy5s35PQrZZ98eunHCUiMh7xxCvojlp+pD5K6qTnD1R3g5zM8uyAgeFoEZupDSeUjMDCWZBOa0NP+uSB2leq7YBVpyBLIdUey9+M+vow5njZoaZdWFHFbsZ9KpLjoOvGSPfen3rbk4JFlM/WYLMFlprdUXynWQ6VLEn4o+OPMY1Jq1L/H6cju4d5g/0YVjw6HHnJq3n6hROAfoDrJ682V50nf4Z8rWK40W6me2aKXCvBXH1URw==

|1|5odrJxwcfDs2dzwqUMzUuYJa9/k=|EehijO13D77JcKio1ODT60nlHm0= ssh-rsa AAAAB3NzaC1yc2EAAAABIwAAAQEA5qHr8lFmegMewySeOC9WyijSY7MirGbiUKHw6Vkfl9sOG+18xiVyUUL63bScJox5MxjzJgqT+0Q01sB2eesAR3kjV/NBsKO8grd0Cy5s35PQrZZ98eunHCUiMh7xxCvojlp+pD5K6qTnD1R3g5zM8uyAgeFoEZupDSeUjMDCWZBOa0NP+uSB2leq7YBVpyBLIdUey9+M+vow5njZoaZdWFHFbsZ9KpLjoOvGSPfen3rbk4JFlM/WYLMFlprdUXynWQ6VLEn4o+OPMY1Jq1L/H6cju4d5g/0YVjw6HHnJq3n6hROAfoDrJ682V50nf4Z8rWK40W6me2aKXCvBXH1URw==

Re: ssh reseting

Steven E. Protter — Sun, 01 Apr 2007 11:06:22 GMT

Shalom,

> known_hosts

And try again.

The most likely cause of this is that either the target or the source system has generated a new public key, most likely from a system being re-installed.

SEP

Re: ssh reseting

mwagiru — Mon, 02 Apr 2007 00:53:21 GMT

Whenever I delete the known_hosts file, I can connect but i am soon disconnected.

Re: ssh reseting

paolo barila — Mon, 02 Apr 2007 03:38:58 GMT

Hi,

please check
/var/adm/syslog/syslog.log
on target host for sshd messages

Pablo

Re: ssh reseting

Ralph Grothe — Mon, 02 Apr 2007 04:08:52 GMT

Your SSH client is exactly telling you why it is refusing to establich a session, and what to do:

" Add correct host key in /root/.ssh/known_hosts to get rid of this message.
Offending key in /root/.ssh/known_hosts:2
RSA host key for hostname has changed and you have requested strict checking."

Most likely on your ssh client someone has enforced strict hostkey checking, because the default setting would be "ask".
This means that your ssh client isn't, after having shown you the above warning about a discovered mismatch between advertised hostkey on the ssh server and the current entry in the user's known_hosts file of the client, as it normally would, viz. asking you to either confirm (i.e. accepting the possibly spoofed identity of the ssh server), and then letting it save the new server's ssh host key on *your* behalf, or simply aborting by disapproving.
Because you most likely have an entry like
"StrictHostKeyChecking yes" your ssh client will *never* modify your client's user's known_host file, but instead the user to manually add new or remove outdated keys.

Please, check your ssh client's global config.
e.g.

# grep -i stricthostkeycheck /opt/ssh/etc/ssh_config
# StrictHostKeyChecking ask

or if prevelant, your user's overriding config

e.g.

$ grep -i stricthostkeycheck $HOME/.ssh/config

If you wish to stick with StrictHostKeyChecking you need to manually delete the outdated host key, and add the new one.
As you are obviously using an OpenSSH release >= 4 your hostkeys, as well as names they belong to are hashed, which makes them difficult to identify by humans.
But ssh-keygen supports new options to ease the task.
You can use -F option of ssh-keygen to identify the key belonging to a particular host.

e.g.

$ ssh-keygen -F somehost

should print that hosts hashed key.

Similarily,

$ ssh-keygen -R somehost

would remove the entry for somehost.

After that you could append the new host key by e.g.

$ ssh -o stricthostkeychecking=no someone@somehost >> ~/.ssh/known_hosts
someone@somehost password: ^C

Note, you don't need to do a full login here
as the key's already been saved to someone's known_hosts (thus the ^C), which you can immediately verify.

$ ssh-keygen -F somehost

Note also, you should (even temporarily) disable strict host key checking only after you have verified that the advertised host key's fingerprint is *really* the correct one.

If this is all too much fuss,
you could relapse to "ask" by either commenting out the stricthostkeychecking directive in ssh_config (or your personel config), or setting it explicitly to ask.

Besides, you should never simply delete or clobber by redirection any user's know_hosts file.

Re: ssh reseting

mwagiru — Wed, 11 Apr 2007 12:01:29 GMT

Thanks Ralph !!
ssh user@host
ssh: connect to host ppgp2 port 22: Connection refused

My problems are now worse...I can't connect...

Re: ssh reseting

Ralph Grothe — Thu, 12 Apr 2007 04:07:20 GMT

Connection refused, simply means that there is no service listening on this port (22/tcp) on the remote host.
Are you sure the sshd is running there?
And if, is it listening on the standard port?

On remote host do

$ UNIX95= ps -fC sshd

or

$ ps -fp $(cat /var/run/sshd.pid)
UID PID PPID C STIME TTY TIME COMMAND
root 28891 1 0 Dec 4 ? 35:37 /opt/ssh/sbin/sshd

Check if it was started with deviating Addr:Port options.

$ grep -Ei 'listenaddress|port' /etc/opt/ssh/sshd_config

If all's commented the defaults were taken,
and there should be a listening socket on port 22.
Check this

$ netstat -an -f inet|awk '$NF~/LISTEN/&&$4~/\.22$/'
tcp 0 0 *.22 *.* LISTEN

If you discovered a deviating port in sshd_config then replace 22 in above command with the appropiate port No..

If it was a different port then on the client that wants to connect address this port.
e.g. if server was listening at 2222

$ ssh -p 2222 -l user host hostname

Beware, scp already uses -p to designate "preserve permissions".
So with scp specify deviating port with -P.

Re: ssh reseting

mwagiru2 — Thu, 12 Apr 2007 06:53:52 GMT

I uniinstalled openssh-client and server and reinstalled again.
I was able to connect but only for a short while....

$ Read from remote host XXXX: Connection reset by peer
Connection to XXXX closed.

Tried again to connect...

@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@
@ WARNING: REMOTE HOST IDENTIFICATION HAS CHANGED! @
@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@
IT IS POSSIBLE THAT SOMEONE IS DOING SOMETHING NASTY!
Someone could be eavesdropping on you right now (man-in-the-middle attack)!
It is also possible that the RSA host key has just been changed.
The fingerprint for the RSA key sent by the remote host is
b2:11:94:bf:7d:c5:58:59:54:f4:e9:e8:c7:c7:0e:63.
Please contact your system administrator.
Add correct host key in /root/.ssh/known_hosts to get rid of this message.
Offending key in /root/.ssh/known_hosts:1
Password authentication is disabled to avoid man-in-the-middle attacks.
Keyboard-interactive authentication is disabled to avoid man-in-the-middle attacks.

Permission denied (publickey,password).

Re: ssh reseting

mwagiru2 — Thu, 12 Apr 2007 06:57:40 GMT

$ps -fp $(cat /var/run/sshd.pid)
UID PID PPID C STIME TTY TIME CMD
root 14609 1 0 Apr02 ? 00:00:00 /usr/sbin/sshd

$grep -Ei 'listenaddress|port' /etc/ssh/sshd_config
# What ports, IPs and protocols we listen for
Port 22
#ListenAddress ::
#ListenAddress 0.0.0.0

Re: ssh reseting

Ralph Grothe — Thu, 12 Apr 2007 08:08:24 GMT

Ok, your ssh server seems to run the default settings.
Don't get me wrong, but you checked these ssh server settings on the remote host that you want to connect to, not of the localhost's ssh server?
There should be no need to reinstall SSH, neither on remote, nor localhost, only needs to get configured correctly and restarted.
So we can assume that you have root access to both remote and local host?

As your ssh client is informing you to change root's known_hosts on local host you must have run the ssh command as root.
The user "user" was only a placeholder from my example.
Therefore you should pick a valid user on remote host.
But anyway, I don't think that we even get this far because already the host key checking fails, long before any user can be authenticated.

Have you tried to execute with the -o stricthostkeychecking=no already?

e.g.

ssh -o stricthostkeychecking=no -l remote_valid_user remote_host hostname

Re: ssh reseting

mwagiru2 — Thu, 12 Apr 2007 08:11:42 GMT

The settings were checked on the remote host.

Re: ssh reseting

Sergey Akifiev_1 — Thu, 12 Apr 2007 08:31:57 GMT

is it possible, that some hosts on your network have identical IP addresses?

Re: ssh reseting

mwagiru2 — Thu, 12 Apr 2007 09:23:20 GMT

Is it possible to have to hosts sharing the same ip?
I don't think so....

Re: ssh reseting

mwagiru2 — Thu, 12 Apr 2007 09:23:45 GMT

Is it possible to have 2 hosts sharing the same ip?
I don't think so....

Re: ssh reseting

mwagiru2 — Thu, 12 Apr 2007 09:25:46 GMT

I have commented stricthostchecking in the remote host so that it defaults to "ask".

Re: ssh reseting

mwagiru2 — Thu, 12 Apr 2007 10:33:54 GMT

Is it possible that there's some kind of a timeout, that causes disconnection to occur on the remote host?
I dont get disconnected from any other host.
All applications that connect to other hosts also get disconnected. I suspect there's some kind of system-wide login disconnection timeout....