Integration
Integrating OpenSSH into daily usage is not difficult. It can be used as a straightforward method for replacing rlogin, rsh, and telnet for interactive host logins that requires minimal user retraining. It can also provide added security to remote jobs and file transfers, it can tunnel through proxy servers to secure connections to outside the corporate intranet, and it can add single-sign on type convenience. You can also add your desired local configuration to the OBSDssh package for easy deployment.
ssh-agent
Agents perform an action on the behalf of something else. Ssh-agent performs cryptographic operations on the behalf of an ssh process. Instead of an ssh process knowing the key to a remote host, the agent holds the key and does the work. Ssh-agent works by setting two environment variables: SSH_AUTH_SOCK and SSH_AGENT_PID. Because environment variables are inherited by children, setting up ssh-agent when first logging on to an environment like CDE means all terminal window shells will know about the agent and use it if possible. The following example shows a system with ssh-agent running.
host $ env | grep SSH SH_AUTH_SOCK=/tmp/ssh-PNq12519/agent.12519 SSH_AGENT_PID=12520 |
A ssh-agent can do nothing until a key is loaded into it. Once a key is loaded, all of the ssh processes that are aware of that agent may use that key. This provides a form of single signon. The drawback is that if a shell is compromised, whatever access the loaded keys granted may be abused. Agent functionality is used to automate actions and make user's lives easier.
Ssh-add is used to add and list keys (referred to as identities by OpenSSH.) Ssh-agent can remove all keys held in memory and can only add a single key at a time. The following is an example of identity management.
host $ ssh-add Need passphrase for /home/user/.ssh/identity Enter passphrase for user@host <passphrase> Identity added: /home/user/.ssh/identity (user@host) host /opt/OBSDssh $ bin/ssh-add -l 2048 d1:0b:59:c3:ff:8a:20:ff:98:84:15:98:ff:63:e8:41 user@host (RSA1) host $ bin/ssh-add -D All identities removed. host $ bin/ssh-add -l The agent has no identities. |
Autonomous Actions
You can use OpenSSH to greatly improve the security of automated scripts and file transfers. However, note that any kind of unattended authentication still presents security risks. It is recommended that you use plain-text public-key authentication (keys are not protected by a passphrase.) The file permissions of the keys must be strict to ensure that others cannot read them. Even with this obvious flaw, this scheme is more secure than host-based authentication and embedding passwords into scripts.
This process requires more setup than the traditionally insecure method of .rhosts or /etc/host.equiv. You must generate a keyfile with ssh-keygen and distribute it to the remote hosts and the script calling host. Next, replace rsh calls with ssh calls as follows.
rsh host -l user <command> |
ssh host -i keyfile -l user <command> |
Then, replace rcp calls with scp calls as follows.
rcp file user@host:<destination> |
scp -i keyfile file user@host:<destination> |
Sites desiring a more secure approach should use agents. At the system boot time, a user would provide the passphrases needed. This scheme would not work in a lights-out style environment.
Keys do need to be protected. Where security is a concern, load them by hand to prevent tampering. For sites when scalability is the largest concern, place a copy of the keys on your JumpStart™ server and copy them at installation time.
Common Desktop Environment (CDE)
A limited form of single sign on can be accomplished with ssh-agent, an X windows-based passphrase requestor, and some shell code in a user's ~/.dtprofile. Users will enter their passphrases once and will then be able to log in to any host that honors the key from any local shell window. The downside is that the security of the system is limited by the screensaver password and by user vigilance never to leave an unattended, unlocked session.
A fairly simple X passphrase requestor is x11-ssh-askpass available at http://www.ntrnet.net/~jmknoble/software/x11-ssh-askpass/. The tool is simple to build and easy to install. After building the tool, integrate it into OpenSSH by installing it as ssh-askpass in <installpoint>/libexec. You can also integrate this tool into the deployment mechanism. An updated version of makeOpenSSHPackage.ksh will add x11-ssh-askpass if it is present during the OBSDssh package creation.The following are instructions for integration.
$ su - <password> # cp x11-ssh-askpass /usr/local/ssh/libexec/ssh-askpass # cd /usr/local/ssh/libexec # chmod 555 ssh-askpass # chown root:other ssh-askpass |
The following code fragment is needed in the ~/.dtprofile. When the users log in to a CDE session, x11-ssh-askpass (ssh-askpass) prompts them for the passphrases to their keys. If users have multiple keys to add, then successive calls to ssh-add with the keys identity strings will be needed.
# This example is specific to OBSDssh # ssh agent support # if /opt/OBSDssh/bin/ssh-agent does not exist, then do not run. if [ -f /opt/OBSDssh/bin/ssh-agent ]; then eval ´/opt/OBSDssh/bin/ssh-agent' # add keys here. Need one ssh-add per key. Consult the man page. # Only add keys if the X passphrase requestor is present. if [ -x /opt/OBSDssh/libexec/ssh-askpass ]; then /opt/OBSDssh/bin/ssh-add fi fi |
Proxies
You can integrate OpenSSH with a SOCKS proxy with the runsocks command. Unfortunately, this requires the user to type a long command line or requires the creation of a small shell script. The following is an example proxy connection shell script.
#!/usr/bin/ksh # Some sites may require SOCKS_SERVER and LD_LIBRARY_PATH explicitly set /usr/bin/env SOCKS_SERVER=sockserver:1080 LD_LIBRARY_PATH=/usr/local/socks/lib \ /usr/local/socks/bin/runsocks /opt/OBSDssh/bin/ssh remote.host.com |
Within OpenSSH, there is also the ProxyCommand user configuration option. You can use this option to specify a helper application that OpenSSH will read and write to for accessing the remote host. The creation of this application is outside the scope of this article. Consult the man page for ssh(1) and SSH, The Secure Shell for more details.
makeOpenSSHPackage.ksh
You can add local configuration files to the OBSDssh package by replacing sshd_config.out with your server configuration and by replacing ssh_config.out with your global client configuration. Then, run the makeOpenSSHPackage.ksh script to generate the OBSDssh package. You can also modify this script to include x11-ssh-askpass as ssh-askpass into the package as well. (Find the section where the sftp-server executable is packaged.)