- Client Security Settings: Challenges
- SSH Client Security: Workstation Security
- SSH Client Security: Digital Key Security
- SSH Client Security: Hidden Startup Files
Like this article? We recommend
Like this article? We recommend
Like this article? We recommend
SSH Client Security: Hidden Startup Files
Client issues are messy indeed. By now you know that ~/.profile can hide a lot of hacker nuggets, if left unsecured. SSH adds sshrc, a script that is unknowingly executed with user permissions after successful authentication. Make sure that your users know to secure these permissions (to the degree that they might use ~/.profile). Examine the man page for all files sourced by SSH during login or logout, and keep them reasonably secured.
And then panic. Remember, your SSH client can operate with command-line settings, with files on USB drives, etc. The most you can hope to do is put clear policies in place, and attempt to monitor/secure the most common files. You might yank users operating as privileged users, too, but that’s an uphill haul.
I need to conclude this section. It’s doubtful that you can control most SSH client directives. People may install another client, right? Use your network controls to firewall off trusted networks from deeply untrusted networks such as the Internet. Review my article "Mitigating the Security Risks of SSH" for more detail.
I normally don’t stress over client security issues. If an FTP client has a security issue, that risk may not be as immediately actionable as an FTP server’s buffer overflow—the one that gives root. But SSH client software is pretty unique. Hack it, and a basic automation of client startup in the middle of the night creates a gateway into your intranet.
Yes, securing SSH is a challenge that needs a lot of upfront work and planning. If you have any questions about your organization’s implementation, please record them in a response to this article.