How do I connect to a tumbleweed file server with just a URL and a public key?

I honestly have no idea if tumbleweed can even be accessed like an SFTP using FileZilla or if I need a special SSH file server tool or something.

SFTP is the standard method for transferring files over SSH. If you've been told to upload files over SSH, they most likely mean SFTP, in which case FileZilla or WinSCP would do the job.

(PuTTY itself doesn't have a graphical SFTP client, only a command-line one), but WinSCP is based on the PuTTY core – any server and any key format that PuTTY supports, so does WinSCP.)

From what little information I've been able to find about Axway Tumbleweed, it has a web interface but also accepts SFTP connections via SSH. Apparently it can also act as an SFTP client, pulling files from another SFTP server.

I've been staring at the information they gave us for days and scouring the internet and can't seem to find if what I've been asked to do is even possible. Some articles and answers seem to say "FileZilla and PuTTY are compatible with public keys" and some say "You have to have the PPK file to connect to a remote server".

Those articles and answers (or at least the part you've quoted) conflate quite a few different things, to the point of being useless and misleading.

• Compatibility with the SSH "public-key" authentication mechanism in general. Yes, practically all SSH clients support key-based user authentication.

• Compatibility with the file format used by OpenSSH software to store public and private keys (which usually produces two files, "foo" and "foo.pub").

  Yes, FileZilla and PuTTY can either use the OpenSSH-format key files directly, or convert them into a format that can be used (e.g. PuTTYgen can import them into .ppk files).

  However, out of the two files that OpenSSH's ssh-keygen produces ("somekey" and "somekey.pub"), only the former contains all necessary data – the .pub file alone is not enough.

• Finally, being able to use only a public key to perform SSH "public-key" authentication and log into the server.

  No – despite its name, the authentication mechanism fundamentally requires the use of both the public and private parts of a keypair, and different clients cannot get around this.

So it would make no sense to interpret your article quote as saying that a .pub file alone can be used as a full replacement of a .ppk file – it doesn't contain the necessary data for that; it only happens to usually come with another file that does.

From my understanding of cryptography, sending me their public key makes sense, so my side can encrypt communications using the given key and send it to them and they use their private key to decrypt it, but how do I actually do it?

While this makes sense in theory, that's not how public keys are used in SSH at all. They are not used to encrypt actual communications; they're only used to make digital signatures.

1. At first, SSH uses the DH/ECDH algorithm to establish the encryption key, with the server using its "host key" only to sign the results as well as prove its identity.

2. Later during the login/authentication stage, your client uses your own keypair to prove your identity by signing some random data that the server verifies; at this point encryption has already been enabled and your keypair doesn't affect it in any way.

Can anyone explain to me how I can go about connecting to a server and depositing a file with just this information? Or why my understanding of the situation is flawed and not actually possible? Or both for that matter?

I'm going to say that you cannot connect to the server as you haven't been given enough information. But there could be a few possibilities:

• They gave you the wrong file. For example, the sysadmin created a SSH keypair for you using ssh-keygen, got the "jrud_key" and "jrud_key.pub" files, and meant to email you the former – but accidentally attached the latter.

  This is quite possible, especially if you haven't used SSH keypairs before and the admin wanted to make the process faster by creating a keypair for you.

• They gave you the server's public key, so that you could verify that you're connecting to the real server.

  While possible, this is unlikely. Most sysadmins would either give you the key's fingerprint instead (as that's what your client is going to show you for verification), or wouldn't bother giving anything at all.

  Additionally, if this was the case, they would still have given you some user authentication details – if not a private-key file, then a password, or a request for you to send your own .pub file to them instead.

• They want you to use something else than SSH/SFTP.