Systems Management Forums

OME / ssh host key linux server

Systems Management

Systems Management
Dell Systems Management Solutions: Dell OpenManage, iDRAC, Repository Manager, Microsoft SCCM, Chassis Managment Controller, and more

OME / ssh host key linux server

  • Thanks for the feedback Stephan. I wasn't sure which service needed the Administrator user so I changed all three of them (DSM BMU SOL Proxy, DSM Essentials Task Manager, and DSM Essentials Network Monitor) and restarted them.

    Unfortunately the problem still persists for me. I opened a case a few days ago, but still unresolved through support.

  • Chris,

    I also changed the 3 services.

    Did you run the the plink with this user ?

  • so, the issue here it seems is that the user for the OME services must be the same user you login with and manually make the ssh key store for the targets.  

    putty is looking for the key in HKEY_CURRENT_USER\Software\SimonTatham\Putty\SshHostKeys

    which is specific to the user( in this case the service account that OME is attempting to use)

  • Turns out the last test was caused by me using the hostname in the plink manual run, rather than the IP which was what was used in discovery. I reran plink with the IP rather than host and it worked.

    Then I went through and set the services to SYSTEM (deleting the key and putty.rnd) one-by-one to see which was causing the problem. All of the services got set SYSTEM and everything was still fine!

    I added another server. It worked fine first time. Who knows that craziness was happening, but it's resolved now. Maybe the services were originally running as local service rather than local system before (I don't remember but I thought it was SYSTEM)?

  • Great News!

  • This is how I solved the issue on my end:

    Created a .cmd file with the following code:

    @echo off

    D:\Admin\Scripts\CMD\plink.exe -l %1 -pw %2 %3 %4 < D:\Admin\Scripts\CMD\yes.txt

    Saved this file on a directory inside D:\Admin\Scripts\CMD on my OME server as sshkeys.cmd. In that same directory, saved a copy of plink.exe and also a text file called yes.txt, which only contains the letter y. (You can save this anywhere you choose though I strongly suggest that there are no spaces in the path).

    I then created a generic remote command task on OME. On the command line i entered the full path to the sshkeys.cmd batch file:

    D:\admin\Scripts\CMD\sshkeys.cmd

    On the Arguments line I entered the username, password, $ip OME variable, and the command I want plink to execute, each argument is separated by space:

    root password $ip hostname

    I then targeted this to a search query that populates only ESX servers.

    What this will do is to simply connect via plink to the ESX host and run the hostname command. By using the yes.txt file, the batch command will automatically answer 'y' when prompted to import a ssh host key if it connects to a server that it hasn't connected to before. By targeting this to a search query in OME I ensure that, as new ESX hosts are added/re-added to the environment, all I have to do is run this task on a schedule and it will keep the SSH keys on my registry updated.

  • Thanks for this info.  Just checking...do you mean $name instead of hostname, or else it seems like you are passing ‘hostname’ to %4 in the file.

    thx

    Rob

  • I'm passing the command 'hostname' as argument 4.  The arguments being passed are:

    %1 - user

    %2 - password

    %3 - $ip

    %4 - command to run on ESX/Linux host. In this case I'm simply the hostname command.

  • Hello,

    I try  jhboricuamn solution, but I get error If run task. I checked the file path, I don't understand what is the problem.

    Results:   Command failed with error message: Cannot find command. Check command path and filename.

  • thanks for the post.

    A few questions:

    - What does the command and arguments being used look like ? (Command parameter + Arguments parameter)?

    - Was a command file created?

    - What is the path to the command file?

    thx

    rob

  • The problem solved. This method isn't working, but I connect by putty to all machines, and delete all machines from OME, and inventory again.

  • In the absence of more details on how my method was implemented on your end, such as the ones Rob C is asking, my guess is that there is something wrong on your end. If you'd like more help on automating the collection of the SSH keys, we'll need the answers to Rob questions to start with.

  • I had the same issue trying to update RHEL5 clients from OME. I kept getting:

    "The server's host key is not cached in the registry. The system may not be the same".

    I've just spent 3 hours on the phone with Dell Support, which included going through this thread. Even though command line toos plink.exe and omreport.exe connected over ssh fine (and I answered 'y' to store the keys) , OME would fail with the above message for remote tasks (as detailed earler in the thread) or system updates.

    The workaround we found was to create a "Deply Server Administrator" task. We left the arguments blank so nothing would actually install (I already have OMSA installed on all the clients), and this generated the keys. After that remote tasks and system updates connected and ran successfully.

    Our theory is (the guy at Dell is checking) that the ssh keys are stored somewhere in the OME app, and not in putty or plink as they worked OK and hitting 'y' to store the keys made no difference. The only way to generate them seemed to be using the Deploy task. Maybe the software designers assume you are always going to deploy the OMSA software via OME first, which will create the keys so then any subsequent updates or remote tasks will run. In my case OMSA was already installed.

  • In my case, I already installed OMSA first and then I installed OME on Windows Server 2008 R2 Ent.  Also I applied plink and no firewall, no iptables and no selinux but I still getting the error message. How can I fix it? :(

  • See my workaround answer above.

    "create a "Deply Server Administrator" task. We left the arguments blank so nothing would actually install (I already have OMSA installed on all the clients), and this generated the keys."