Differences
This shows you the differences between the selected revisions of the page.
2005-04-26 | 2005-05-04 | ||
ssh (martin) | 3.7.5 ssh version syntax (martin) | ||
Line 12: | Line 12: | ||
Each bug can be configured in three states. With //Off// WinSCP will assume that the server does not have the bug. With //On// WinSCP will assume that the server does have the bug. With //Auto// (default) WinSCP will try to guess whether or not the server has the bug. | Each bug can be configured in three states. With //Off// WinSCP will assume that the server does not have the bug. With //On// WinSCP will assume that the server does have the bug. With //Auto// (default) WinSCP will try to guess whether or not the server has the bug. | ||
- | ===== Chokes on SSH1 ignore messages ===== | + | ===== Chokes on SSH-1 ignore messages ===== |
- | An ignore message (SSH_MSG_IGNORE) is a message in the SSH protocol which can be sent from the client to the server, or from the server to the client, at any time. Either side is required to ignore the message whenever it receives it. WinSCP uses ignore messages to hide the password packet in SSH1, so that a listener cannot tell the length of the user's password; it also uses ignore messages for [[ui_login_connection#keepaliaves|connection keepalives]]. | + | An ignore message (SSH_MSG_IGNORE) is a message in the SSH protocol which can be sent from the client to the server, or from the server to the client, at any time. Either side is required to ignore the message whenever it receives it. WinSCP uses ignore messages to hide the password packet in SSH-1, so that a listener cannot tell the length of the user's password; it also uses ignore messages for [[ui_login_connection#keepaliaves|connection keepalives]]. |
- | If this bug is detected, WinSCP will stop using ignore messages. This means that keepalives will stop working, and WinSCP will have to fall back to a secondary defence against [[ui_login_bugs#refuses_all_ssh1_password_camouflage|SSH1 password-length eavesdropping]]. If this bug is enabled when talking to a correct server, the session will succeed, but keepalives will not work and the session might be more vulnerable to eavesdroppers than it could be. | + | If this bug is detected, WinSCP will stop using ignore messages. This means that keepalives will stop working, and WinSCP will have to fall back to a secondary defence against [[ui_login_bugs#refuses_all_ssh_1_password_camouflage|SSH-1 password-length eavesdropping]]. If this bug is enabled when talking to a correct server, the session will succeed, but keepalives will not work and the session might be more vulnerable to eavesdroppers than it could be. |
- | This is an SSH1-specific bug. No known SSH2 server fails to deal with SSH2 ignore messages. | + | This is an SSH-1-specific bug. No known SSH-2 server fails to deal with SSH-2 ignore messages. |
- | ===== Refuses all SSH1 password camouflage ===== | + | ===== Refuses all SSH-1 password camouflage ===== |
- | When talking to an SSH1 server which cannot deal with [[ui_login_bugs#chokes_on_ssh1_ignore_messages|ignore messages]], WinSCP will attempt to disguise the length of the user's password by sending additional padding within the password packet. This is technically a violation of the SSH1 specification, and so WinSCP will only do it when it cannot use standards-compliant ignore messages as camouflage. In this sense, for a server to refuse to accept a padded password packet is not really a bug, but it does make life inconvenient if the server can also not handle ignore messages. | + | When talking to an SSH-1 server which cannot deal with [[ui_login_bugs#chokes_on_ssh-1_ignore_messages|ignore messages]], WinSCP will attempt to disguise the length of the user's password by sending additional padding within the password packet. This is technically a violation of the SSH-1 specification, and so WinSCP will only do it when it cannot use standards-compliant ignore messages as camouflage. In this sense, for a server to refuse to accept a padded password packet is not really a bug, but it does make life inconvenient if the server can also not handle ignore messages. |
If this 'bug' is detected, WinSCP will have no choice but to send the user's password with no form of camouflage, so that an eavesdropping user will be easily able to find out the exact length of the password. If this bug is enabled when talking to a correct server, the session will succeed, but will be more vulnerable to eavesdroppers than it could be. | If this 'bug' is detected, WinSCP will have no choice but to send the user's password with no form of camouflage, so that an eavesdropping user will be easily able to find out the exact length of the password. If this bug is enabled when talking to a correct server, the session will succeed, but will be more vulnerable to eavesdroppers than it could be. | ||
- | This is an SSH1-specific bug. SSH2 is secure against this type of attack. | + | This is an SSH-1-specific bug. SSH-2 is secure against this type of attack. |
- | ===== Chokes on SSH1 RSA authentication ===== | + | ===== Chokes on SSH-1 RSA authentication ===== |
- | Some SSH1 servers cannot deal with RSA authentication messages at all. If Pageant is running and contains any SSH1 keys, WinSCP will normally automatically try RSA authentication before falling back to passwords, so these servers will crash when they see the RSA attempt. | + | Some SSH-1 servers cannot deal with RSA authentication messages at all. If Pageant is running and contains any SSH-1 keys, WinSCP will normally automatically try RSA authentication before falling back to passwords, so these servers will crash when they see the RSA attempt. |
If this bug is detected, WinSCP will go straight to password authentication. If this bug is enabled when talking to a correct server, the session will succeed, but of course RSA authentication will be impossible. | If this bug is detected, WinSCP will go straight to password authentication. If this bug is enabled when talking to a correct server, the session will succeed, but of course RSA authentication will be impossible. | ||
- | This is an SSH1-specific bug. | + | This is an SSH-1-specific bug. |
- | ===== Miscomputes SSH2 HMAC keys ===== | + | ===== Miscomputes SSH-2 HMAC keys ===== |
Versions 2.3.0 and below of the SSH server software from ssh.com compute the keys for their HMAC message authentication codes incorrectly. A typical symptom of this problem is that WinSCP dies unexpectedly at the beginning of the session, saying "Incorrect MAC received on packet". | Versions 2.3.0 and below of the SSH server software from ssh.com compute the keys for their HMAC message authentication codes incorrectly. A typical symptom of this problem is that WinSCP dies unexpectedly at the beginning of the session, saying "Incorrect MAC received on packet". | ||
Line 40: | Line 40: | ||
If this bug is detected, WinSCP will compute its HMAC keys in the same way as the buggy server, so that communication will still be possible. If this bug is enabled when talking to a correct server, communication will fail. | If this bug is detected, WinSCP will compute its HMAC keys in the same way as the buggy server, so that communication will still be possible. If this bug is enabled when talking to a correct server, communication will fail. | ||
- | This is an SSH2-specific bug. | + | This is an SSH-2-specific bug. |
- | ===== Miscomputes SSH2 encryption keys ===== | + | ===== Miscomputes SSH-2 encryption keys ===== |
Versions below 2.0.11 of the SSH server software from ssh.com compute the keys for the session encryption incorrectly. This problem can cause various error messages, such as 'Incoming packet was garbled on decryption', or possibly even 'Out of memory'. | Versions below 2.0.11 of the SSH server software from ssh.com compute the keys for the session encryption incorrectly. This problem can cause various error messages, such as 'Incoming packet was garbled on decryption', or possibly even 'Out of memory'. | ||
Line 48: | Line 48: | ||
If this bug is detected, WinSCP will compute its encryption keys in the same way as the buggy server, so that communication will still be possible. If this bug is enabled when talking to a correct server, communication will fail. | If this bug is detected, WinSCP will compute its encryption keys in the same way as the buggy server, so that communication will still be possible. If this bug is enabled when talking to a correct server, communication will fail. | ||
- | This is an SSH2-specific bug. | + | This is an SSH-2-specific bug. |
- | ===== Requires padding on SSH2 RSA signatures ===== | + | ===== Requires padding on SSH-2 RSA signatures ===== |
- | Versions below 3.3 of [[&openssh|OpenSSH]] require SSH2 RSA signatures to be padded with zero bytes to the same length as the RSA key modulus. The SSH2 draft specification says that an unpadded signature MUST be accepted, so this is a bug. A typical symptom of this problem is that WinSCP mysteriously fails RSA authentication once in every few hundred attempts, and falls back to passwords. | + | Versions below 3.3 of [[&openssh|OpenSSH]] require SSH-2 RSA signatures to be padded with zero bytes to the same length as the RSA key modulus. The SSH-2 draft specification says that an unpadded signature MUST be accepted, so this is a bug. A typical symptom of this problem is that WinSCP mysteriously fails RSA authentication once in every few hundred attempts, and falls back to passwords. |
If this bug is detected, WinSCP will pad its signatures in the way OpenSSH expects. If this bug is enabled when talking to a correct server, it is likely that no damage will be done, since correct servers usually still accept padded signatures because they're used to talking to OpenSSH. | If this bug is detected, WinSCP will pad its signatures in the way OpenSSH expects. If this bug is enabled when talking to a correct server, it is likely that no damage will be done, since correct servers usually still accept padded signatures because they're used to talking to OpenSSH. | ||
- | This is an SSH2-specific bug. | + | This is an SSH-2-specific bug. |
===== Misuses the session ID in PK auth ===== | ===== Misuses the session ID in PK auth ===== | ||
- | Versions below 2.3 of [[&openssh|OpenSSH]] require SSH2 public-key authentication to be done slightly differently: the data to be signed by the client contains the session ID formatted in a different way. If public-key authentication mysteriously does not work but the session log shows that WinSCP has successfully sent a signature, it might be worth enabling the workaround for this bug to see if it helps. | + | Versions below 2.3 of [[&openssh|OpenSSH]] require SSH-2 public-key authentication to be done slightly differently: the data to be signed by the client contains the session ID formatted in a different way. If public-key authentication mysteriously does not work but the session log shows that WinSCP has successfully sent a signature, it might be worth enabling the workaround for this bug to see if it helps. |
- | If this bug is detected, WinSCP will sign data in the way OpenSSH expects. If this bug is enabled when talking to a correct server, SSH2 public-key authentication will fail. | + | If this bug is detected, WinSCP will sign data in the way OpenSSH expects. If this bug is enabled when talking to a correct server, SSH-2 public-key authentication will fail. |
- | This is an SSH2-specific bug. | + | This is an SSH-2-specific bug. |
===== Handles key re-exchange badly ===== | ===== Handles key re-exchange badly ===== | ||
Line 72: | Line 72: | ||
If this bug is detected, WinSCP will never initiate a repeat key exchange. If this bug is enabled when talking to a correct server, the session should still function, but may be less secure than you would expect. | If this bug is detected, WinSCP will never initiate a repeat key exchange. If this bug is enabled when talking to a correct server, the session should still function, but may be less secure than you would expect. | ||
- | This is an SSH2-specific bug. ((&puttydoccite)) | + | This is an SSH-2-specific bug. ((&puttydoccite)) |