fix: set file permissions on AWS credentials, remove sensitive data from SSH logs

[jlima8900]

Summary

Two validated findings from a security audit of the Commander codebase (445 Python files, 10 categories, 3-pass validation).

KC-2026-001: AWS credentials file permissions

The awskey plugin writes rotated AWS credentials without setting restrictive file permissions. If the credentials file is newly created (custom path), it inherits umask defaults (typically 0644), making the AWS secret access key readable by other users on multi-user systems.

File: keepercommander/plugins/awskey/aws_accesskey.py:138

Fix: Add os.chmod(creds_filename, 0o600) after writing credentials file and backup.

KC-2026-002: SSH plugin logs password command output

The SSH password rotation plugin logs raw terminal output from the passwd command at DEBUG level. This output can include echoed password characters, credential-related prompts, or error messages that reveal password context.

File: keepercommander/plugins/ssh/ssh.py:118,126,131,138

Fix: Replace raw output logging with response size only ('Rotation command responded (%d bytes)'). The actual credential values are no longer included in log statements.

Audit methodology

• 130 initial candidates from static analysis
• 17 after first validation (context check)
• 5 after second validation (exploitability check)
• 2 after third validation (data flow trace)
• 98.5% false positive elimination rate

Test plan

• AWS plugin: verify credentials file has 0600 permissions after rotation
• AWS plugin: verify backup file also has 0600 permissions
• SSH plugin: verify DEBUG logs no longer contain terminal output
• SSH plugin: verify password rotation still works correctly
• No regressions in existing plugin tests

[aaunario-keeper]

One concern — race condition (TOCTOU): The file is opened, written, closed, and then chmod'd. There is a brief window where the file exists at 0644 (or whatever the process umask dictates) before permissions are restricted. On a paranoid multi-user system, the correct fix would be to either:

Set a restrictive umask before open() and restore it afterward,
or
Open the file descriptor with os.open(path, os.O_WRONLY | os.O_CREAT | os.O_TRUNC, 0o600) and wrap it with open(fd, 'w').

[jlima8900]

Good catch on the TOCTOU window. You're right — there's a brief moment where the file exists with default umask permissions before chmod is called.

I'll update to use os.open() with explicit mode to eliminate the race:

fd = os.open(path, os.O_WRONLY | os.O_CREAT | os.O_TRUNC, 0o600)
with open(fd, 'w') as f:
    f.write(content)

This way the file is created with 0600 from the start — no window for another process to read it.