Differences

This shows you the differences between the selected revisions of the page.

ui_login_authentication 2023-02-13 ui_login_authentication 2024-09-20 (current)
Line 50: Line 50:
The passphrase cannot be entered in advance in session settings and thus it cannot be saved to [[session_configuration#site|site]]. If you need to login to server automatically without prompt, generate a key without passphrase. Use this method carefully and only under special circumstances. The passphrase cannot be entered in advance in session settings and thus it cannot be saved to [[session_configuration#site|site]]. If you need to login to server automatically without prompt, generate a key without passphrase. Use this method carefully and only under special circumstances.
-If you select a key file in a different format (OpenSSH or ssh.com), WinSCP will offer you to convert the key to PuTTY format.+If you select a key file in a different format (OpenSSH or ssh.com), WinSCP will offer you to ==convert== the key to PuTTY format. If certificate file with the same name((but ''-cert.pub'' or ''.pub-aadcert.pub'' //(latest beta only)// &beta suffixes.)) is found, it will be automatically added to the converted key file.
=== [[private_key_tools]] Private Key Tools === === [[private_key_tools]] Private Key Tools ===
Line 62: Line 62:
==== [[certificate]] Certificate to use with the private key ==== ==== [[certificate]] Certificate to use with the private key ====
-In some environments, user authentication keys can be signed in turn by a certifying authority (CA for short), and user accounts on an SSH server can be configured to automatically trust any key that's certified by the right signature.+In some environments, user authentication keys can be signed in turn by a certifying authority (CA for short), and user accounts on an SSH server can be configured to automatically trust any key that's certified by the right signature. This is optional. If you don't know you need it, you can leave this blank.
This can be a convenient setup if you have a very large number of servers. When you change your key pair, you might otherwise have to [[guide_public_key#configure_openssh|edit the ''authorized_keys'' file]] (in case of OpenSSH) on every server individually, to make them all accept the new key. But if instead you configure all those servers once to accept keys signed as yours by a CA, then when you change your public key, all you have to do is to get the new key certified by the same CA as before, and then all your servers will automatically accept it without needing individual reconfiguration. This can be a convenient setup if you have a very large number of servers. When you change your key pair, you might otherwise have to [[guide_public_key#configure_openssh|edit the ''authorized_keys'' file]] (in case of OpenSSH) on every server individually, to make them all accept the new key. But if instead you configure all those servers once to accept keys signed as yours by a CA, then when you change your public key, all you have to do is to get the new key certified by the same CA as before, and then all your servers will automatically accept it without needing individual reconfiguration.

Last modified: by martin