How To Troubleshoot Server Actions In Room Alert Manager

Follow these steps to manually test the SSH connection:

1. On Room Alert Manager’s host system, open a command prompt window as an administrator. You may find it at the following path: Start–> All Programs–> Windows System (or Accessories)–> Command Prompt
2. Then, in the command prompt window, run this command: ssh [username@target IP or hostname]
   
3. You should be able to connect to the target system without needing to enter the user’s password. (If the key has a passphrase associated with it, you will be prompted to enter that.)
   
   • If the SSH connection fails for any reason (including if you get prompted for your user password) please skip step 4 and go straight to the troubleshooting recommendations below.
4. If you are able to successfully establish an SSH connection to the target server, you can try manually sending the shutdown/reboot command next.
   • To do so, enter either the shutdown or reboot command below that corresponds to the target server’s Operating System.
     • Windows System – Shutdown: shutdown -s
     • Windows System – Reboot: shutdown -r
     • Linux System – Shutdown: sudo shutdown -h -t 5
     • Linux System – Reboot: sudo shutdown -r -t 5
     • Mac System – Shutdown: sudo shutdown -h now
     • Mac System – Reboot: sudo shutdown -r now
       
   • After a few moments, you should get feedback that indicates whether or not the command was successful. (In our example, we successfully rebooted the target server.)
     

Your “authorized keys” file must be stored in the correct location with the proper file name & permissions.

• The file name & location depends on whether the user account is a member of the local administrators group or a standard user account.
  • For a standard user, the authorized_keys file is located in the .ssh folder of the user’s directory.
    On Windows systems, the path is C:\Users\UserName\.ssh\authorized_keys
  • For an admin user, the administrators_authorized_keys file is located in the system’s main ssh directory.
    On Windows systems, the path is C:\ProgramData\ssh\administrators_authorized_keys
• Only the local system and administrators security group should have permissions to access the administrators_authorized_keys file.
  • The example below shows the permissions of the file on our Windows system.

1. Open the sshd configuration file in a text editor, such as Notepad.
   • For our example, we’re opening the file located at C:\ProgramData\ssh\sshd_config in a text editor.
2. Locate the Authentication settings, and make sure public key authentication is enabled.
   • In our example, we needed to uncomment the line “PubkeyAuthentication” and set it to yes.
     
3. Restart the SSH Server daemon to apply the change.

• Ensure that local anti-spyware and anti-virus programs on both the target computer and Room Alert Manager’s host system allow SSH connections.
• Ensure that the firewall on the target system allows incoming remote SSH connections via TCP Port 22 (or whatever custom port you may be using).

OpenSSH includes log files that may offer additional clues—or even specific suggestions—for troubleshooting. Debugging can be enabled at multiple levels in order to print additional information to the log files. For more information, please see this Wikibooks entry: OpenSSH/Logging and Troubleshooting.

For example, this debug line in our log shows that we need to adjust the user permissions on our administrators_authorized_keys file.

To get the debugging lines to print in our log, we simply adjusted the #Logging settings within our sshd_config file.

On the target system, the sshd service should be set to startup automatically. These instructions show you how to do that on Windows.

1. Open Windows Services.  You may find it at the following path: Start–> Control Panel–> Administrative Tools–> Services.
2. Right-click on OpenSSH SSH Server in the list of programs, and then select Properties.
   
3. In the service properties window, make sure Startup type is set to Automatic.
   

Use an administrator user on the target server. If the target server is a Mac or Linux, you’ll need to enable sudo without a password.

You can do this by editing the admin group permissions within the ‘/etc/sudoers’ file so that the user permissions are: ALL = (ALL) NOPASSWD: ALL. If you don’t wish to grant the user full-access, you may configure limited access to only execute certain commands without a password. There are tutorials available online that walk you through this process.