Differences
This shows you the differences between the selected revisions of the page.
| ssh 2005-04-28 | ssh 2023-06-05 (current) | ||
| Line 1: | Line 1: | ||
| ====== Understanding SSH ====== | ====== Understanding SSH ====== | ||
| - | SSH is a cryptographically protected remote login protocol | + | SSH is a cryptographically protected remote login protocol that replaces insecure telnet and rlogin protocols. It provides strong protection against password sniffing and third party·session monitoring, better protecting your authentication credentials |
| - | designed to replace the insecure telnet and rlogin protocols. SSH | + | and privacy. In addition, %%SSH%% offers additional authentication methods that are considered more·secure than passwords, such as [[public_key|public key authentication]] and extensive |
| - | provides strong protection against password sniffing and third party | + | |
| - | session monitoring, better protecting your authentication credentials | + | |
| - | and privacy. In addition to protecting your passwords and your privacy, | + | |
| - | SSH offers additional authentication methods that are considered more | + | |
| - | secure than passwords, such as public key authentication, and extensive | + | |
| protection against spoofing. | protection against spoofing. | ||
| - | ===== Authentication in SSH ===== | + | The %%SSH%% employs a public key cryptography that uses [[ssh_keys|two keys pairs, for host and user]]. |
| + | |||
| + | ===== [[authentication]] Authentication in SSH ===== | ||
| SSH servers offer the client a selection of authentication | SSH servers offer the client a selection of authentication | ||
| methods. The server advertises what it supports, and the client | methods. The server advertises what it supports, and the client | ||
| Line 15: | Line 12: | ||
| Generally, the client will choose methods that are the least intrusive | Generally, the client will choose methods that are the least intrusive | ||
| to the user, if they are available. In most cases, the client provides | to the user, if they are available. In most cases, the client provides | ||
| - | the option to choose which methods can be used. | + | the option to choose which methods can be used. In WinSCP, you can configure this on //[[ui_login_authentication|SSH > Authentication page]]// of Advanced Site Settings dialog. |
| - | The actual order of authentication methods is as follows: MIT Kerberos GSSAPI 5 (SSH2 only), public key (using [[ssh#using_pageant_for_authentication|Pageant]]), public key (using [[ui_login_session|configured file]]), keyboard-interactive (SSH2 only), TIS or Cryptocard (SSH1 only), password. | + | The actual order of authentication methods is as follows: [[ui_login_authentication#gssapi|GSSAPI]], [[public key]] (using [[ui_pageant|Pageant]]), public key (using [[ui_login_authentication|configured file]]), keyboard-interactive, password. |
| - | ==== Using Public Keys for Authentication ==== | + | ===== [[verifying_host_key]] Verifying the Host Key ===== |
| - | Public key authentication is an alternative means of identifying yourself to a login server, instead of typing a password. It is more secure and more flexible, but more difficult to set up. | + | To prevent [[wp>Man-in-the-middle_attack|man-in-the-middle attacks]], each SSH server has a unique identifying code, called a host key. These keys prevent a server from forging another server's key. If you connect to a server for the first time or if the server presets a different key than previously, WinSCP will prompt you to [[ssh_verifying_the_host_key|verify the key]]. |
| - | + | ||
| - | In conventional password authentication, you prove you are who you claim to be by proving that you know the correct password. The only way to prove you know the password is to tell the server what you think the password is. This means that if the server has been hacked, or spoofed, an attacker can learn your password. | + | |
| - | + | ||
| - | Public key authentication solves this problem. You generate a key pair, consisting of a public key (which everybody is allowed to know) and a private key (which you keep secret and do not give to anybody). The private key is able to generate signatures. A signature created using your private key cannot be forged by anybody who does not have that key; but anybody who has your public key can verify that a particular signature is genuine. | + | |
| - | + | ||
| - | So you generate a key pair on your own computer, and you copy the public key to the server. Then, when the server asks you to prove who you are, WinSCP can generate a signature using your private key. The server can verify that signature (since it has your public key) and allow you to log in. Now if the server is hacked or spoofed, the attacker does not gain your private key or password; they only gain one signature. And signatures cannot be re-used, so they have gained nothing. | + | |
| - | + | ||
| - | There is a problem with this: if your private key is stored unprotected on your own computer, then anybody who gains access to that will be able to generate signatures as if they were you. So they will be able to log in to your server under your account. For this reason, your private key is usually encrypted when it is stored on your local machine, using a passphrase of your choice. In order to generate a signature, WinSCP must decrypt the key, so you have to type your passphrase. | + | |
| - | + | ||
| - | This can make public-key authentication less convenient than password authentication: every time you log in to the server, instead of typing a short password, you have to type a longer passphrase. One solution to this is to use an authentication agent, a separate program which holds decrypted private keys and generates signatures on request. WinSCP can use PuTTY's authentication agent, called [[&pageanthelp|Pageant]]. When you begin a Windows session, you start Pageant and load your private key into it (typing your passphrase once). For the rest of your session, you can start WinSCP any number of times and Pageant will automatically generate signatures without you having to do anything. When you close your Windows session, Pageant shuts down, without ever having stored your decrypted private key on disk. Many people feel this is a good compromise between security and convenience. | + | |
| - | + | ||
| - | There is more than one public-key algorithm available. The most common is RSA, but others exist, notably DSA (otherwise known as DSS), the USA's federal Digital Signature Standard. ((&puttydoccite)) | + | |
| - | + | ||
| - | ===== Verifying the Host Key ===== | + | |
| - | If you are using WinSCP to connect to a server for the first time, you will probably see a message looking something like this: | + | |
| - | + | ||
| - | ··The server's host key was not found it the cache. You have no guarantee that the | + | |
| - | ··server is the computer you think it is. The server's key fingerprint is: | + | |
| - | ssh-rsa 1024 94:3c:9e:2b:23:df:bd:53:b4:ad:f1:5f:4e:2f:9d:ba | + | |
| - | + | ||
| - | This is a feature of the SSH protocol. It is designed to protect you against a network attack known as spoofing: secretly redirecting your connection to a different computer, so that you send your password to the wrong machine. Using this technique, an attacker would be able to learn the password that guards your login account, and could then log in as if they were you and use the account for their own purposes. | + | |
| - | + | ||
| - | To prevent this attack, each server has a unique identifying code, called a host key. These keys are created in a way that prevents one server from forging another server's key. So if you connect to a server and it sends you a different host key from the one you were expecting, WinSCP can warn you that the server may have been switched and that a spoofing attack might be in progress. | + | |
| - | + | ||
| - | WinSCP records the host key for each server you connect to, in the [[config|configuration storage]]. Every time you connect to a server, it checks that the host key presented by the server is the same host key as it was the last time you connected. If it is not, you will see a warning, and you will have the chance to abandon your connection before you type any private information (such as a password) into it. | + | |
| - | + | ||
| - | However, when you connect to a server you have not connected to before, WinSCP has no way of telling whether the host key is the right one or not. So it gives the warning shown above, and asks you whether you want to trust this host key or not. | + | |
| - | + | ||
| - | Whether or not to trust the host key is your choice. If you are connecting within a company network, you might feel that all the network users are on the same side and spoofing attacks are unlikely, so you might choose to trust the key without checking it. If you are connecting across a hostile network (such as the Internet), you should check with your system administrator, perhaps by telephone or in person. (Some modern servers have more than one host key. If the system administrator sends you more than one fingerprint, you should make sure the one WinSCP shows you is on the list, but it doesn't matter which one it is.) ((&puttydoccite)) | + | |
| - | + | ||
| - | Once the key is verified, you can see it during all future sessions on [[ui_fsinfo#server_hostkey_fingerprint|Server and Protocol Information Dialog]]. | + | |
| ===== Encryption in SSH ===== | ===== Encryption in SSH ===== | ||
| - | A number of encryption methods can be used by SSH clients and | + | SSH clients and·servers can use a number of encryption methods.· |
| - | servers. In the older SSH1 protocol, 3DES and DES are typically used. | + | Most widely used encryption methods in SSH are AES and |
| - | SSH2 adds support for additional encryption methods including AES and | + | Blowfish. By default, %%AES%% is used if supported by the server. While %%AES%% is |
| - | Blowfish. By default, AES is used if supported by the server. AES is | + | considered to be highly secure, %%AES%% encryption requires substantial processor overhead. Blowfish is also considered |
| - | considered to be highly secure, however substantial processor overhead | + | |
| - | is involved in performing AES encryption. Blowfish is also considered | + | |
| secure, but with less computational overhead, it's also theoretically | secure, but with less computational overhead, it's also theoretically | ||
| easier to perform a brute-force attack. Depending on your security and | easier to perform a brute-force attack. Depending on your security and | ||
| performance requirements, you may wish to configure WinSCP to prefer | performance requirements, you may wish to configure WinSCP to prefer | ||
| - | the Blowfish algorithm. 3DES and DES are used with SSH1 servers. DES | + | the %%Blowfish%% algorithm. %%3DES%% and %%DES%% are used with %%SSH-1%% servers. %%DES%% |
| is widely regarded as insecure, as the resources to perform an | is widely regarded as insecure, as the resources to perform an | ||
| exhaustive brute-force attack have been well within the realm of | exhaustive brute-force attack have been well within the realm of | ||
| Line 69: | Line 33: | ||
| ===== SSH Protocols ===== | ===== SSH Protocols ===== | ||
| - | Two major versions of the SSH protocol are in widespread use. | + | Two major versions of the SSH protocol exist, SSH-2 and SSH-1. Most %%SSH%% servers nowadays allow modern and secure %%SSH-2%% only, which is also WinSCP's default. |
| - | The SSH1 protocol is an older version of the SSH protocol that's still | + | |
| - | widely supported despite its age and some technical issues. The SSH2 | + | |
| - | protocol has become the de-facto standard for most installations, | + | |
| - | although there are still a few systems out there only supporting SSH1. | + | |
| - | Additionally, many sites that use SSH2 now disable the SSH1 protocol | + | |
| - | for security reasons. | + | |
| - | The default setting in WinSCP is to prefer SSH2 and negotiate | + | ===== [[compression]] Compression ===== |
| - | down to SSH1 if SSH2 is not available. If the majority of systems you | + | SSH supports data stream compression between the client |
| - | connect to are using SSH2, you may wish to change this setting in the | + | and the server. On slow links, this may increase throughput, while in faster connections the added CPU overhead may actually result in |
| - | SSH preferences. | + | slower transfers, particularly depending on the data type you're transferring. Large text files may still benefit significantly, while |
| - | + | binaries may transfer more slowly. You may want to | |
| - | ===== Compression ===== | + | |
| - | SSH supports compression of the data stream between the client | + | |
| - | and the server. On slow links, this may increase throughput, however, | + | |
| - | with faster connections the added CPU overhead may actually result in | + | |
| - | slower transfers, particularly depending on the type of data being | + | |
| - | transferred - large text files may still benefit significantly, while | + | |
| - | binaries may actually transfer more slowly. You may wish to | + | |
| experiment to find what works best in your situation. Compression may | experiment to find what works best in your situation. Compression may | ||
| - | also improve security slightly, in part by rendering known-cyphertext | + | also improve security slightly, in part by rendering known·cyphertext |
| - | attacks more difficult to execute and by providing less data for | + | attacks more difficult and by providing less data for |
| cryptanalysis. | cryptanalysis. | ||
| + | |||
| + | ===== Supported Algorithms ===== | ||
| + | |||
| + | See list of [[ssh_algorithms|supported SSH algorithms]]. | ||