OpenSSH Version 2 has support for both the SSH-1 and SSH-2 protocols within a single
daemon accepting both types of connections. For SSH1 and SSH2, however, the story is more
complicated.
The SSH2 server can accept connections from SSH1 clients. This compatibility is achieved by having the SSH2 server run the SSH1 server program instead whenever an SSH-1 connection is requested. This compatibility feature is enabled and disabled with the SSH2 Ssh1Compatibility keyword, given a value of yes or no:
command-line option:
# SSH2 only, invoked automatically by sshd2
/usr/local/bin/sshd1 -V "client version string" <other arguments>
The -V command-line option is for internal use only by sshd2. It is necessary because when sshd1 starts this way, the client has already sent its initial version announcement, which sshd1 needs to get somehow. We can't think of any practical reason to use this option manually, but we mention it here for completeness.
When you compile and install SSH2, if SSH1 is already installed, then the configure script [Section 4.1.4] automatically sets the internal, compiled-in defaults for Ssh1Compatibility to yes, and for Sshd1Path to the correct path to sshd1. If SSH1 isn't installed, then the compiled defaults are no for Ssh1Compatibility and the null string for Sshd1Path.
The OpenSSH server also implements the -V option, so that you can use OpenSSH instead of SSH1 for SSH2 backward-compatibility mode.
The SSH2 server can accept connections from SSH1 clients. This compatibility is achieved by having the SSH2 server run the SSH1 server program instead whenever an SSH-1 connection is requested. This compatibility feature is enabled and disabled with the SSH2 Ssh1Compatibility keyword, given a value of yes or no:
# SSH2 only
Ssh1Compatibility yes
When Ssh1Compatibility is enabled, and an SSH-1 client connects to the SSH2 server,
the two programs exchange strings indicating their versions. [Section 3.4.1] sshd2 then locates
the sshd1 executable by examining the value of the Sshd1Path keyword:
# SSH2 only
Sshd1Path /usr/local/bin/sshd1
sshd2 then invokes an sshd1 process, passing the client's version string to sshd1 using the -V
[21]
command-line option:
# SSH2 only, invoked automatically by sshd2
/usr/local/bin/sshd1 -V "client version string" <other arguments>
The -V command-line option is for internal use only by sshd2. It is necessary because when sshd1 starts this way, the client has already sent its initial version announcement, which sshd1 needs to get somehow. We can't think of any practical reason to use this option manually, but we mention it here for completeness.
When you compile and install SSH2, if SSH1 is already installed, then the configure script [Section 4.1.4] automatically sets the internal, compiled-in defaults for Ssh1Compatibility to yes, and for Sshd1Path to the correct path to sshd1. If SSH1 isn't installed, then the compiled defaults are no for Ssh1Compatibility and the null string for Sshd1Path.
The OpenSSH server also implements the -V option, so that you can use OpenSSH instead of SSH1 for SSH2 backward-compatibility mode.
Although sshd2 can accept and reroute SSH1 client connections, the
reverse isn't true: sshd1 can't accept SSH2 connections.
5.9.1 Security Issues with SSH-1 Compatibility Mode in SSH2
There's one vital thing to keep in mind if you're using the SSH-1 compatibility feature in SSH2: you must maintain two separate SSH server configurations. When sshd2 starts sshd1, it is an entirely new process, with its own SSH1 server configuration file. No restrictions set in your SSH2 server configuration apply to it. Even restrictions that could apply, such as AllowHosts, don't, because sshd2 invokes sshd1 before performing such checks.
This means you must keep the two configurations synchronized with respect to your security intent. Otherwise, an attacker can circumvent your carefully crafted SSH2 configuration simply by connecting with an SSH-1 client.
[21]
Note that you need at least Version 1.2.26 (F-Secure 1.3.6) of SSH1 to use the compatibility
mode, since this option isn't implemented in earlier versions.
There's one vital thing to keep in mind if you're using the SSH-1 compatibility feature in SSH2: you must maintain two separate SSH server configurations. When sshd2 starts sshd1, it is an entirely new process, with its own SSH1 server configuration file. No restrictions set in your SSH2 server configuration apply to it. Even restrictions that could apply, such as AllowHosts, don't, because sshd2 invokes sshd1 before performing such checks.
This means you must keep the two configurations synchronized with respect to your security intent. Otherwise, an attacker can circumvent your carefully crafted SSH2 configuration simply by connecting with an SSH-1 client.
[21]
Note that you need at least Version 1.2.26 (F-Secure 1.3.6) of SSH1 to use the compatibility
mode, since this option isn't implemented in earlier versions.
Book: SSH, The Secure Shell: The Definitive Guide
Section: Chapter 5. Serverwide Configuration
5.10 Summary
As you can see, SSH servers have a tremendous number of configuration options, and in some cases, multiple ways to achieve the same results. All this power comes at a price, however. When setting up a secure system, it is vital to consider each option carefully and select appropriate values. Don't skimp on understanding: the security of your systems may depend on it. Chapter 10 lists configurations for SSH1, SSH2, and OpenSSH. In addition,
all the keywords and options in this chapter appear in Appendix B.
Remember that serverwide configuration is only one avenue for affecting server behavior. We discuss compile-time configuration in Chapter 4 and per-account configuration in
Chapter 8.
5.10 Summary
As you can see, SSH servers have a tremendous number of configuration options, and in some cases, multiple ways to achieve the same results. All this power comes at a price, however. When setting up a secure system, it is vital to consider each option carefully and select appropriate values. Don't skimp on understanding: the security of your systems may depend on it. Chapter 10 lists configurations for SSH1, SSH2, and OpenSSH. In addition,
all the keywords and options in this chapter appear in Appendix B.
Remember that serverwide configuration is only one avenue for affecting server behavior. We discuss compile-time configuration in Chapter 4 and per-account configuration in
Chapter 8.
No comments:
Post a Comment