Posts tagged ssh
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.
SSH – Gateway Ports and Forward Reverse Tunnels
Feb 27th
SSH can create forward and reverse tunnels to transmit port data through the encrypted connection. You can create forward tunnels that link the local port of the client machine to the remote port on the server. You can create reverse tunnels that link the remote ports of the server to the local ports on the client. Forward tunnels are created using the -L option. Reverse ports are configured using the -R option. The forward and reverse tunnels work fine when working locally on the client machine, but if you want other hosts, at the client location, to connect to the tunnels you need to enable the gateway ports feature of ssh.
Gateway ports does not work with forward and reverse tunnels on Ubuntu 8.04, the long term support branch. The openssh version included in the repositories does not allow reverse tunnels, and forward tunnels combined, with the -G (gatewayports) option enabled. Forward tunnels do work with the gateway ports feature. Theoretically the option does try and work, but when you operate ssh using -VV you will see that during the connection process the reverse tunnel fails to create.
I think this is an old bug that may have been addressed. I do see posts about successes, therefore I’m inclined to think that new versions of openssh have addressed the bug.
http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=228064
Instead of installing a newer version of ssh I just implemented an alternative for hosts at the client location. I wanted to use a single computer as a gateway to ports located on a remote server. It would have been nice to consolidate all communications to a single ssh connection.
I ended up using http://haanstra.eu/putty/. Each workstation, at the client location, will establish a direct ssh connection bypassing the gateway ports feature. There will be many ssh connections, but this is all behind the scenes stuff that the employees will never see, and it will provided the needed functionality.
SSH X Forwarding with Compression
Feb 13th
If you plan to forward X applications via ssh, and are using a very slow internet connection you should definitely use compression. The “-C” option will use compression and will substantially increase the data transfer rate in 100 Kb/s or less internet connections. Also with vnc connection, if you are using xtightvncviewer you can effectively decrease the quality of the desktop, which is proportionally increase performance. For more information about xtightvncviewer check here:
http://www.bgevolution.com/blog/vnc-compression-quality-the-works/
You’d be surprised at what you can get accomplished on slow internet connections using the tips above.
Related articles by Zemanta
- Keep SSH Sessions Active, Or Reconnect? (ask.slashdot.org)
![Reblog this post [with Zemanta]](http://img.zemanta.com/reblog_e.png?x-id=c7055344-07cd-4293-9015-9d8e0f21e4bd)
SSH Login Timeout – Password Authentication
Feb 6th
SSH login timeouts are not very effective at preventing unauthorized login attempts. Most ssh attacks are scripted attached launched by automatic mechanisms. The scripts most likely will use dictionary based brute force attacks that insert the password very quickly. Setting the login timeout very low will most likely not prevent such scripted attacks, and will only hinder the ability for a legitimate user to login successfully within the allocated amount of time. Set the login timeout to 60 seconds; I have set it to 5 seconds and it only caused problems for actual user logins.
Auth.log in Debian Systems
Feb 2nd
- Image via Wikipedia
Your auth.log file is the first step in determining of an intrusion is being attempted, or has occured. It logs all ssh connection attempts, cron jobs, and su calls. If an ssh brute force attach is occurring you will see countless failed ssh login attempts. Most likely various usernames will be attempted. You should immediately stop the ssh server and implement some security countermeasures. Implement various rules in your hosts.allow and hosts.deny files any if you want implement some iptables rules. Host.allow and deny should be enough; the files control tcp connections to your running system daemons. Iptables will block ip numbers just at the connection attempt is made to the computer so for ultimate security implemente iptables and various host rules.
After locking down your servers you will see brute force attacks stop, and your auth.log file will be mainly filled with cron jobs and su commands by users and daemons. The cron jobs are automated process run by various applications, and are mostly run as root. Mail servers, and other tasks are typically managed by cron jobs. You can check user specific cron jobs using the crontab command. Use option -e to edit a users jobs.
![Reblog this post [with Zemanta]](http://img.zemanta.com/reblog_e.png?x-id=3d636c5f-6390-4670-846a-1ac3fcac0e47)
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.