Posts tagged password
VirtualBox Manager Pro – UI Updates and Stability
May 23rd
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.
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.
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)
Detecting a Security Breach – Ubuntu and Linux Machine
Jan 25th
Detecting a security breech is sometimes as easy as logging into the machine, using ssh, and viewing the last login attempt from a completely unrecognized ip address or domain. Subsequently check your auth.log file, in /var/log, for login attempts. If you see countless failed login attempts you have been the victim of a brute from attack. In gedit, or nano you can search for “attempt” or “access”. When several failed login attempts occur a log entry saying “possible breaking attempt” is posted. The first think a hacker will do, on a Linux machine, is attempt to change the root password, which will lock down the machine completely. If they cannot change the root password, they may just try and install a backdoor to the particular user that was breached. A backdoor can be a daemon running on any port, so check with “ps aux | grep user”. Grepping the ps command will bring up all of your active processes and if any process name looks funny you have identified a concern. You can also check what ports are accepting communication (open). A backdoor can also be an installed authorized key, which will allow password-less ssh access to the system.
Ultimately if a hacker changes the root password of your machine, there is nothing you can do. You must either restore from a backup, or rebuild the entire machine. No questions asked.
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