The SSH agent is a simple utility that allows end-users to handle passphrases attached to public-key files in a simpler way. If multiple passphrases are being used with multiple public keys, it may be cumbersome for the end-user to type and retype all the passphrases several times. The SSH agent utility remembers your passphrases for you after the first time you have authenticated with the passphrase. It is a utility that remembers your private keys and provides the authentication portion to other SSH connections. Therefore, after you initially authenticate with your passphrase, the SSH agent will prevent subsequent SSH sessions from asking you for your passphrase. The process to enable SSH agents involves the following four steps:
ssh-agent bash
ssh-add <privatekeyfile> (e.g. ssh-add Shreya) ssh –i OpenSSHPrivateKey <IP Address>
SSH Communications:
ssh-agent2 bash
ssh-add2 <privatekeyfile> (e.g. ssh-add2 id_dsa_2048_a) ssh2 –i identification <IP Address>
Summary
This chapter discusses the various authentication options available in SSH. It should be noted that many of the authentication options, such as password attempts, are separate from the operating-system authentication options. For example, the operating system could have a password-attempts threshold at 5, while the SSH service has a password-attempts threshold at 3. While SSH servers on both Windows and Unix platforms use the local username/pass- word database for authentication, such as /etc/shadow or the SAM database, the SSH servers can have additional or similar authentication options. Fur- thermore, while SSH servers are using the same password database, the actual authentication options apply to different services. For example, to log on to a Windows service requires the use of SMB, which may have authentication options tied to it. These authentication options are separate from the authenti- cation options that apply to the SSH service on the operating system, even though both SMB and SSH are using the SAM database file.
While certain authentication options are discussed in detail in this chapter, such as password, public-key, and host-based authentication, there are several other authentications options, such as SecureID and Certificates, which are not discussed. Both SecureID and Certificate-based authentication are strong authentication methods but require the use of several other servers and/or
tional and security requirements for the application. The following is a list of questions and answers to ask when trying to determine which method of authentication is acceptable and/or optimal.
■■ Does the corporate culture enforce strong passwords? ■■ Yes. Password authentication is an acceptable option. ■■ No. Consider public-key authentication.
■■ Will access be from trusted segments?
■■ Yes. Host-based authentication is an acceptable option. ■■ No. Rely on passwords and public keys for authentication. ■■ Will the SSH service/daemon be facing the public Internet?
■■ Yes. Consider public-key authentication.
■■ No. Password authentication is an acceptable option. ■■ Will remote users be connecting from predefined locations?
■■ Yes. Consider adding host-based authentication. ■■ No. Public-key authentication is an acceptable option. ■■ Are the SSH servers in a layered security architecture?
■■ Yes. Passwords and public keys are acceptable options. ■■ No. Consider using server authentication.
■■ Are multiple SSH servers utilized in the environment? ■■ Yes. Consider using public keys.
■■ No. Passwords are an acceptable option.
Now that you understand all the authentication options with SSH and how to use them across different SSH servers, you will now shift your focus to man- aging servers/devices that are SSH enabled. Knowing and using different authentication methods in SSH is critical to fully understanding the security implications that exist in terms of server/device management, as well as the functional uses that SSH can enable in the process.
155
Thus far, I have described SSH in terms of application servers or SSH client applications. While using applications such as VanDyke Software’s VShell, SSH Communications’ SSH, and OpenSSH, or core SSH server utilities, SSH services can also be available without any of these applications. SSH services are also available on network devices such as routers, switches, firewalls, load balancers, and storage filers. These services on network devices provide the same type of secure access that SSH applications provide. Furthermore, the SSH services on these devices provide secure management capabilities while replacing insecure clear-text protocols such as Telnet, FTP, and/or SNMP.
In addition to SSH services being available on network hardware, SSH ser- vices can be integrated with other security utilities. Utilities such as Chroot, user restrictions, TCP wrappers, and IP access filters can be used with SSH to complement and enhance the overall security of network management.
Secure management is often overlooked when it comes to security. Many organizations and corporations deploy a strong perimeter defense with multi- ple firewalls and router-access control lists; however, they also use poor man- agement protocols that weaken the entire network environment. For example, for remote business travelers, the use of encryption to gain access to e-mail or internal file servers is usually a requirement, either through SSH port for- warding (described in Chapters 6 and 7) or IPSec. In spite of this, many net- work administrators use Telnet to access perimeter devices such as routers, firewalls, and switches in order to conduct remote management. The odd thing
used. For example, many network devices may not support standard encryp- tion protocols such as SSH for remote management. While these devices can- not support encryption, other mitigating controls should be set, such as access-control lists, which can limit access from a predefined set of IP addresses and enforce two-factor authentication.
This chapter addresses the following features of SSH: