- Community Home
- >
- Servers and Operating Systems
- >
- Operating Systems
- >
- Operating System - Linux
- >
- Re: ssh & service guard
Categories
Company
Local Language
Forums
Discussions
Forums
- Data Protection and Retention
- Entry Storage Systems
- Legacy
- Midrange and Enterprise Storage
- Storage Networking
- HPE Nimble Storage
Discussions
Discussions
Discussions
Forums
Forums
Discussions
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
- BladeSystem Infrastructure and Application Solutions
- Appliance Servers
- Alpha Servers
- BackOffice Products
- Internet Products
- HPE 9000 and HPE e3000 Servers
- Networking
- Netservers
- Secure OS Software for Linux
- Server Management (Insight Manager 7)
- Windows Server 2003
- Operating System - Tru64 Unix
- ProLiant Deployment and Provisioning
- Linux-Based Community / Regional
- Microsoft System Center Integration
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Community
Resources
Forums
Blogs
- Subscribe to RSS Feed
- Mark Topic as New
- Mark Topic as Read
- Float this Topic for Current User
- Bookmark
- Subscribe
- Printer Friendly Page
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
тАО08-29-2005 02:44 AM
тАО08-29-2005 02:44 AM
The problem occurs when in failover mode. Instead of our processes sending files to box X with an IP address of 10.10.10.1 it now attempts to send files to box X with an IP address of 10.10.10.2 and the following message is displayed:
@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@
@ 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 5e:e0:25:a4:50:c3:cf:e6:6e:da:8f:cc:74:0f:bf:2d.
Please contact your system administrator.
Add correct host key in /home/user1/.ssh/known_hosts to get rid of this message.
Offending key in /home/user1/.ssh/known_hosts:2 RSA host key for X has changed and you have requested strict checking.
Host key verification failed.
lost connection
Any ideas on how to solve this problem?
Thanks in advance.
Solved! Go to Solution.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
тАО08-29-2005 03:09 AM
тАО08-29-2005 03:09 AM
Re: ssh & service guard
go to $HOME/.ssh directory where $HOME is the home dir of this user,i.e. if the user is root then it would be /root/.ssh
Edit the file known_hosts find the entry for previous IP (10.10.10.1 in you case)
and delete it.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
тАО08-29-2005 03:17 AM
тАО08-29-2005 03:17 AM
Re: ssh & service guard
I know I can remove the entry in my known_hosts file but this only fixes it temporarily. I will need to remove the entry in the known_hosts file again when I fail the box over. Is there a way to connect to a different box in failover without having to modify the known_hosts file?
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
тАО08-29-2005 03:21 AM
тАО08-29-2005 03:21 AM
Re: ssh & service guard
As far as SG goes, if all ssh traffic to the SG cluster is to a floating IP address, these errors should not occur any more after taking the steps above.
SEP
Owner of ISN Corporation
http://isnamerica.com
http://hpuxconsulting.com
Sponsor: http://hpux.ws
Twitter: http://twitter.com/hpuxlinux
Founder http://newdatacloud.com
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
тАО08-30-2005 02:18 AM
тАО08-30-2005 02:18 AM
Solutiongood luck
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
тАО08-30-2005 02:30 AM
тАО08-30-2005 02:30 AM
Re: ssh & service guard
Thanks Again.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
тАО08-30-2005 03:29 AM
тАО08-30-2005 03:29 AM
Re: ssh & service guard
It is not clear what processes are the ones that failed over. From the description, it is also not clear why the IP address is changing.
So are the processes that are doing the ssh the ones that failover? So can you please describe what is running on the cluster nodes and what is on the client?
Also, after failover, has the ssh "restarted" or is there an assumption that the ssh should still be connected? If there is an assumption that ssh is still connected, that could be the problem.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
тАО08-30-2005 03:31 AM
тАО08-30-2005 03:31 AM
Re: ssh & service guard
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
тАО08-30-2005 03:42 AM
тАО08-30-2005 03:42 AM
Re: ssh & service guard
The ONLY way of not getting into this problem
is to share one hostkey (/etc/ssh/ssh_host*)
for both servers.
Simply copy all 3 host keys to the other system.
Thus, the floating IP has always the same host key... everything is fine :-)
This will be no security issue because the maping is OK, you can activate strict checking again.
Armin
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
тАО08-30-2005 07:49 AM
тАО08-30-2005 07:49 AM
Re: ssh & service guard
Changing StrictHostKeyChecking doesn't help either, nor does changing CheckHostIP.
At least it didn't for me.
When the package moves to the other node, then the key fingerprint changes (for the floating name/IP) and the ssh to the floating IP fails with this error.
It will still work fine for access to the *node* names/IPs, but *not* the floating name/IP.
I wanted to be able to determine dynamically the hostname from where the package is currently running by doing
# pkgHost=$( ssh pkg-name/IP hostname )
to be able to do special things (like backup things) dynamically.
I ended up allowing 'remsh' *only* between the nodes. Then
# pkgHost=$( remsh pkg-name/IP hostname )
works fine, of course.
bv