[ previous ] [ Contents ] [ 1 ] [ 2 ] [ 3 ] [ 4 ] [ 5 ] [ 6 ] [ 7 ] [ 8 ] [ 9 ] [ 10 ] [ 11 ] [ next ]

Some Mini-Howtos of Interest
Chapter 3 - The ssh application

3.1 Removing a known_hosts entry

In order to remove from the known_hosts file the entry corresponding the the computer hostname, execute[7]

      
     ssh-keygen -R hostname

3.2 Generating a key pair and exporting to a remote host

If we want to access a remote node with ssh without providing our password, we can do so using automatic login. In order to do so, we must first check if we have a keypair already generated.

      
     $ ls .ssh/
     known_hosts

If it is not generated, like in this example, we generate it using the command

      
     $ ssh-keygen
     Generating public/private rsa key pair.
     Enter file in which to save the key (/users/home/username/.ssh/id_rsa): [press enter]  
     Enter passphrase (empty for no passphrase): [press enter]  
     Enter same passphrase again: [press enter]  
     Your identification has been saved in /users/home/username/.ssh/id_rsa.
     Your public key has been saved in /users/home/username/.ssh/id_rsa.pub.
     The key fingerprint is:
     8b:93:61:e7:2d:4a:50:30:a3:23:7d:fc:c5:21:af:d7

The next step is to copy the generated public key to the remote host we want to be able to login automatically, hostname.

      
     $ ssh-copy-id -i ~/.ssh/id_rsa.pub hostname
     36
     The authenticity of host 'hostname (XXX.163.XXX.XXX)' can't be established.
     RSA key fingerprint is 37:2b:77:61:50:0f:2a:d2:7f:da:c9:a9:10:29:37:t6.
     Are you sure you want to continue connecting (yes/no)? yes
     Warning: Permanently added 'hostname,XXX.163.XXX.XXX' (RSA) to the list of known hosts.
     Password: 
     Now try logging into the machine, with "ssh 'hostname'", and check in:
     
       .ssh/authorized_keys
     
     to make sure we haven't added extra keys that you weren't expecting.

And that's all. Now you can login via ssh without being prompted for a password.

3.3 Launching with ssh programs that require a terminal

There are some programs that cannot be launched directly with ssh because they require an associated terminal. For example, mutt or screen,

      
     $ ssh user@server screen
     Must be connected to a terminal.

To solve this problem there is an option in ssh to force pseudo-tty allocation. For example, if we want to re-attach to a previous screen session in the node server we can do

      
     $ ssh -t user@server screen -dr

3.3.1 References

1. Hack and / - Lightning Hacks, Linux Journal, issue 195, July 2010

3.4 Tunneling with ssh

The ssh program has the powerful feature of making the user able to stablish encrypted tunnels between nodes. This is a major advantage of this extremely useful tool. There are several possibilities. Let's assume that we are user bob in a node called home_box, that has a private IP and it's behind a firewall, and we can access a second node, called work_box, where we are user william. We can connect from home_box to work_box but not the other way around. Thus, we want to make a encrypted tunnel that enables the coconnection from work_box to home_box. This is known as reverse ssh tunneling.

In order to create this tunnel we should run from home_box.

      
     william@home_box:~$ ssh -R 9999:localhost:22 william@work_box

A session in work_box is opened, and while this session is active, the tunnel works. Then, if we log into work_box, we can connect to home_box making use of the tunnel.

      
     william@work_box:~$ ssh -p 9999 bob@localhost
     The authenticity of host 'localhost (127.0.0.1)' can't be established.
     RSA key fingerprint is b0:b6:f3:78:e2:8d:8f:8b:3f:ab:b4:d4:da:c5:a6:e1.
     Are you sure you want to continue connecting (yes/no)? yes
     Warning: Permanently added 'localhost' (RSA) to the list of known hosts.
     bob@localhost's password: 
     bob@home_box:~$

A problem in this case is that once the initial connection is closed the tunnel collapses. A possible way to alleviate this problem there is to run an application in the connection to work_box, e.g. top trying to keep the connection alive.

This is not the best option. There are better ones, for example, launching a dedicated connection with options -f (detach ssh process from tty), -N (do not execute any command over ssh), and -o TCPKeepAlive=yes to keep the connection alive.

      
     william@home_box:~$ ssh -f -N -o TCPKeepAlive=yes -R 9998:localhost:22 \ 
                            william@work_box
     william@home_box:~$

We can then connect using the new tunnel.

      
     william@work_box:~$ ssh -p 9998 bob@localhost
     bob@localhost's password: 
     bob@home_box:~$

3.4.1 References

1. howtoforge :: reverse-ssh-tunneling

2. SSH Tunneling Made Easy

3. SSH Tunneling

4. Breaking Firewalls with OpenSSH and PuTTY

3.5 Using ssh to make a tarball directly in a remote folder

Created on March 13th, 2015.

You could be interested in preparing a tarball and, for lack of space or to save intermediate steps, transfer on the fly the file to a remote box. For example, let's assume that you want to transfer a directory called data_EXP from a computer called laptop to another computer called backup_server (I know, not very imaginative....). If our working directory is data_EXP parent directory we can then run

      
     $ tar czf - data_EXP | ssh username@backup_server "cat > data_EXP_dir.tgz"

[ previous ] [ Contents ] [ 1 ] [ 2 ] [ 3 ] [ 4 ] [ 5 ] [ 6 ] [ 7 ] [ 8 ] [ 9 ] [ 10 ] [ 11 ] [ next ]

Some Mini-Howtos of Interest