On Wednesday, February 4, 2004, at 04:03 AM, Cees de Groot wrote:

> Markus Gaelli  <squeak-dev at lists.squeakfoundation.org> said:
>> Anybody working on ssh?
>>
> Maybe if we ask Cincom really nicely they'll share their SSH package
> with us. Otherwise, we'll probably need to build some OpenSSH-based
> plugin, which - I fear - won't be very simple.
>

Funny you should say that, Cees.  Once upon a time I did an sftp client  
in VW, and it ran on top of an ssh forked process.  I just passed the  
right pipes to the system call, then I could talk over ssh.   There  
were good reasons to impl this rather than callout to the sftp client  
(tty interface and platform independence).  It worked very well and was  
~95% the performance of the *nix native version.  The company I was  
working for sent it Cincoms way, but they probably implemented the  
underlying ssh protocol if they did anything.   Like you, I'd love to  
see that if they did.

As Lex pointed out, it may be possible to wrap a library across  
platforms.  That's gotta be the way to go if you can do it, or is it?   
One interesting thing about implementing your own is that devices that  
run squeak could talk over ssh, where they may not have this library.   
Another interesting aspect is that you could register squeak objects as  
sub-systems.  There may be other reasons, too.

There is some handshaking when sftp connects.  It's not nearly as  
involved as the ssh handshake is going to be, though.   Luckily,  
SqueakElib needed a Diffie-Hillman key exchange, which is undoubtedly  
what ssh uses, so the hankshake logic through key exchange is there  
algorithmically if not in the details, both client and server.  SSL  
would also use this stuff.  Two details that strike me are msg IDs and  
what Msgs are part of a signature check.   One thing we will need is a  
completed x.509 implementation.    ssh can use either RSA or DSA  
certificates, and we'll have to pluck data out of them.  SqueakElib, by  
comparison, uses a partial DSA certificate for key exchange.   
SqueakElib doesn't use the identity and certificate authority fields  
since it avoids third party certificate authorities.    There may be  
other negotiations in the ssh handshake aside from key exchange.

One layer up from the security is probably the ssh session layer and  
this would need to handle the port redirections and subsystem  
invocations and what ever else.

As mundane as implementing something like secsh could be, it would be  
very interesting to have this in the image.   It would take strong  
collaboration to make it happen.

Here are the SECSH RFCs:
http://www.ietf.org/html.charters/secsh-charter.html   (scroll down)

and here is the draft for SFTP:
http://www.ietf.org/proceedings/03mar/I-D/draft-ietf-secsh-filexfer- 
04.txt

Rob