Posts tagged ssh
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.
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
