3 added 18 characters in body
source | link

In the comments OP separated his original question into two different questions, the first of which has already been answered, as pointed out in the comments.

Question 1:

can client public key be used to authenticate server

The answer is no. (See, Does git use the ssh user keys or the repository's deploy keys for encryption?).

Question 2:

is there any harm in being promiscuous with your authentication attempts (e.g., attempting to authenticate at a known-but-potentially-unfriendly server using the client credentials intended for another server)?

Harm can mean various things. But, I think OP is asking about whether or not simply trying to authenticate using ssh keys to a rogue server will somehow leak information about his private key (stored only on his client machine).

With this definition of "harm" the answer is no.

When you try to authenticate to a rogue server, you will receive that server's public key (in its certificate). This will allow you to authenticate the server and you will see that it is rogue and not connect. So, this doesn't expose your private key in any way.

But what about the case where you do attempt to connect to the rogue server? Suppose that the rogue server does have your public key. In this case you still don't leak your private key by attempting to connect, since it is your (ssh) public key that is used by the rogue server to authenticate you. The rogue server can send you a challenge encrypted with your public key. Then you can decrypt it with your private key and prove you are who you say you are. You only send back the decrypted challenge, you don't send your private key or any info about your private key. And this should not leak any information about your private key (with the caveat that I'm assuming that modern public key crypto such as RSA and/or ssh is/are not broken).

I would also like to reemphasize that fact that I'm assuming the question is only directed asat connection attempts. I'm not considering the fact that a rogue server might spoof a user/pass login and harvest your credentials that way, or some other malicious behavior such as logging your IP for a subsequent retaliatory attack, etc.

In the comments OP separated his original question into two different questions, the first of which has already been answered, as pointed out in the comments.

Question 1:

can client public key be used to authenticate server

The answer is no. (See, Does git use the ssh user keys or the repository's deploy keys for encryption?).

Question 2:

is there any harm in being promiscuous with your authentication attempts (e.g., attempting to authenticate at a known-but-potentially-unfriendly server using the client credentials intended for another server)?

Harm can mean various things. But, I think OP is asking about whether or not simply trying to authenticate using ssh keys to a rogue server will somehow leak information about his private key (stored only on his client machine).

With this definition of "harm" the answer is no.

When you try to authenticate to a rogue server, you will receive that server's public key (in its certificate). This will allow you to authenticate the server and you will see that it is rogue and not connect. So, this doesn't expose your private key in any way.

But what about the case where you do attempt to connect to the rogue server? Suppose that the rogue server does have your public key. In this case you still don't leak your private key by attempting to connect, since it is your (ssh) public key that is used by the rogue server to authenticate you. The rogue server can send you a challenge encrypted with your public key. Then you can decrypt it with your private key and prove you are who you say you are. You only send back the decrypted challenge, you don't send your private key or any info about your private key. And this should not leak any information about your private key (with the caveat that I'm assuming that modern public key crypto such as RSA and/or ssh is not broken).

I would also like to reemphasize that fact that I'm assuming the question is only directed as connection attempts. I'm not considering the fact that a rogue server might spoof a user/pass login and harvest your credentials that way, or some other malicious behavior such as logging your IP for a subsequent retaliatory attack, etc.

In the comments OP separated his original question into two different questions, the first of which has already been answered, as pointed out in the comments.

Question 1:

can client public key be used to authenticate server

The answer is no. (See, Does git use the ssh user keys or the repository's deploy keys for encryption?).

Question 2:

is there any harm in being promiscuous with your authentication attempts (e.g., attempting to authenticate at a known-but-potentially-unfriendly server using the client credentials intended for another server)?

Harm can mean various things. But, I think OP is asking about whether or not simply trying to authenticate using ssh keys to a rogue server will somehow leak information about his private key (stored only on his client machine).

With this definition of "harm" the answer is no.

When you try to authenticate to a rogue server, you will receive that server's public key (in its certificate). This will allow you to authenticate the server and you will see that it is rogue and not connect. So, this doesn't expose your private key in any way.

But what about the case where you do attempt to connect to the rogue server? Suppose that the rogue server does have your public key. In this case you still don't leak your private key by attempting to connect, since it is your (ssh) public key that is used by the rogue server to authenticate you. The rogue server can send you a challenge encrypted with your public key. Then you can decrypt it with your private key and prove you are who you say you are. You only send back the decrypted challenge, you don't send your private key or any info about your private key. And this should not leak any information about your private key (with the caveat that I'm assuming that modern public key crypto such as RSA and/or ssh is/are not broken).

I would also like to reemphasize that fact that I'm assuming the question is only directed at connection attempts. I'm not considering the fact that a rogue server might spoof a user/pass login and harvest your credentials that way, or some other malicious behavior such as logging your IP for a subsequent retaliatory attack, etc.

2 added 18 characters in body
source | link

In the comments OP separated his original question into two different questions, the first of which has already been answered, as pointed out in the comments:.

Question 1:

can client public key be used to authenticate server

The answer is no. (See, Does git use the ssh user keys or the repository's deploy keys for encryption?).

Question 2:

is there any harm in being promiscuous with your authentication attempts (e.g., attempting to authenticate at a known-but-potentially-unfriendly server using the client credentials intended for another server)?

Harm can mean various things. But, I think OP is asking about whether or not simply trying to authenticate using ssh keykeys to a rogue server (a server that does not have his public key) will somehow leak information about his private key (stored only non his client machine).

With this definition of "harm" the answer is no.

When you try to authenticate to a rogue server, you will receive that server's public key (in theirits certificate). This will allow you to authenticate the server and you will see that it is rogue and not connect. So, this doesn't expose your private key in any way.

But what about the case where you do attempt to connect to the rogue server? Suppose that the rogue server does have your public key. In this case yuoyou still don't leak theyour private key by attempting to connect, since it is theyour (ssh) public key that is used by the rogue server to authenticate you. The rogue server can send you a challenge encrypted with your public key. Then you can decrypt it with your private key and prove you are who you say you are. You only send back the decrypted challenge, you don't send your private key or any info about your private key. And this should not leak any information about your private key (with the caveat that I'm assuming that modern public key crypto such as RSA and/or ssh is not broken).

I willwould also like to reemphasize, that fact that I'm assuming the question is only directed as connection attempts. I'm not considering the fact that a rogue server might spoof a user/pass login and harvest your credentials that way, or some other malicious behavior such as logging your IP for a subsequent retaliatory attack, etc.

OP separated his question into two different questions, the first of which has already been answered, as pointed out in the comments:

Question 1:

can client public key be used to authenticate server

The answer is no.

Question 2:

is there any harm in being promiscuous with your authentication attempts (e.g., attempting to authenticate at a known-but-potentially-unfriendly server using the client credentials intended for another server)?

Harm can mean various things. But, I think OP is asking about whether or not simply trying to authenticate using ssh key to a rogue server (a server that does not have his public key) will somehow leak information about his private key (stored only n his client machine).

With this definition of "harm" the answer is no.

When you try to authenticate to a rogue server, you will receive that server's public key (in their certificate). This will allow you to authenticate the server and you will see that is rogue and not connect. So, this doesn't expose your private key in any way.

But what about the case where you do attempt to connect to the rogue server? Suppose that the rogue server does have your public key. In this case yuo still don't leak the private key by attempting to connect, since it is the public key that is used by the rogue server to authenticate you. The rogue server can send you a challenge encrypted with your public key. Then you can decrypt it with your private key and prove you are who you say you are. You only send back the decrypted challenge, you don't send your private key or any info about your private key. And this should not leak any information about your private key (with the caveat that I'm assuming that modern public key crypto such as RSA is not broken).

I will also reemphasize, that I'm assuming the question is only directed as connection attempts. I'm not considering the fact that a rogue server might spoof a user/pass login and harvest your credentials that way, or some other malicious behavior such as logging your IP for a subsequent retaliatory attack, etc.

In the comments OP separated his original question into two different questions, the first of which has already been answered, as pointed out in the comments.

Question 1:

can client public key be used to authenticate server

The answer is no. (See, Does git use the ssh user keys or the repository's deploy keys for encryption?).

Question 2:

is there any harm in being promiscuous with your authentication attempts (e.g., attempting to authenticate at a known-but-potentially-unfriendly server using the client credentials intended for another server)?

Harm can mean various things. But, I think OP is asking about whether or not simply trying to authenticate using ssh keys to a rogue server will somehow leak information about his private key (stored only on his client machine).

With this definition of "harm" the answer is no.

When you try to authenticate to a rogue server, you will receive that server's public key (in its certificate). This will allow you to authenticate the server and you will see that it is rogue and not connect. So, this doesn't expose your private key in any way.

But what about the case where you do attempt to connect to the rogue server? Suppose that the rogue server does have your public key. In this case you still don't leak your private key by attempting to connect, since it is your (ssh) public key that is used by the rogue server to authenticate you. The rogue server can send you a challenge encrypted with your public key. Then you can decrypt it with your private key and prove you are who you say you are. You only send back the decrypted challenge, you don't send your private key or any info about your private key. And this should not leak any information about your private key (with the caveat that I'm assuming that modern public key crypto such as RSA and/or ssh is not broken).

I would also like to reemphasize that fact that I'm assuming the question is only directed as connection attempts. I'm not considering the fact that a rogue server might spoof a user/pass login and harvest your credentials that way, or some other malicious behavior such as logging your IP for a subsequent retaliatory attack, etc.

1
source | link

OP separated his question into two different questions, the first of which has already been answered, as pointed out in the comments:

Question 1:

can client public key be used to authenticate server

The answer is no.

Question 2:

is there any harm in being promiscuous with your authentication attempts (e.g., attempting to authenticate at a known-but-potentially-unfriendly server using the client credentials intended for another server)?

Harm can mean various things. But, I think OP is asking about whether or not simply trying to authenticate using ssh key to a rogue server (a server that does not have his public key) will somehow leak information about his private key (stored only n his client machine).

With this definition of "harm" the answer is no.

When you try to authenticate to a rogue server, you will receive that server's public key (in their certificate). This will allow you to authenticate the server and you will see that is rogue and not connect. So, this doesn't expose your private key in any way.

But what about the case where you do attempt to connect to the rogue server? Suppose that the rogue server does have your public key. In this case yuo still don't leak the private key by attempting to connect, since it is the public key that is used by the rogue server to authenticate you. The rogue server can send you a challenge encrypted with your public key. Then you can decrypt it with your private key and prove you are who you say you are. You only send back the decrypted challenge, you don't send your private key or any info about your private key. And this should not leak any information about your private key (with the caveat that I'm assuming that modern public key crypto such as RSA is not broken).

I will also reemphasize, that I'm assuming the question is only directed as connection attempts. I'm not considering the fact that a rogue server might spoof a user/pass login and harvest your credentials that way, or some other malicious behavior such as logging your IP for a subsequent retaliatory attack, etc.