How to access a non-trusted SSH server without a password and without providing your private key?

Question

This answer explains how to set up a key-based ssh authentication to avoid re-typing the password at each access.

However, it apparently requires providing the server with a client's private key (No! See Edit.) unless the client's keys are passwordless. In my opinion, this looks unsafe for the client. Is there a way to set up a key-based ssh authentication without providing client information to the server?

For example, by instead storing some server's private key in the client machine? After all, when we log in with a password, we are proving to the server that we (the client) know a piece of information only the server has. Not the opposite.

Personal context: I have a workstation that, in theory, only I have access to, but that is placed in a location subject to password "eyesdropping". So I don't have in it any other files except for the programs I need to run for work. However, I need to access it sometimes via SSH.

Edit: I misunderstood several things. The client's private key is actually NEVER provided to the server. See the accepted answer. I thought that with my public key and my keys' password, anyone could recover my private key, and I also thought that by following the key-based ssh authentication guide I would be providing the server with my public key and my keys' password (unless passwordless), and therefore I would essentially be given my private key (unsafe!). But first of all, the password is not given to the server! The key generation password is only used to decrypt the private key locally (in the client's machine), so the prompt asking for the password is from the client's decrypter, not the server. Second, even if the server had the password and the public key, it could not deduce the private key with that. These and other things are mentioned in the accepted answer.

Answer 1

However, it apparently requires providing the server with a client's private key (or a client's passwordless public key). In my opinion, this looks unsafe for the client. (Do I misunderstand something?)

You misunderstand nearly all of it.

1. The client's private key is never provided to the server. (The post literally says "Upload the public key".) Even during authentication, the private half is not sent as-is – it's only used to create a digital signature as a "proof" that you have the private part; the server verifies the signature using only the public part of the key.

   (It's similar to how TLS works; an HTTPS webserver never sends you their private key for the TLS certificate, only a signature as proof that they have the key.)

2. "Passwordless" does not apply to the public key at all. The password (passphrase) provided during key generation is only used to encrypt the file containing the private part – the public part is, well, public, so there is no need to encrypt it.

   The passphrase is only used for local encryption of the private key file (which is never sent anywhere), so a key being "passwordless" only matters if the client machine is untrusted (e.g. if the file is at risk of being stolen overnight) – the server can't tell the difference as it never gets to see the file, encrypted or not.

3. Providing the public key to an untrusted server is not inherently unsafe, unless an incredibly weak key algorithm was chosen (which is not the case for anything OpenSSH supports).

   Generally, the entire point of public-key cryptography is that it is impossible to derive the private key from knowing only the public key. For example, all of TLS (HTTPS) relies on this assumption; TLS servers routinely send their public keys to clients (as part of the certificate, in order to authenticate the server's identity).

4. Specifically, letting the server know the client's public key does not grant any access to the client – the server cannot just turn around and send the same key to the client to gain access.

   Even if the client happens to accept inbound SSH, and if the client is set up to accept its own key (though that is not unusual), the server couldn't do anything as it doesn't have the corresponding private half to make the "proof" signature with.

   (Which it could do when logging in with a password.)

5. Just like you can use different passwords for different servers, you can also generate different SSH keypairs for different servers; you're not limited to one "client key".

   So if privacy is a concern (e.g. knowing that it's possible to match an SSH public key to a GitHub identity), you're just a ssh-keygen away from having a new one.

For example, by instead storing the server's private key in the client machine? After all, when we log in with a password, we are proving to the server that we (the client) know a piece of information only the server has. Not the opposite.

No, in a sense it is the opposite – you're proving to the server that you (the client) know a piece of information only you (the client) have. The server doesn't even have the actual password, it only has enough information to verify whether the password you sent was correct or not.

Public-key authentication works the same way: you send proof that you know a piece of information (the private key) that only you (the client) have. Except instead of sending the piece of information itself, you only send a proof made with it.

[Comment] Right, but if the server possesses several private keys, and provides one for each of its clients, it can confirm someone is some client, if they show they know the server's private key related to that client, no?

What you described is practically the same as using a password; it ignores all of the features that make private/public keys more secure than passwords. If the server is at risk of eavesdropping, your mechanism would have the same risks as just using a password that's unique for this server.

That would be a way to avoid exposing a client's private key

The client's private key is already never exposed; that's the whole point of using keypairs instead of passwords.

why do they ask me for the password to unlock my private key when I try to do the first login?

The key file is stored encrypted; even though it won't be sent anywhere, your SSH client can't do any local operations with the key either unless it's decrypted first. (Being able to use an encrypted key without decrypting it would rather defeat the point of it being encrypted...)