rsa
VirtualBox Manager – Version 44MPG
May 17th
VirtualBox Manager was released two days ago and several updates have been published since then.
- I have fixed a bug on the delete hosts page
- Enhanced the header images on the delete hosts page and machine page
- Tweaked the keyboards in the input data menus
- Added references to the host as well as the machine in various dialog headers
- Some code cleanup trying to do more in the oncreate rather than in methods
- Fixed a bug in the help pages and customized the info respectively
As mentioned, therefore is a lot of code I have already written dealing with rsa key login. Now that the program is in a stable release state I plan to cleanup the code and then start looking at completing encrypted login features.
Jsch on Android
May 9th
Jsch works on android. With the only dependency, jzlib, satisfied the java based implementation of ssh is beginning to code relatively straight forward. After many days of trial and error the correct syntax to the commands, and the methods of particular classes are beginning to make sense. Password login is relatively straight forward, and with a little bit of encryption added to the internal storage location the password should be relatively secure on a mobile device. Ultimately the goal is to create an RSA key on the mobile device, connect initially with a password, and add the public key to the authorized keys file. Then the key on the device can bypass password login altogether.
Right now I have several ssh connections, running various commands, operating in background threads. I’m working on displaying progress bars to add a ui to the connection process. Ultimately the final ssh command will generate output to populate several views in a new activity.
Yes it would be nice for Jsch to have more documentation, but compared to the size, and dependencies requirements, of other java based ssh packages I find the Jsch package well consolidated and not dependency heavy.
VirtualBox – Android Remote Management
Apr 18th
I wonder if Android can use animated backgrounds. If they can I will work on the following image. I’ll reduce its size and tweak it for the relatively small screen of a smartphone. If the phone cannot use an animated background I will just use the image without the animation. Ultimately I made the image in hopes that it will lead to an application, which I have begun tinkering with.
Theoretically the app will use ssh to connect to a server. The app will need to configure either password or RSA authentication. It will then use shell commands to retrieve the available virtual machines in a particular users home directory. At first it would provide the ability to start, pause, and stop them individually. Then additional functions can be added.
Sshd_config Settings Rundown
Feb 3rd
- Image via Wikipedia
First change the port you are using. Do not use port 22 on servers that have internet connectivity. This is the first port that will be checked by countless robots searching the internet for vulnerabilities. Change the port to whatever, and then use the -p option in your ssh login attemt. Then make sure root login is disabled, remove the pound symbol from the front of the option line. If you can you should definitely allow rsa key login. Once you get your encryption key setup disable password login by setting the respective line to “no”. If you cannot enable keyed logins for any reason what soever, you should enabled ip based restrictions either by iptables or by tcp wrappers. Iptables is configured with the iptables command, and the tcp wrappers are configured in /etc/hosts.allow. You can reduce the time limit for password login, but sometimes this causes problems with remote users connecting; sometimes it takes a couple of extra seconds for people to login. Make the time limit around 30 seconds. If people are still having trouble connecting check the /var/log/auth.log file for more information about the failed login attempt. Maybe the password is too complicated? Before reducing the complexity of the password implement fail2ban, which will automatically block ip addresses based on failed login attempts, therefore you can reduce the complexity of the password without substantially reducing system security.
![Reblog this post [with Zemanta]](http://img.zemanta.com/reblog_e.png?x-id=e60bad9b-01fa-477c-8d93-931cacb700d4)
Server Security – Passwordless Remote Login
Jan 24th
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.
Secure Remote Connections – Tech Support
Jan 23rd
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