[bash] SSH to remote servers accessible only through a central server

We have several Red hat servers node001 through node065 which are only accessible from outside via a central server, central.com. I can think of three different solutions to connect to a node, say node010, via ssh:
1. First SSH to central.com then to node010
2. Forward port 22 of node010 to local machine’s port 2200 via central.com
$ ssh kousik@central.com -L 2200:node010:22
Then ssh to localhost’s port 2200
$ ssh localhost -p 2200
3. $ ssh -YC -t kousik@central.com ssh -YC kousik@node$num

It’s the last one that caught my attention recently — so much so that I put a whole function in the ~/.bash_aliases on my local machine:

#
# A function to ssh to a node: put this in the ~/.bash_aliases file
# The input is the node number
# Example: to ssh to node010 type go2 followed by either 10, 0010 or 0000010 .....
# ..... which is `arithmetically' equal to 10.
#
go2() { num="$*";
  echo "you entered '"$num"' ";
  num="${num#[Nn]ode}"; # Ignore "node", if entered, and consider the rest 
  if [ "$num" -ge 1 2>& /dev/null ] && [ "$num" -le 65 2>&/dev/null ]; then
     num=`echo $num|bc` # for correct arithmetic conversion to a decimal integer
     if [ $num -lt 10 ]; then
        num="00$num";
     else
        num="0$num";
     fi;
     echo "Logging on to  node$num in 1s";
     sleep 1;
     ssh -YC -t kousik@central.com ssh -YC kousik@node$num;
  else
     echo "Please enter a valid integer (1--65)"
  fi;
}

The first conditional statement checks to see if the input is really an integer and is within the correct range: 0-65. The redirections of STDERR to /dev/null are there to suppress appearance of error messages due to non-integer inputs. The reason for using bc for correct arithmetic expansion may be clear from my comment here.

[Network] Use VNC to connect to a remote Linux machine

Let’s assume that you are on computer A and you wan to connect to a remote linux machine B using VNC. You need to follow these steps in order to achieve just that:
1. Install x11vnc and openssh-server on B. The corresponding daemons should start automatically, but if not, then
$ /sbin/service sshd start
$ vncserver :0 -localhost.

2. Make sure that on B the firewall (if installed and active) allows connection to port 22 from anywhere (for ssh connection) and to 5900 from localhost (i.e., 127.0.0.1). These are the commands (in case of ufw as the firewall) to allow traffic to the specific ports.
$ sudo ufw allow 22
$sudo ufw allow from 127.0.0.1 to any port 5900

3. If B is behind a router firewall, you need to forward port 22 to the router. (You should do this in the router configuration page).
4. On A, create a newfile, vnc2b.sh and enter the following


#!/bin/sh
ssh -f -L 5900:localhost:5900 username@remote_hostname \
x11vnc -safer -localhost -nopw -once -display :0 \
&& sleep 5 \
&& vncviewer localhost:0


and make the file executable:
$ chmode u+x vnc2b.sh.

Next time when you want to vnc to B, just type:
$ ./vnc2b.sh

Reference: here.

[network] Port forwarding via SSH

Let’s say you have physical access to your home computer h.com and your work computer w.com and besides that you work on a remote server r.com. Let’s also assume that the usernames are huser, wuser and ruser, respectively.

There may be various accessibility scenarios, but let’s just assume that you can access the remote servers from both home and work computers, but you cannot access home computer from work directly and vice versa. A possible solution to have all the computers accessible is forward a port on the remote machine to the local port 22 (we are interested in ssh connection only, at least for the time being!).

Forwarding remote port:
So at home before you leave for work, forward port 2222 of r.com to port 22 of local machine h.com
$ ssh ruser@r.com -R 22:localhost:2222
Type in localhost as it is! It creates a secure socket from remote machine’s port 2222 to local machine’s port 22, meaning the ssh traffic coming to port 2222 of r.com will be forwarded to port 22 of h.com.
When you get to work, first ssh to the remote machine from your work computer:
$ ssh ruser@r.com.
You can then access the files at your home while you are still on h.com by simply doing
$ ssh huser@r.com -p 2222 (you’ll be asked for the password for your home computer). The flag -p stands for port.

Now, before you leave your work, forward port 22 of w.com to another port (say, 2223) of r.com using the above method. At home, you first ssh to r.com; and the using
$ ssh wuser@r.com -p 2223 (you’ll be asked for the password for the work computer),
you may access files on your work computer.

Forwarding local port:
I don’t know how I can best use it yet, but anyway, here is how to do it along with one “possible” use of it. Let’s say from your home computer you cannot ssh to r2.com, another remote server, but you can from r.com. In order to connect to r2.com form home, the most obvious way is to connect to r.com from h.com first, and then to r2.com. You have to do this for every new ssh connection r2.com from h.com. But if you forward an available local port (say, 2224) to port 22 of r2.com via r.com, it'll be a lot easier. Issue the following command while you are on h.com:
$ ssh ruser@r.com -L 2224:r2.com:22.
This will enable you to connect to r2.com from h.com by using
$ ssh r2user@localhost -p 2224
in another terminal on the home computer (r2user is the username for r2.com).

File copying between those computers also becomes a breeze:
$ scp -P 2224 file_to_be_copied r2user@localhost:/desired_dir/copied_file
(notice the capital P).

N.B. (1) In order to check if a port (say, 2225) is available on the locahost, try
$ nc localhost 2225,
(2) Needless to say, you must have sshd running on the machines that you want to connect to via ssh.

[ssh] SSH login to remote server without password

If you’re using OpenSSH to connect to remote Linux machine, then this may come as bliss. This is based on public key authentication — (1) create a key-pair — a private and a public one, and then (2) save the public key in the authorized_keys file in the remote machine. Next time when you login using SSH to the remote server from the local machine where you have saved the private key, you won’t have to enter the password! Isn’t it cool? OK, now let’s get down to business, shall we?

Step 0: Make sure the RSA and public key authentication methods are enabled (which are in general enabled by default) in /etc/ssh/sshd_config on the remote machine — it should look like the following:

RSAAuthentication yes
PubkeyAuthentication yes

and then reload the configuration if you had to modify it

$ sudo /etc/init.d/ssh reload

You need the administrative rights for the above.

.

Step 1: Use the command ssh-keygen to create the key pair:

$ ssh-keygen -t rsa

Save the key to the default location, viz. ~/.ssh/id_rsa. When you hit enter, it’ll ask you for a passphrase — leave it empty (see warning below). You need to hit enter once more to confirm it.

Now if you go to ~/.ssh directory, you’ll see that two new files are created: id_rsa (your private key — don’t lose it or give it to somebody else!) and the public key, id_rsa.pub.

.

Step 2: We need to append the public key to the authorized_keys file or save the key as a new file with the name authorized_keysX (where X is a number to avoid conflict) in ~/.ssh directory on the remote machine. We’ll use the fancy vi trick that we saw earlier:

$ vi scp://remoteuser@remote.machine.com//home/remoteuser/.ssh/authorized_keys

Enter your password when you’re asked. Once the vi window opens up, go to the end of the file (hit Shift+G) and then append the public key file

:r id_rsa.pub

assuming you’re still in the ~/.ssh directory on the local machine. Next, save the file and exit.

Note: you may also use

$ ssh-copy-id remoteuser@remote.machine.com

to automatically put the ID in the desired place.

Now you are all set to login to the remote machine using ssh without a password!

.

WARNING: The big security concern and a work-around (still being lazy!)

The ease of this method has a very strong downside: if the local machine is compromised the attacker will waltz onto the remote machine. A way out of this is to protect your private key with a non-empty passphrase. That also means every time the machine requires access to the private key (i.e., every time you login to the remote machine where you saved your public key), you have to enter the passphrase. What’s the use of this hoopla then — you may ask. Well, when there is a wish there is a way too — by committing the key to the  local system’s `memory’ so that you type the passphrase once and only once for the whole session.

OK. Let’s first change password to a non-empty string, shall we?

$ ssh-keygen -p

It’ll ask for the location of the key. Then you’ll have to enter a passphrase and verify it (don’t leave this empty this time).

Next make the system remember your key:

$ ssh-add

It’ll ask for the passphrase (in order to ‘unlock’ your private key) and then for the whole session you won’t need any password/passphrase to login to the remote machine.

.

READ MORE: here and here.