Skip to main content

Joel Liu's Library tagged ssh →  View Popular

29 Sep 09

Speaking UNIX: Stayin' alive with Screen

  • 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.
  • Screen can manage multiple windows
30 Mar 07

Linux.com | Advanced SSH security tips and tricks

  • 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

05 Oct 06

Geek to Live: Set up a personal, home SSH server - Lifehacker

  • 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.
20 Sep 06

UnixTutorials.info - A couple of tricks with the secure shell


  • 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 .
    >




02 Mar 06

Using Rsync and SSH


  • 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).

Automated Backups With rdiff-backup | HowtoForge - Linux Howtos and Tutorials

  • 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.
1 - 12 of 12
Showing 20▼ items per page

Selected Tags

Related Tags

Highlighter, Sticky notes, Tagging, Groups and Network: integrated suite dramatically boosting research productivity. Learn more »

Join Diigo