Joel Liu's Library tagged SSH →  View Popular, Search in Google

Figures 1 through 5 picture the features and operation of Screen. Looking at Figure 1,   assume that you have used SSH to log in to a remote host. Initially, you have your   original shell on your local host (say, your laptop or desktop) and a remote shell. As   usual, you can use the remote shell to run commands on the remote host; output is   encrypted and sent over the SSH connection to your local shell. (In the figures, blue   highlights the shell output that is currently visible.) As lamented above, if your local   shell or the remote shell or the connection between the two is terminated, the   remote shell is terminated, taking your work to the big bit bucket in the sky.

SSH time-lock tricks

 

You can also use different iptables parameters to limit connections to the  SSH service for specific time periods. You can use the /second, /minute, /hour,  or /day switch in any of the following examples.

 

In the first example, if a user enters the wrong password, access to the SSH  service is blocked for one minute, and the user gets only one login try per  minute from that moment on:

 

~# iptables -A INPUT -p tcp -m state --syn --state NEW --dport 22 -m  limit --limit 1/minute --limit-burst 1 -j ACCEPT
~# iptables -A INPUT -p tcp  -m state --syn --state NEW --dport 22 -j DROP

 

In a second example, iptables are set to allow only host 193.180.177.13 to  connect to the SSH service. After three failed login tries, iptables allows the  host only one login try per minute:

 

~# iptables -A INPUT -p tcp -s 193.180.177.13 -m state --syn --state  NEW --dport 22 -m limit --limit 1/minute --limit-burst 1 -j ACCEPT
~#  iptables -A INPUT -p tcp -s 193.180.177.13 -m state --syn --state NEW --dport 22  -j DROP

~# iptables -A INPUT -p tcp -m state --syn --state NEW --dport 22 -m  limit --limit 1/minute --limit-burst 1 -j ACCEPT
~# iptables -A INPUT -p tcp  -m state --syn --state NEW --dport 22 -j DROP

 

In a second example, iptables are set to allow only host 193.180.177.13 to  connect to the SSH service. After three failed login tries, iptables allows the  host only one login try per minute:

 

~# iptables -A INPUT -p tcp -s 193.180.177.13 -m state --syn --state  NEW --dport 22 -m limit --limit 1/minute --limit-burst 1 -j ACCEPT
~#  iptables -A INPUT -p tcp -s 193.180.177.13 -m state --syn --state NEW --dport 22  -j DROP

Anyone who's done any Unix work has used SSH (Secure Shell) to connect to  other computers and perform tasks like transferring files. But you don't have to  be a Unix whiz with a beard, ponytail and penguin tee-shirt to reap the benefits  of the secure, remote computing that SSH offers.

 To copy content of local directory "mydir" to user's home directory >  on a remote machine do: >  

  

   # >  scp -r mydir user@remote-box: > 

   

  To copy in the opposite direction do >  

  

   # scp -r user@remote-box:mydir . >  

   

 This document covers using cron, ssh, and rsync to backup files over a local network or the Internet. Part of my goal is to ensure no user intervention is required when the computer is restarted (for passwords, keys, or key managers).

This tutorial describes how to do automated server backups with the tool rdiff-backup. rdiff-backup lets you make backups over a network using SSH so that the data transfer is encrypted. The use of SSH makes rdiff-backup very secure because noone can read the data that is being transferred. rdiff-backup makes incremental backups, thus saving bandwidth.

But fortunately there is a solution: the use of public keys. We create a pair of keys (on our backup server backup.example.com), one of which is saved in a file on the remote system (server1.example.com). Afterwards we will not be prompted for a password anymore when we run rdiff-backup. This also includes cron jobs which is exactly what we want.