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 SUDO master). Make sure you add all possible domains to the /etc/resolv.conf
for searching since SUDO Controls may also use short host names:
search foo1.com foo2.com foo3.com
WARN: failed to transfer ./manage_sudo.sh to host1:/etc/sudo_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
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 sudoadmin@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/sudoadmin/.ssh/known_hosts to get rid of this message.
Offending RSA key in /home/sudoadmin/.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 SUDO Controls may not execute its operations with super-user privileges. Most likely the default SUDO rules for SUDO 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:
a. missing SUDO rules for the SUDO Controls on the client host. If SUDO 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.
b. 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_sudo.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_sudo.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 SUDO master:
[master] $ ps -ef | grep manage_sudo.sh
Identify the hanging job based on the timestamp (should be older):
sudoadmin 21259 21243 0 11:20:25 pts/36 0:00 ssh -o StrictHostKeyChecking=no -o ConnectTimeout=10 -n sudoadmin@host1 sudo /etc/sudo_master/holding/manage_sudo.sh --upda
sudoadmin 21243 1 0 11:20:25 pts/36 0:00 /bin/ksh ./manage_sudo.sh --apply
And kill the job:
[master] $ kill 21243 21259
[master] $ kill -9 21243 21259
Fix the problem and re-try your operation.
Comments