Fixing syntax errors in the access & alias configuration files
Following errors may be discovered using the syntax checker
Add members to the
@admin_team alias in the
alias file or comment it out.
Incorrect number of fields
John_Doe : @db_hosts
John_Doe : @db_hosts : johndoe
@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: : 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:
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:
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:
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
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:
- 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.
- Having requiretty set in your sudoers file(s):
Or by removing the former line.
ERROR: authentication refused: bad ownership or modes for directory
This probably indicates that the
/ directory has the wrong ownership or permissions. Fix with:
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:
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:
Identify the hanging job based on the timestamp (should be older):
And kill the job:
Fix the problem and re-try your operation.