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