Sending a file - need creative ideas

[Guest s_mack]

I'm writing a script that connects the client to the server via ssh and uses ssh key pairs. So before those pairs exist (private on the client side and public on the server side) the connection can not be made. So I need some 100% works-every-time method of sending the public keys from the client to the server (in a manner that I can trust that the client is who the client says they are).

I'm doing inital authentication via a password scheme that I don't want to post for public scrutiny, but that side of it works (that is, I know the client is who they say they are). Now all i need is the transfer.

Here are the possibilities I've thought of:

• Send via email (various implimentations
• Send via FTP
• Post to a cgi script on a webserver

But the all have problems! Email is chalk full of them because I can't guarantee that they have a default email client setup (so I can't use _INetMail), I don't want to ask them for their SMTP info, and I can't assume their ISP hasn't blocked port XX (many ISPs block port 25 unless using their SMTP server). FTP's issue is there doesn't appear to be a built-in client that I can use or be assured they have (is there?) plus it depends on an FTP server to be running and voids me of any chance at having a notification to know a file is there! That leaves posting to a website... I didn't have a problem with this until testing showed that sometimes Windows crashes when attempting to open the default browser. That made me think too that some systems (*nix geeks especially) aren't going to have "default" browsers that simply open up when you ask to go to a web address.

Is there some method that you can think of that will work 100% of the time (assuming I've already successfully checked that they have an active Internet connection) or at least 99.9% of the time on all types of client systems that I have no control over?

I glanced at the TCPmail topics but they still have the problem of possibly blocked SMTP ports, I believe.

Thanks!!

- Steven

[Nuffilein805]

i think about converting the files to binary or hex - send them to the client - convert them back

but my problem is, that i don't have a clue how to get files from unicode to hex or bin

[Guest s_mack]

Perhaps I wasn't clear. I'm going from the client to the server, not the other way around. Key pair is generated at the client and they send the public key to the server. Well.. that's not true either lol... they send the public key to ME, and I put it on the server (manually - prevents auto-nastiness).

Also, the public key doesn't really need to be look at as a "file" if it helps... it is simply text. So really, I just need a sure-fire way of sending a string of text from the AutoIt script on the client's computer to ME - using any method at our disposal provided it is available across all Windows machines and VERY unlikely that the user does not have said method available to them. So either a built-in function of AutoIt or a command line (freeware GNU) that I can package in but that doesn't depend on settings that may or may not be available to the client (like port 25 as an example, as explained above).

_ Steven

[themax90]

Check My TCP Made Easy funcs, TCP Communicator, ITS Chat Project, and other things. You need to use either TCP or UDP communication in the current beta.

$String = "ID"
TCPSend($ConnectedSocket, $String)

It is simple, just read up on it.

[Guest s_mack]

Sorry... where do I read up on it? I'm more than happy to read Just not sure where to look. I searched for "TCP Made Easy" and found only this thread, a couple of other references you made to it, and your post that shows the code... but nothing that allows me to "read up on it".

Thanks!

- Steven

[Guest s_mack]

If I'm even beginning to get the gist of it... I don't think this will work. It still depends on assuming the client's IP isn't blocking port 25, if you're suggesting I use TCP to generate an email.

If you aren't suggesting that, the it would involve having a server running on my end that is capable of accepting a direct TCP connection and that's not going to happen for the very reason I need to receive the data in the first place - I can not trust the data connection to the server UNTIL I first receive the data! (cart before the horse).

I suppose I could set up a second server soley for the purpose of accepting public keys but that seems wasteful.

I'm probably missing something... I'll attempt to keep digging but I fear this isn't the right path.

- Steven

[seandisanti]

I'm writing a script that connects the client to the server via ssh and uses ssh key pairs. So before those pairs exist (private on the client side and public on the server side) the connection can not be made. So I need some 100% works-every-time method of sending the public keys from the client to the server (in a manner that I can trust that the client is who the client says they are).

I'm doing inital authentication via a password scheme that I don't want to post for public scrutiny, but that side of it works (that is, I know the client is who they say they are). Now all i need is the transfer.

Here are the possibilities I've thought of:

• Send via email (various implimentations

• Send via FTP

• Post to a cgi script on a webserver

But the all have problems! Email is chalk full of them because I can't guarantee that they have a default email client setup (so I can't use _INetMail), I don't want to ask them for their SMTP info, and I can't assume their ISP hasn't blocked port XX (many ISPs block port 25 unless using their SMTP server). FTP's issue is there doesn't appear to be a built-in client that I can use or be assured they have (is there?) plus it depends on an FTP server to be running and voids me of any chance at having a notification to know a file is there! That leaves posting to a website... I didn't have a problem with this until testing showed that sometimes Windows crashes when attempting to open the default browser. That made me think too that some systems (*nix geeks especially) aren't going to have "default" browsers that simply open up when you ask to go to a web address.

Is there some method that you can think of that will work 100% of the time (assuming I've already successfully checked that they have an active Internet connection) or at least 99.9% of the time on all types of client systems that I have no control over?

I glanced at the TCPmail topics but they still have the problem of possibly blocked SMTP ports, I believe.

Thanks!!

- Steven

AutoIT actually may not be the solution you're looking for in this case, if it's expected to run on non-windows systems. And even if you're 100% sure that they'll all be using windows, it sounds like you're deploying to an unknown environment, and there are going to be things outside of your control. Example, even if the end-user's ISP doesn't block port 25, they may have a firewall or router that does. Your best bet to ensure that your solution doesn't make use of the program impossible for someone else, would be to either give them a few choices for how it should be transmitted (maybe a GUI where they pick e-mail, tcp, webpage), or worst case scenario, to have the keys generated, and tell them where to e-mail them to, making it their responsibility to get them to you.

[MSLx Fanboy]

InetGet works as long as IE4(?) is installed on the system. Just create a cgi or php document that will output only the data you need (not html, you would have to parse it then).

[Guest s_mack]

cameronsdad - that's interesting because that's exactly what I did the first time around (a few versions ago) was give them the choices... but it was messy and proved to still confuse the less adept users (some of these clients barely know not to give the mouse cheese to make it run). Your final comment about letting them email it to me and making it their responsibility probably still leaves a tiny percentage that would be lost, but would probably reduce the amount of errors and confusion to the most people. One of the least elegant options, but most likely the most effective Thanks for that.

Fanboy. That was my first though... but then I got to wondering about that IE4 (I think its 3) requirement. Some people are very anti-MS... I'm not one of them. I happilly hum along in my totalitarian bliss using my latest version of IE because it works... but there are a growing number that do everything they can to strip out everything MS related they possibly can and my thoughts were that if I'm relying on their system to automatically pop open a browser (well, not really the case with INetGet but same idea) then I could be leaving them with the possibility of clicking the button and absolutely nothing occuring.

Although I could introduce error checking to then resort back to "just email it" in the case it fails.

Ahh... that might very well be it then! Because IF they are geek enough (meant in the most endearing sense of the word) to strip out IE3/4+ from their system then they are certainly savvy enough to figure out how to copy/paste and email me some text!

It may not be what I was after, but it certainly fits the bill!

Meanwhile though, I did take a closer look at AutoIt Smith's TCP suggestion and that's what I have semi-implemented in my beta right now. The *only* problem I have with that is not knowing if their ISP is blocking port 25... other than that it works great!

Alas, this whole project (a personal one) has to take a back seat to the other (work related) one I'm working on right now.

I thank you all for your suggestions!

- Steven