如何在每次连接时生成客户端 ssh 密钥？
目前，我认为在客户端使用的公钥会被重复使用多次（也许只要我认为配置不改变）。我假设我们使用密码方法。
这让我很担心。我希望我的 ssh 客户端在每个连接上自动生成 RSA 密钥（但客户端密钥必须保持不变以确保真实性，
这可能吗？
谢谢。
编辑：请参阅评论 #3。
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 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.
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（3）
SSH 中的公钥用于识别客户端。
私钥用于证明用户不是冒名顶替者。
服务器只知道公钥。如果您为每个连接更改它，就像为每个连接更改您的用户名一样。所以服务器知道用户“john”，但你说“我是 Joe”。你能否证明你是 Joe 并不重要，服务器不认识你，所以不会让你进入。
它不像 SSL，你使用签名证书来证明你是谁，所以你可以随时更改密钥。这里的公钥是您身份的一部分，因此您必须为每个连接使用相同的公钥。
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.
您缺少的是公钥和私钥以加密方式相互绑定。当私钥生成时，相应的公钥也随之生成。用一个密钥加密某些东西，只能用另一个密钥解密。由于这种加密关系，拥有公钥的任何人都可以验证消息只能来自拥有私钥的人。
当 SSH 会话启动时，每一方都使用此属性来验证对方的身份。在握手过程中，秘密（从技术上讲，它被称为“随机数”，基本上是一个随机数）使用接收者的公钥进行加密，然后使用发送者的私钥进行签名。收到此消息后，接收者 a) 可以使用发送者的公钥验证签名； b) 是唯一可能解密该消息的人。这验证了交换。如果握手发生在两个方向，双方就可以互相验证。这称为相互认证。
因此，重要的不是密钥的值，而是绑定公钥和私钥的加密原理。此过程提供了创建随机会话密钥并使用公钥/私钥对安全地交换它的能力，并且是 SSH（或 SSL 或 TLS）如何启动会话的核心。
这意味着您的问题的答案是，如果 SSH 设置为相互身份验证（即您不需要输入密码），则您的客户端的公钥必须位于服务器的密钥库中。由于您无法在不更改私钥的情况下更改公钥，因此每次进行密钥更改时都需要在服务器上重新加载公钥。
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.
如果您使用密码身份验证，则不会使用客户端 RSA 密钥。如果您使用公钥身份验证，则客户端密钥显然不能每次都更改，因为服务器需要知道它才能对您进行身份验证。
您似乎对 SSH 协议有很深的误解。我只能建议阅读 RFC 4252 来澄清问题。
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.