Printable View
Hy there i have one big problem. Im writing this application for connecting to http server with winsock and it works great but i have one problem. The connection to that server is have to be secured with ssh.
How i do that? Im complitly new to secured connections.
Tnx for help.
Whats SSH? Are you sure you dont mean SSL (Secure Sockets Layer)? Also, what language are you using?
SSL may be what is required, but SSH (Secure SHell) is also possible.
It works differently. The basic idea is "shell" (terminal session) access over a secure channel, but that secure channel can also be used for file transfers via SFTP or SCP as well as tunneling and port-forwarding other traffic securely.
Typically one would run some form of SSH client at the client end. This establishes the secure channel with an SSH server and manages things like port interception/forwarding as well as handling shell and file transfer sessions. I'm unaware of any free component for building this into a VB program, but it is possible for a VB program to run an instance of the free PuTTY or PLink utilities to manage the SSH connection.
Sory, my bad mean ssl
im using VB6
Most of the standard "HTTP request" controls and classes support HTTPS as well as HTTP.
As dilettante said, one control that supports HTTPS is the Inet control.
Nevertheless, this happens to be what you're looking for. Winsock with open source SSL support:
http://www.pscode.com/vb/scripts/Sho...49170&lngWId=1
I like a lot of what I see in this thing, though I doubt it is the best way to go for meeting the OP's needs. It operates at too low a level, providing merely an SSL socket. Of course the code does offer a trivial HTTP implementation in the Form that uses the Class in the downloadable Project.Quote:
Originally Posted by DigiRev
I'd be more likely to suggest the WinHttpRequest Object myself.
As a basic SSL socket though I think it has a lot going for it. There are only three nits I have to pick with it:
- The author fails to state anywhere I can find that it requires Win2K or later.
- More seriously, it fails to do proper License management for the Winsock control it invokes as a Class.
- If a project requires both a regular Winsock (non-SSL) control and this SSL socket class it will get twisted up in its underwear.
Of course all of this is easily remedied. One way would be to rewrite the thing as a UserControl (which it probably should have been in the first place). Another is to rewrite it, still as a VB Class, but including proper License management via the Licenses collection.
Other things could be done such as adding License management and compiling it as a separate DLL. One could also add a property making SSL an optional feature. Either way helps get around the issue of needing both SSL and pass-through socket capability.
Ideally one might turn it into an OCX that exposes the functionality as both a Control and a Class.
Other (much tinier) issues I have with it are:
- It appears to be a client-only implementation.
- It exposes funky member names instead of sticking with Winsock control standards, but VB does make this diificult for names like "Close."
- Parts of it could be rewritten for more clarity and efficiency, but the good news is the "slow" parts only happen once per connection anyway.
Generally I like what I see, and by having the source available all of those options are available to us. Thanks for pointing it out!
Yech!
I've been looking at the code and comparing it to the other Project that much of the logic was taken from.
I see some serious bugs that would intermittently lead to data loss and exceptions (warnings) raised by the Winsock control. These appear to have been fixed in the original Project but not in this (otherwise better) one.
I'm back to my original impressions about everything posted to PSC: Caveat Emptor!
Nothing that can't be fixed though.
Egad, another weirdie! If you're on Win2K without the high-encryption pack (which by Win2K SP4 you'll have, and pre-SP4 Win2K is now unsupported anyway)... the dumb thing asks you whether to start a download from a location that may not exist anymore.
Talk about weird.
Ahh, PSC. The Land of Amateur Code.
Ain't that the truth...there are several really good submissions on there though but littered with a million crappy ones.Quote:
Originally Posted by dilettante
I never looked too far into the SSL code, just checked it out to see if it worked.
When using SSL for webpages, I've always used the Inet control with the Protocol property set to inetHTTPS or whatever it is.
There are some great ideas over there at PSC, and the result of a lot of hard work and occasionally even some brilliant work. Most of it is unpolished and not extensively tested though.
You just need to keep that in mind and go over things carefully. When you have more time than money (for a commercial solution) it can make a lot of sense to see what people have posted.