CSE 199 Independent Study for Undergraduates Proposal
Winter Quarter 1998
UCSD ACM Windows Secure Shell Project
Proposal Written by: Timothy Chen, Co-Chair UCSD ACM
Team Members
The Windows NT/95 SSH Project Team:
Tim is the "project leader" for administrative and coordination purposes.
Faculty Sponsors
The following faculty have expressed interest in sponsoring our project:
-
Professor Burkhard - (burkhard@cs.ucsd.edu)
-
Professor Kube (kube@cs.ucsd.edu)
-
Professor Yee (bsy@cs.ucsd.edu)
Goal
To write a free Secure Shell Client (ssh) for Windows 95/NT 4.0 by the
end of Winter Quarter 1998. Seeking 4 units of technical elective
credit towards department graduation requirement. This will be the
first CSE 199 for all team members involved in the project.
Summary
Tatu Yloenen at the Helsinki University of Technology created the SSH specificiation
back in 1995 that allowed users to create secure telnet sessions, execute
remote commands securely, and copy files protected by encryption remotely.
While there have been numerous ports to the UNIX environment that are freely
available, a Windows 95/NT port is NOT freely available. The majority
of students on campus who have a Windows machine are unable to guarantee
a secure connection unless they install some x86 flavor of UNIX.
It was felt that it would be beneficial to produce such a client for UCSD
students and the general computing community and enable them to protect
themselves from malicious network snoopers.
Short History
The original suggestion for the SSH client was suggested by Jambi at a
weekly Assocation for Computing Machinery Chapter (ACM) meeting.
Tim had suggested that with the increase of members, the group might consider
tackling a software project to increase ACM visibility. Furthermore
this would be an opportunity to tackle a programming project outside of
class and of interest to the group. Jambi's suggestion of a SSH Java
Client immediately caught everyone's interest. At a later meeting
it was discussed that the project could be proposed as a possible CSE 199,
thus giving the group members incentive. It was agreed upon that
the eventual product was to be released as freeware for the general computing
public to use. A succesful project outcome would not only improve
the visibility of the ACM group at UCSD, it would also provide good publicity
for the CSE Department at UCSD. And of course, the team members would
experience working in a team project and learn about SSH. A win-win
situation for all those involved.
To ensure that the product remain free, it was agreed upon that all
development of the client would take place on individual computers; thus
making no use of University resources. Source control would be kept
at a central server computer provided by a team member. The Java
SSH Group slowly swelled in size till Tim decided that a separate effort
could concentrate on producing a platform specific client for Windows NT/95
as there were no free stable clients for that platform.
Tim, Mike, and Doug thus formed the UCSD ACM SSH Win95/NT Project Team
with the intent of producing a stable Windows 95/NT client by the end of
Winter Quarter 1998. Preliminary research on the SSH specification
started and information was centrally placed at this location for all team
members to use. The original feeling was that it would not be a difficult
task to port the SSH UNIX code to the Windows GUI. Unfortunately
this proved to be a naive assumption. The group's original intention
was to only create a SSH client. The SSH distribution was bundled
with shared code between ssh (the client), sshd (the daemon), and scp (secure
copy). After careful perusal of the code it became clear that a simple
port would not be feasible. To implement the various encryption algorithms
used in SSH the GNU GMP library was used for the arbitrary precision arithmetic
required. In it's current implementation GMP is designed to be compiled
with gcc and also used a fair amount of platform specific assembly code
to increase code performance. The Windows team was planning to use
Microsoft Visual C++ 5.0 for their development work and as such it would
not be practical to port the assembly.
The team thus pursued the option of writing a SSH client from scratch
by following the current proposed RFC specification. Instead of writing
the cryptography functions from scratch the group decided that a publicly
available cryptography library would be used instead.
A separate ACM group will be working on porting SSH to Java. The
two groups will probably collaborate on UI design and documentation. The
collaboration will be reduced to these elements due to the differences
in GUI programming between Windows and Java (and the differences between
C++ and Java). As a result code sharing will be impractical.
If it is determined during the quarter that there is no reason to continue
collaboration, this effort will be terminated.
Project Resources
A list of resources and information has been gathered here http://www.massconfusion.com/ssh/.
Development Tools
All development will take place on home computers owned by the Team Members.
Source control will be centralized on a non-university server. We'll
be compiling with Microsoft Visual C++ 5.0 on Microsoft Windows NT Workstation
4.0 SP3.
Project Features / Wish List
At the very least, we'd like to have a minimally functional SSH GUI client
with VT100 terminal emulation by the end of Winter Quarter 1998.
Hopefully a more feature rich version will be completed though. A
few wish list items (more will surely be added):
-
Auto-detection of terminal capability beyond VT100.
-
Ability to choose different proportional true-type fonts and allow user
to change foreground/background colors.
-
Allow dynamic resizing of window row and column size.
-
A scroll buffer would be nice.
-
And to remember all these settings when the program is restarted.
-
Works as seamless telnet client also. Similar to Netscape's "lock/unlock"
concept, an initial connection to a server would first try the SSH port
and authenticate. If not possible, use the telnet protocol instead.
This would allow users to use one client for shell sessions. A similiar
"lock/unlock" user design would alert the user on whether or not he was
on a secure connection.
Initial Research
Currently the group has finished the intial research on the project and
confident of the project's feasibility. Microsoft Foundation Classes
(MFC) in C++ will be used to allow rapid development and integration of
GUI elements rather than the WinAPI based on C. While some would
argue that an WinAPI implementation provides faster code, it was decided
that a rapid development outlook would be more approppiate in this case
as the limiting factor here would most likely be network speeds rather
than the computer itself.
To ensure a succesful project, some rapid development and software engineering
concepts will be used to increase the effeciency of the team. Lifecycle
Planning, Team Management, and Risk Management principles should help keep
the schedule and team on track. Since this will be a team project
taking place over the course of the quarter, the more common "code and
fix" strategy will be avoided here. Hopefully the succesful deployment
of these techniques will impart valuable team skills to its members.
Projected Timeline
Design Phase (Now - Friday, January 9th)
End of Week One
From now till the end of the first week of the Winter Quarter the team
will be engaged in clarifying the software concept and detailing the requirements/features
of the software that will give a broad architectural design of the software.
The end of the first week should result in a final detailed design of the
overall project that will then be divided for implementation by team members.
The design should be divided in a way to allow integration of the parts
two or three times during the Code and Debug Phase for a complete
system test.
One non-university computer will be designated and used for source control.
A functional design of the program functions should also be layed out at
this time and divided among the team members to start implementing. Hungarian
Notation will be used as a common coding cycle to facilitate review of
other team member's code.
Code and Debug Phase I (Saturday, January 10th - Friday,
January 30th) End of Week Four
Code and Debug Phase II (Sunday, January 31st - Friday,
February 13th) End of Week Six
Code and Debug Phase III (Saturday, February 14th - Friday,
February 27 th) End of Week Eight
The Code and Debug Phase will be expected to take the bulk of
the quarter and is subdivided into three parts. At the end of each
part, integration and testing of code will take place to ensure code is
working together.
Final Testing, Documentation, and Presentation (Saturday, February
28th - Sometime Finals Week)
Code cleanup, documentation of features and presentation to faculty
will be the last phase of the project. Devising a system of distributing
the final product without violation of US Munitions Export Laws will need
to be implemented.
Risks Analysis And Management
Sorted from most probable to least probable risk, a risk is balanced with
a risk management technique to best control the risk. This ordering
is by no means set in concrete and risks can be added or reassesed throughout
the project lifetime.
Risk: Overoptimistic Schedule.
Management: This risk cannot be overemphasized, especially given
the fact that team members are not able to work on the project full time,
but will need to be balanced with other course work. Due to
the nature of this risk, the Design Phase cannot be overemphasized in determing
realistic expectations from the team in overall product feature.
Controlling this risk will be crucial for a succesful project.
Risk: Team Needs Extra Time to Learn Unfamiliar Software
Management: Team Members will be utilizing the Microsoft Foundation
Classes for their application framework. Writing Microsoft Software
is usually a tenuous thing at best. Identifiying issues quickly with
other team members will be important. Doug is the MFC guru for this
project.
Risk: Team Not As Effecient As It Could Be
Management: To make sure that the project is moving along, short
meetings will be held once a week. If a physical meeting is not possible,
telephone conferencing can be arranged also (3-way calling). This
ensures that team members are accountable for their code sections and any
problems are uncovered as quickly as possible.
Risk: Feature Creep.
Management: To avoid the dreaded "feature creep" syndrome, the
feature set should be frozen by the end of the design phase to prevent
schedule slippage. If schedule is starting to get tight towards the
end, prioritize features and start cutting them if this would help with
delivery time.
Final Distribution / Licensing
Final source code and executable will only be freely distributed within
the United States. Due to the current restictions on exporting encryption,
we won't be able to allow anonymous FTP access or Web distribution for
the final program. It was half-facetiously suggested that the group
do their development in Tijuana. The group decided that a US only
distribution was a price they were willing to pay to not have to trek across
the border everytime they wanted to code. To prevent unauthorized
downloading we'll have to have some sort of IP number checking and/or registration
process before allowing someone to download the final package.
Licensing of the final product will be similar to ssh itself.
The original intent was to distribute under the GNU Public License, but
we felt that we'd like a bit more control over our source but at the same
time giving non-commercial users the full ability to poke around and modify
the source.
The proposed license text is linked here.
The final license will also include the license statements from the public
cryptographic library that the group uses.
References
CSE 199 Course Description:
CSE 199 - Independent Study for Undergraduates
Prerequisites: Consent of instructor. Department stamp required.
An application for Special Studies must be filed with
the Registrar's Office after approval from the instructor and the
department chair.
Restrictions: Not more than 4 units of CSE 199 may be used for
satisfying graduation requirements.
4 units, P/NP
Rapid Development - Taming Wild Software Schedules
by Steve McConnell, Microsoft Press 1996, ISBN: 1556159005
Code Complete: A Practical Handbook on Software Production
by Steve McConnell, Microsoft Press 1993, ISBN: 1556154844
Last Modified: December 5th, 1997
This document is dynamic and archived at: http://www.massconfusion.com/ssh/ssh_cs199_proposal.html
Maintainer: Timothy
Chen 
babyduck@massconfusion.com