Blogs

Posted by: {authorName}

Problem

Workstation 1 needs to connect to Database Server located at another part of the globe.

Prerequisites

• Workstation 1 and Workstation 2 are on the same network.
• Workstation 3 and Database Server are on the same network.
• Workstation 2 can connect to Workstation 3 via SSH.
• Port 4321 at mycompany.com is forwarded to port 22 of Workstation 3.
• Workstation 2 does not have a firewall which allows Workstation 1 to connect to it.
• Database Server allows connection from Workstation 3.



Solution

Create an SSH tunnel using Workstation 2 and Workstation 3 where Workstation 1 connection can pass through going to Database Server.

Steps:

1. Go to Workstation 2 and make sure it can connect to Workstation 3 by issuing the following commands:

[user1@Workstation2 ~] ssh user1@mycompany.com -p 4321
user1@mycompany.com's password:
Last login: Mon Feb 21 21:55:54 2011 from Workstation2
[user1@Workstation3 ~] exit
[user1@Workstation2 ~]

If you can do the above, then we are set to do tunneling.

2. Still on Workstation 2 issue the following command:

[user1@Workstation2 ~] ssh -f user1@mycompany.com -p 4321 -L 192.168.70.2:1234:192.168.50.2:3306 -N
user1@mycompany.com's password:
[user1@Workstation2 ~]

We will define each one of the parameters:

-f

This tells ssh to go to background just before command execution.





user1@mycompany.com

This defines your username and address of the remote computer.





-p 4321

This is the port in the firewall where in it is being forwarded to port 22 of Workstation 3. If your firewall is on Workstation 3, then this parameter can be omitted.





-L 192.168.70.2:1234:192.168.50.2:3306

This is where the magic happens. -L means you want a local (Workstation 2) port  to be forwarded to a remote host (Database Server) and port (3306) on the remote side (Workstation 3). Just to be clear, local side pertains to the computer network at Africa while remote side pertains to the computer network at South America.

The bunch of numbers after -L can be separated by colon(:) and here are their meanings:

192.168.70.2 is the address of the local computer (Workstation 2).

1234 is the port on the local computer (Workstation 2).

192.168.50.2 is the address of the remote computer (Database Server) on the remote side.

3306 is the port to access in the remote computer.






-N

This means that you cannot execute a command on the remote host since your are only tunneling data. This is basically for security.






Once you have issued the above command and entered your password, the ssh connection will go in the background. The tunnel is now created.

3. To use the tunnel, we go to Workstation 1 and execute mysql:

[user1@Workstation1 ~] mysql -h 192.168.70.2 -P 1234 -u dbuser -pdbpasswd dbname

That's all there is to it. Workstation 1 is now connected to Database Server.

August 11, 2010

SSH login using config

Posted by: {authorName}

My last blog, which discussed how you can login via ssh without entering a password, makes your life easier as you don't have to remember each and every password on every single computer. Not to mention, it ensures greater security as you are accessing the other computer with a key which only you have access to.

This time I'll make ssh login even easier by using a config file.

Instead of typing ssh with different arguments plus the long domain name or IP address and user name, you'll just need to type the command "ssh myserver".

Using our example from my previous blog, open console and run the following command:

[happy@mars ~] vim .ssh/config

Hit 'i' and type in the following:

Host jup
User happy
HostName jupiter

Hit esc button then type ':x" to save.

You can now just type:

[happy@mars ~] ssh jup

SSH command will read your config file and match up 'jup' from the Host in your config and use the User and Hostname to connect to another computer.

This is very useful, especially if you have many servers that you manage and have different usernames and parameters when connecting.

You can set all possible parameters for ssh in the config file instead of typing them one by one.

Examples are Port if the other computer uses a port other than 22, ForwardX11 to display GUI on your local computer, Protocol to force ssh protocol version, Tunnel for tunneling and many others. Type "man ssh_config" in your console to get more in depth information about possible parameters.

Posted by: {authorName}

Tired of always typing your password when logging in to your server? Here are steps on how to you can eliminate the typing of your password and making it more secure when connecting to your server.

In this example scenario, let's call your local computer "mars" with user happy. We'll call the remote server "jupiter" with user happy (this can be any user in jupiter).

First in mars, fire up the console type the following command:

[happy@mars ~] ssh-keygen

You will be asked to specify where the key should be saved and optionally add a passphrase (aka password). Just hit enter key on those question. No need to enter a passphrase because it will beat our purpose.

The command will produce 2 files in /home/happy/.ssh folder. A private key which is used by the ssh program when connecting to remote hosts and a public key which needs to reside in the remote hosts.

We will now need to send the public key to the remote hosts.

[happy@mars ~] scp .ssh/id_rsa.pub happy@jupiter:/home/happy/

You will be asked for your password and if successful your public key will be transferred to the remote server.

We now need to tell the remote server that that public needs to be trusted.

[happy@mars ~] ssh happy@jupiter
happy@jupiter's password:
[happy@jupiter ~] mkdir .ssh
[happy@jupiter ~] cat id_rsa.pub >> .ssh/authorized_keys2
[happy@jupiter ~] rm -f id_rsa.pub
[happy@jupiter ~] chmod -R 700 .ssh

TIP: If you have the same username in the local and remote server, you can omit the "happy@" when doing ssh command.

This may be the last time you will be typing your password. The first command will get you inside the remote server as you usually do. The second one copies your public key into the authorized_keys2 file. The third one deletes your public key. Lastly, the fourth command sets the authorized_keys2 permission correctly (you only need to do this once).

You are now set to password-less logins. Exit the remote server and try logging in again. It should not ask for your password any more.