In case you haven't followed the earlier discussion, you may want to have a look at the Apache SSHD project, which implements an SSH server and some parts of the client. The client is far from complete, so it may be a good idea to join our forces: http://svn.apache.org/repos/asf/mina/sshd/trunk/
Currently, the client api is asynchronous, but it would make sense to add a synchronous api for ease of use. In all cases, feel free to reuse any code from this project, as most of the crypto stuff / kex negociation and other algorithms have already been implemented, as there's really no need to duplicate the work. 2009/4/8 Vinod Kumar Badhavat <vinod.ofgov...@gmail.com>: > Hi > > I applied to ASF as a part of Google Summer of Code program for a project - > "Implementation of SSH in Java" , and this implementation may be added to > commons net. > > I have an idea on how to start-off with this. Although I consulted my mentor > with this idea, i'm posting this idea here to get an insight on developing > code. > > /* > * we will have a class called SSHConnect to establish SSH connection. > > * SSHConnect sshCon = new SSHConnect(hostname to which a connection > must be established ) ; > * sshCon.serverAuth(); // used to authenticate server > * // This involves > * // 1.exchange of identification strings > between server and client hosts > * // 2.exchange of SSH_MSG_KEYINIT > * // 3.Algorithm negotiation. > * // 4.Key Exchange algorithm is run - server > authentication is done in this step > * // 5.If 4th step is successful, then exchange > SSH_MSG_NEWKEYS . > * // 6.This ends the Server Authentication > * // If server authentication is successful then everything must go > smoothly and we can proceed to > * user authentication. > * sshCon.userAuthentication(method of authentication, user details ) > ; > * // 1.Now the user name is sent to server. > Already the algorithm negotiation is > * done in serverAuth() method. So we use > these negotiated algorithms to > * compress, encrypted, signed (signature > is used only for user > * authentication. MAC will be used for > further message transmission ) and transported . > * // 2. Server that receives the above message > authenticates the user ( by > * the signature ) and confirms whether it > is communicating with the correct > * user host. > * // 3. Now depending upon the type of > authentication method, user will > * be authenticated. > * // If user authentication is successful then a session is started > and here in session, client will have > * access to SSH features like remote command execution, X11 > forwarding, port forwarding, DSA and RSA key > * generation, SCP etc . > * sshCon.startSession() ; // sending data - data is compressed(if > negotiated) , 'mac' is calculated, > * // encrypted, mac is appended to the > encrypted data and next transported. > * > * > * // The above mentioned is the basic structure how a programmer can > use SSH in his/her program. > * // Now the real task is developing code for this to happen according > to SSH2 standards. > * > * // for server authentication we require > * > * 1.Packet description ( Binary Packet - as mentioned in RFC ) - > * we may have an interface called Packet which is > implemented by all the Packet type classes > * like SSH_MSG_KEYINIT ( there are many such messages ). > Although the basic structure of all > * the packets is same we try to classify them according the > message they convey, because we > * can have methods declared and coded in respective classes > ( ( different packets have > * different information and hence must be handled > differently ). For example SSH_MSG_KEYINIT > * will have some stuff for algorithm negotiation and hence > will be handled in that class > * appropriately. > * > * 2.Algorithm Negotiation - > * we can have a class called AlgoNegotiation and a static > method in this class for negotiation. > * This method will be used when handling SSH_MSG_KEYINIT > * > * 3.Key Exchange Algorithm - > * class named KexAlgo can handle this algorithm > appropriately. We use cryptography algorithms > * defined in java crypto. We may require this class to > create a harmony between crypto classes > * and our implementation ( to take care of correct argument > passing and returned results ). > * > * // TO BE CONTINUED. I'll continue to develop this idea in gradual > steps. > * > * */ > > am I approaching in correct way? You can see that I'm approaching in Top to > Down fashion - i first considered how an user will use this implementation > and then going down to protocol implementation. > > Please suggest me some of developing tips which will be useful for this > project. > > Thank you, > > Vinod Kumar. > -- Cheers, Guillaume Nodet ------------------------ Blog: http://gnodet.blogspot.com/ ------------------------ Open Source SOA http://fusesource.com --------------------------------------------------------------------- To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org