At the start, a copy of the client's public key is stored on the server and the client's private key is on the client, both stay where they are. The process of key-based authentication uses these keys to make a couple of exchanges using the keys to encrypt and decrypt some short message. The comment field at the end of the public key can also be useful in helping to keep the keys sorted, if you have many of them or use them infrequently. Because the key files can be named anything it is possible to have many keys each named for different services or tasks. Keys can be named to help remember what they are for. Longer keys are much slower to work with but provide better protection, up to a point. Shorter keys are faster, but less secure. Ed25519, Ed25519-SK, and ECDSA-SK keys each have a fixed length of 256 bits. ECDSA can be 256, 384 or 521 bits in size. However, there is only limited benefit after 2048 bits and that makes elliptic curve algorithms preferable.
RSA keys are allowed to vary from 1024 bits on up. Even though DSA keys can still be made, being exactly 1024 bits in size, they are no longer recommended and should be avoided. The ssh-keygen(1) utility can make RSA, Ed25519, ECDSA, Ed25519-SK, or ECDSA-SK keys for authenticating. The keys are used in pairs, a public key to encrypt and a private key to decrypt. In public key cryptography, encryption and decryption are asymmetric. OpenSSH can use public key cryptography for authentication.
2.1 Single-purpose Keys to Avoid Remote Root Access.1.3.1 Hardware Security Token Resident Private Key.1.3 Key-based Authentication Using A Hardware Security Token.1.2.1.2 New Style SSH Agent Destination Constraints.1.2.1.1 Old Style, Somewhat Safer SSH Agent Forwarding.1.2 Key-based Authentication Using an Agent.1.1.6 Requiring Certain Key Types For Authentication.1.1.4 Requiring Both Keys and a Password.1.1.1 Associating Keys Permanently with a Server.1.1 Basics of Public Key Authentication.
0 kommentar(er)
