from Wiki: http://en.wikipedia.org/wiki/Web-based_SSH
Web-based SSH clients basically consist of the following parts:
- Client-side: Typically JavaScript and dynamic HTML pages are used to capture keystrokes, transmit messages to/from the server and display the results in the user's web browser.
- Server-side/Web application: Incoming requests are processed on the web application server. Keyboard events are forwarded to a secure shell client communicating with the connected SSH server. Terminal output is either passed to the client where it is converted into HTML via JavaScript or it is translated into HTML by the server before it is transmitted to the client.
Client-side terminal emulation
Web-based SSH servers that utilize client-side terminal emulation typically transmit the raw terminal output from the SSH server directly to the client. This has the advantage of offloading the process of translating terminal output into HTML on to the client. The disadvantage of this method is that it is limited by the capabilities of JavaScript and it will use up a non-trivial amount of the client's CPU and memory to process the incoming character stream. It also relies on the client to keep track of the terminal state and respond to escape sequences.
Client-side terminal emulator example: vt100.js (from Shell in a Box)
Server-side terminal emulation
Web-based SSH servers that utilize server-side terminal emulation typically keep track of the terminal screen and state in memory and convert it to HTML either when a screen update occurs or when the client expressly requests an update. The advantage of this method is that the state of the terminal remains persistent even if the user connects to their existing session(s) from a different web browser. It also enables the server to act upon terminal output even if the user is disconnected.[1] The disadvantage of this method is that it uses up more CPU and memory on the server.
Server-side terminal emulator example: terminal.py (From Gate One).
Advantages
The main advantages of web-based SSH can be summarized as follows:
- Accessibility: Web-based SSH as described in this article requires no local installation of client software. It is thus possible to access SSH servers through a web browser from anywhere. As communication is based on HTTP or HTTPS it is also possible to access SSH servers from behind a firewall or proxy that restricts Internet access to only ports 80 (HTTP) or 443 (HTTPS).
- Anonymous Access: As SSH access is tunneled through an intermediary web application server it is this server which actually communicates with the SSH server. This means that the SSH server will only be aware of the IP address of the web application server, keeping the actual client's IP address hidden.
- Auditability: Because all communication between the client and the SSH server must pass through the web application serverthis communication can be logged. This prevents a malicious client from deleting logs of their activities.
- Resuming Sessions: Some web-based SSH implementations allow the user to resume their SSH sessions after being disconnected. This is not possible with a traditional SSH client.
- Embeddable: Web-based SSH implementations can be embedded into any web page allowing them to be integrated into other web-based applications.
- Unique Features: Many web-based SSH tools have unique features such as the ability to share terminals with other users, can display images within terminals, and other useful capabilities.
--- ajaxterm on Ubuntu setup
1, sudo apt-get install ajaxterm
You will need to enable SSH password authentication for AjaxTerm to work.
2, uncomment "PasswordAuthentication yes" in /etc/ssh/sshd_config.conf
3, sudo service ssh restart
4, configure Apache2 for HTTPS and generate a certificate
------------------------------------------------------------------------------------------------------------------------
Generating a Certificate Signing Request (CSR)
Whether you are getting a certificate from a CA or generating your own self-signed certificate, the first step is to generate a key.
If the certificate will be used by service daemons, such as Apache, Postfix, Dovecot, etc, a key without a passphrase is often appropriate. Not having a passphrase allows the services to start without manual intervention, usually the preferred way to start a daemon.
This section will cover generating a key with a passphrase, and one without. The non-passphrase key will then be used to generate a certificate that can be used with various service daemons.
Running your secure service without a passphrase is convenient because you will not need to enter the passphrase every time you start your secure service. But it is insecure and a compromise of the key means a compromise of the server as well.
To generate the keys for the Certificate Signing Request (CSR) run the following command from a terminal prompt:
openssl genrsa -des3 -out server.key 2048
Generating RSA private key, 2048 bit long modulus ..........................++++++ .......++++++ e is 65537 (0x10001) Enter pass phrase for server.key:
You can now enter your passphrase. For best security, it should at least contain eight characters. The minimum length when specifying -des3 is four characters. It should include numbers and/or punctuation and not be a word in a dictionary. Also remember that your passphrase is case-sensitive.
Re-type the passphrase to verify. Once you have re-typed it correctly, the server key is generated and stored in the server.key file.
Now create the insecure key, the one without a passphrase, and shuffle the key names:
openssl rsa -in server.key -out server.key.insecure mv server.key server.key.secure mv server.key.insecure server.key
The insecure key is now named server.key, and you can use this file to generate the CSR without passphrase.
To create the CSR, run the following command at a terminal prompt:
openssl req -new -key server.key -out server.csr
It will prompt you enter the passphrase. If you enter the correct passphrase, it will prompt you to enter Company Name, Site Name, Email Id, etc. Once you enter all these details, your CSR will be created and it will be stored in the server.csr file.
You can now submit this CSR file to a CA for processing. The CA will use this CSR file and issue the certificate. On the other hand, you can create self-signed certificate using this CSR.
Creating a Self-Signed Certificate
To create the self-signed certificate, run the following command at a terminal prompt:
openssl x509 -req -days 365 -in server.csr -signkey server.key -out server.crt
The above command will prompt you to enter the passphrase. Once you enter the correct passphrase, your certificate will be created and it will be stored in the server.crt file.
If your secure server is to be used in a production environment, you probably need a CA-signed certificate. It is not recommended to use self-signed certificate.
Installing the Certificate
You can install the key file server.key and certificate file server.crt, or the certificate file issued by your CA, by running following commands at a terminal prompt:
sudo cp server.crt /etc/ssl/certs sudo cp server.key /etc/ssl/private
Now simply configure any applications, with the ability to use public-key cryptography, to use the certificate and key files. For example, Apache can provide HTTPS, Dovecot can provide IMAPS and POP3S, etc.
HTTPS Configuration
The mod_ssl module adds an important feature to the Apache2 server - the ability to encrypt communications. Thus, when your browser is communicating using SSL, the https:// prefix is used at the beginning of the Uniform Resource Locator (URL) in the browser navigation bar.
The mod_ssl module is available in apache2-common package. Execute the following command from a terminal prompt to enable the mod_sslmodule:
sudo a2enmod ssl
There is a default HTTPS configuration file in /etc/apache2/sites-available/default-ssl. In order for Apache2 to provide HTTPS, acertificate and key file are also needed. The default HTTPS configuration will use a certificate and key generated by the ssl-cert package. They are good for testing, but the auto-generated certificate and key should be replaced by a certificate specific to the site or server. For information on generating a key and obtaining a certificate see Certificates
To configure Apache2 for HTTPS, enter the following:
sudo a2ensite default-ssl
The directories /etc/ssl/certs and /etc/ssl/private are the default locations. If you install the certificate and key in another directory make sure to change SSLCertificateFile and SSLCertificateKeyFile appropriately.
With Apache2 now configured for HTTPS, restart the service to enable the new settings:
sudo service apache2 restart
Depending on how you obtained your certificate you may need to enter a passphrase when Apache2 starts.
You can access the secure server pages by typing https://your_hostname/url/ in your browser address bar.
------------------------------------------------------------------------------------------------------------------------
Now copy [then symlink] the SSL config from the Available sites to the Enabled sites
5, sudo cp /etc/apache2/sites-available/default /etc/apache2/sites-available/ssl
Make sure all the modules and sites for proxy and ssl have been enabled.
6, sudo a2enmod proxy_http 6, sudo a2enmod ssl 6, sudo a2ensite default-ssl
It is time to decide on an htaccess password and username. Remember to make this password strong.
7, sudo mkdir /srv/ajaxterm 8, sudo htpasswd -bc /srv/ajaxterm/.htpasswd [user] [pass]
You will now need to edit the default Apache SSL configuration.
9, sudo nano -w /etc/apache2/sites-enabled/default-ssl.conf
Insert just before </VirtualHost>:
ProxyRequests Off
<Proxy *>
AuthUserFile /srv/ajaxterm/.htpasswd
AuthName EnterPassword
AuthType Basic
require valid-user
Order Deny,allow
Allow from all
</Proxy>
ProxyPass / http://localhost:8022/
ProxyPassReverse / http://localhost:8022/
Restart apache2.
10, sudo service apache2 restart
Open your firewall port 443 and try to browse to https://yourhost.foo where yourhost.foo is either your IP adress or your hostname/web address.
--- ajaxterm on Ubuntu
No comments:
Post a Comment