I have added a variety of user interface updates to the pro version. In addition to the toast popups actual notifications add a sence of feedback and depth to the program. I want the program to feel that its actually aware of what you are doing and processing interactions accordingly. I feel with recent enhancements this is becoming more and more the case.
I have fixed a couple of potential situations where an i/o exception can occur. I have also added enhancements that clarify a particular action based on the current state of setting. All in all the depth and feedback offered by the application is improving.
Without substantial feedback/comments by actual users, I see very little confusion using the app and no bugs. Every action performs accordingly. The primary situation I think users may encounter is the inability to login. In such a situation the connecting dialog will just continue to spin. VirtualBox Manager is designed for users to first login to a host using password authentication. Therefore for each host the first connection must be made to an ssh server with PasswordAuthentication set to yes in /etc/ssh/sshd_config. Withe the correct host/port/username/password set in the app, and port forwarding properly configured in a users router/network a connection will occur. The user can then click the menu, and select generate key; which generated a new 1024 bit DSA key. The user can view the private and public keys directly from buttons in the menu. There are strategic dialog boxes that state the user can then upload the key to the server, which automatically appends it to the bottom of ~/.ssh/authorized_keys2. Pressing upload automatically enabled key login for the particular host. Enabling and disabling key login is done via the hosts configuration options accessible on the main screen.
There are many checks to prevent confusion. A user cannot enable key login unless there is a key. Keys cannot be displayed/uploaded before they are created; which would be an i/o exception. There is also a warning when a user tries to generate a key when a key already exists. This can cause a problem that will prevent other hosts from loggin in; if the key changes it will no longer match the public key stored on the host. A dialog will appear explaining that password login will be re-enabled for the host, and that when the key is uploaded password authentication will be used. If a new key is generated the user must disabled key authentication for other hosts configured in the app; once logged in to other hosts using password auth the user can easily upload the new public key to the server, reestablishing key based authentication for the respective host.
After a public key is uploaded to the server password authentication can be disabled. This substantially diminishes and practically eliminates the possibility of a brute force intrusion.
The pro version adds support for 20 hosts, and 20 machines per host. This is done using a ScrollView wrapped around each activity. Its a logical addition. If users request support for more hosts it can easily be added.
I want to change the oncreate structure to each of the three activities. I want to initialize the buttons in a background thread. While the UI is fast and there is no visible delay I would like to code the oncreates as such. Frankly given the speed of recent phones I don’t think there will be any visible differences. Theoretically on a slower processor the activity would display with no button, and then as the thread processes the views they will display on the screen one by one.
I will add some additional features in time, but until comments start rolling in a new project is in the works. Linux Manager Pro. I’ll posts as it develops.
VirtualBox Manager – Dialogs Class Complete Re-Write »« VirtualBox Manager/Pro Enhancements
VirtualBox Manager Pro has been launched on the Android Marketplace. It has many enhancements over the free version. The user interface has additional notifications, and the most important feature, public key authentication, has been fully implemented. Once logged into a host using password authentication, VirtualBox Manager Pro can create a 1024 bit DSA encryption key, which can then be uploaded to the server. The upload method automatically appends the key to the bottom of the authorized_keys2 file. From then on pub key auth is used to connect to the particular host. Pub key authentication can be enabled and disabled in the hosts configuration menu. The application has many checks and when a situation may require explanation several dialog boxes have been strategically implemented to avoid problems with pub key authentication.
VirtualBox Manager Pro is excellent for serious IT departments that require minimum security requirements. Using pub key authentication the use of password authentication can be completely disabled. This is a huge security enhancement over the free version. VirtualBox Manager Pro is available for $19.99, and is targeting IT departments rather than the individual. Home users can utilize password authentication to a great extent without detrimentally exposing a server to internet based threats, whereas IT departments host servers that are business dependent.
Try VirtualBox Manger Pro today to experience a stable, intuitive, and fully function VirtualBox remote management solution.
VirtualBox Manager/Pro Enhancements »« VirtualBox Manager Pro – Public Key Authentication
If you are going to be providing technical support, to be professional you should implemented a secure ssh connection. There is no excuse to potentially give terminal access to a password snooper. Using ssh the terminal commands themselves are encrypted, so disabling password login truly minimized risks of a security breach. Using a RSA key passwords are not transmitted and the login process is truly encrypted. Disabled password login by changing its option to “no” in the sshd configuration file. The config file is located in /etc/ssh/sshd_config. The default authorized key file is located in the users home directory. ~/.ssh/authorized_keys2. You need to place the id_rsa.pub information in the authorized_keys2 file. You can open the file manually or your can cat it in. You can also replace the entire authorized_keys2 file with id_rsa.pub; but maybe you want multiple authorized keys so use cat or editing manually may be better.
Create a new RSA key with:
ssh-keygen
It will put the new id_rsa and id_rsa.pub in ~/.ssh. When logging in as a client the default location for the id_rsa is in ~/.ssh, but you can place it anywhere using the ssh -i option. Then include the path to the id_rsa key. An example is:
ssh -i /home/user/Desktop/id_rsa user@host
Server Security – Passwordless Remote Login »« Linux CUPS Configuration – Foomatic
There is no reason to be hassled to enter login usernames and password when accessing a terminal via ssh. SSH has built in rsa key authentication mechanisms. First build the private and public keys:
ssh-keygen
This will create your private and public keys in the .ssh folder in your home folder. You then copy the public key to the .ssh folder on the target system. Use scp for this.
scp .ssh/id_rsa.pub 192.168.0.100:.ssh/authorized_keys2
Change the ip address of the target system accordingly. Then login to the target system and change the ssh daemons configuration file.
sudo nano /etc/ssh/sshd_config
Scroll to the password authentication line, remove the pound sign, and make sure its set to no. Also make sure the daemon uses the authorized_keys2 file as the public key reference. Save the file, exit, and reset the ssh daemon.
sudo /etc/init.d/ssh restart
Now your ssh connections will be automated, and powerfully encrypted. You can remove the id_rsa.pub key from your .ssh directory for total security. Now the public key is only on the target system, and the only way to gain access to that system is via direct login or via the private key on your remote system. You can also transfer the private key to a usb drive, and delete the id_rsa key from the .ssh directory. When connecting via ssh use the -i option to locate the key on the usb drive. For example:
ssh -i /media/drive/id_rsa 192.168.0.100
Now the entire session will only work with the usb key in the drive. Your usb drive will literally be a key, without it there is no access to the target system whatsoever. Also do not loose the usb key, otherwise the only way to access the system will be directly via a terminal.
Compiz and VNC Fullscreen Bug Workaround »« VirtualBox Headless Mode
