开发者

How to generate a client ssh key at each connection?

开发者 https://www.devze.com 2023-04-10 08:32 出处:网络
For now, I think that the public key that is used on a client-side is reused several times (maybe as long as the config dosn\'t change I think). I assume we are using the password method.

For now, I think that the public key that is used on a client-side is reused several times (maybe as long as the config dosn't change I think). I assume we are using the password method.

This worries me. I would prefer my ssh client to开发者_Python百科 automatically generate a RSA key on each connection (but the Client-side key MUST remain the same to ensure authenticity and

Is this possible ?

Thanks.

EDIT : Please see comment #3.


The public key in SSH is used for identifying the client. The private key is used for proving that the user is not an imposter.

The server only knows the public key. If you change it for each connection, it's like changing your username for each connection. So the server knows the user "john", but then you say "I'm Joe". It doesn't matter whether you can prove that you're Joe, the server doesn't know you, so it won't let you in.

It's not like SSL where you use a signed certificate to prove who you are, so you can change the key whenever you want. Here the public key is part of your identity, so you have to use the same one for every connection.


What you are missing is that the public and private keys are cryptographically bound to one another. When the private key is generated, the corresponding public key is as well. Encrypt something with one key and it can only be decrypted with the other. Anyone with the public key can validate that a message can only have come from someone with the private key because of this cryptographic relationship.

When an SSH session starts up, each side uses this property to authenticate the other. During the handshake a secret (technically, it's called a 'nonce' and it's basically a random number) is encrypted with the recipient's public key and then signed with the sender's private key. When this is received, the recipient a) can validate the signature with the sender's public key; and b) is the only one who can possibly decrypt the message. This authenticates the exchange. If this handshake occurs in both directions, it is possible for both sides to validate each other. This is called mutual authentication.

So, it is not the value of the key that is important but rather the cryptographic principle binding the public and private keys. This process provides the ability to create a random session key and exchange it securely using the public/private key pairs and is the heart of how SSH (or SSL or TLS for that matter) fires up a session.

This means the answer to your question is that if SSH is set up for mutual authentication (i.e. you do not need to enter a password), your client's public key must be in the keystore of the server. Since you cannot change the public key without changing the private key it is necessary to reload the public key at the server each time a key change is made.


If you use password authentication, no client side RSA key is used. If you use public key authentication, the client side key obviously can't change every time as the server needs to know it already in order to authenticate you.

You seem to have deep misconceptions about the SSH protocol. I can only suggest to read RFC 4252 to clarify things.

0

精彩评论

暂无评论...
验证码 换一张
取 消

关注公众号