Fixing syntax errors in the access & alias configuration files

Following errors may be discovered using the syntax checker

Empty definitions

[master]$ /etc/ssh_master/manage_ssh.sh --check-syntax

ERROR: line '@admin_team' in alias file has missing or too many field(s) (should be 2)

Add members to the @admin_team alias in the alias file or comment it out.

Incorrect number of fields

[master]$ /etc/ssh_master/manage_ssh.sh --check-syntax

ERROR: line 'John_Doe   :   @db_hosts' in access file has missing or too many field(s) (should be 3)

Replace:

John_Doe : @db_hosts

By:

John_Doe : @db_hosts : johndoe

Non-resolving aliases

[master]$ /etc/ssh_master/manage_ssh.sh --check-syntax

ERROR: unable to resolve alias @acme_db in the alias file

Check the @acme_db alias is present in the alias file and that it has members.

Common copy/update errors

This is a non-exhaustive list of potential update problems

WARN: [10503]: could not lookup host host1, skipping

The client system’s name does not resolve correctly (DNS or locally on the SSH master). Make sure you add all possible domains to the /etc/resolv.conf for searching since SSH Controls may also use short host names:

search foo1.com foo2.com foo3.com

WARN: failed to transfer ./manage_ssh.sh to host1:/etc/ssh_controls/holding

The SFTP copy of the file to client failed. This can be due to:

  • ownership/permission errors on the files/parent directory on the target (see FAQ: DAC considerations
  • filesystem/network problems
  • SSH related errors

Permission denied (publickey,gssapi-keyex,gssapi-with-mic,password)

Your SSH login is not working on the client host. This can be due to:

  • Missing public key on the client host
  • Missing private key on the source host, or missing private key in the SSH agent.

If the problem is caused by a missing public key on the remote host then you can try to restore the remote SSH Controls key store if you can access the system using a password logon and if SSH Controls configuration data is still present there:

[master]$ ssh sshadmin@client
Password:

[client]$ sudo /etc/ssh_controls/holding/manage_ssh.sh --update

[client]$ ls –l /etc/ssh_controls/keys.d/sshadmin

If your key file is present then, you should be able to logon again using your SSH key pair.

WARNING: REMOTE HOST IDENTIFICATION HAS CHANGED!

This warning indicates that the client host key has been changed/updated since the last time you performed a logon to the system. Host keys are cached in the known_hosts file on the source host (where you are connecting from). To troubleshoot the problem, first connect manually to the problematic host to get the full warning message:

[master]$ ssh sshadmin@client

@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@
@    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 a host key has just been changed.
The fingerprint for the RSA key sent by the remote host is
b9:64:56:a4:cb:dd:d5:d7:45:74:32:74:0a:1a:0b:e6.
Please contact your system administrator.
Add correct host key in /home/sshadmin/.ssh/known_hosts to get rid of this message.
Offending RSA key in /home/sshadmin/.ssh/known_hosts:51
RSA host key for <client> has changed and you have requested strict checking.
Host key verification failed.

Then remove the offending fingerprint from your local known_hosts file (deleting the corresponding line completely). Alternatively, you can use SSH host key discovery feature to refresh your known_hosts file.

sudo: sorry, a password is required to run sudo

This error indicates that SSH Controls may not execute its operations with super-user privileges. Most likely the default SUDO rules for SSH Controls are missing in the SUDO configuration (see: Configuring a client host)

sudo: sorry, you must have a tty to run sudo

This error is most likely caused due to:

  1. missing SUDO rules for the SSH Controls on the client host. If SSH Controls cannot execute an apply or update as user root, then sudo will try to prompt for a password. Since the apply/update job is running in the background, no terminal (tty) can be opened for it.

Check the SUDO rules on the client host, fix and try again.

  1. Having requiretty set in your sudoers file(s):
Defaults    requiretty

Disable by:

Defaults    !requiretty

Or by removing the former line.

ERROR: authentication refused: bad ownership or modes for directory

This probably indicates that the /etc or / directory has the wrong ownership or permissions. Fix with:

[client]# chown root:root /
[client]# chown root:root /etc/
[client]# chmod 755 /
[client]# chmod 755 /etc

If this does not fix the problem then run the affected sshd in debug mode and check the log files for more information.

manage_ssh.sh hangs on background jobs when syncing or updating clients

The script divides its operations into batches of clients ($MAX_BACKGROUND_JOBS) and will wait for all of its current background jobs to finish before starting a new batch of clients. You may see a hanging job if no output is generated for a longer while:

INFO: *** finish of manage_ssh.sh [--update] ***
INFO: child process 21252 exited [RC=0]
INFO: child process 21266 exited [RC=0]
INFO: child process 21272 exited [RC=0]
…

A background job could be hanging on password prompt for example. In such case you should kill the client copy/update job on the SSH master:

[master] $ ps -ef | grep manage_ssh.sh

Identify the hanging job based on the timestamp (should be older):

sshadmin 21259 21243  0 11:20:25 pts/36    0:00 ssh -o StrictHostKeyChecking=no -o ConnectTimeout=10 -n sshadmin@host1 sudo /etc/ssh_master/holding/manage_ssh.sh --upda
sshadmin 21243     1  0 11:20:25 pts/36    0:00 /bin/ksh ./manage_ssh.sh --apply

And kill the job:

[master] $ kill 21243 21259
[master] $ kill -9 21243 21259

Fix the problem and re-try your operation.

Updated:

Leave a comment