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.
Yes, I know it sounds funny. You can work locally from a remote location. I am specifically referring to use of LTSP. I am managing a server for a company, and I will be placing the server in an air conditioned server room; and I don’t want to sit in that room all day long. I installed an LTSP server so I can sit in the main office and boot a PXE enabled computer from the system. LTSP allows you to login directly to the server from a remote location. The desktop environment will be exactly the same as if you were sitting in front of the machine. The only difference is the LDM login screen, which technically you can change to anything including GDM.
I want to take the graphics card out of the server; its a nice Nvidia card; in the end I will not being doing what I want because I cannot leave the server completely without local video capabilities. I will be relying on the motherboard integrated Intel video chipset on the PXE enabled computer. It will server its purpose. I will be taking the 1080p capable monitor from the server, to use on the client; this I can get away with. Its a nice system and a pleasure to manage.
Based on some recent experience do not ever allow password remote login. There are two things you chould apply to your ssh server. Implement a RSA key login, and implement fail2ban. Fail2ban will modify iptables (firewall) to block the ip address of offending attempts to connect. It will do so for your apache, ssh, ftp, and other servers. It is a separate program, not a wrapper, and it monitors log files for login attempts. You set the max login attempts (fails) in the jail.conf file in /etc/fail2ban. The combination of RSA keys and fail2ban will ensure a secure and accessible system, which is a must of the system is to be open to outside internet connections.
A previous post about fail2ban
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:
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