• Like
SSH_Operation_and_techniques.v0.9.ppt
Upcoming SlideShare
Loading in...5
×

SSH_Operation_and_techniques.v0.9.ppt

  • 1,039 views
Uploaded on

 

  • Full Name Full Name Comment goes here.
    Are you sure you want to
    Your message goes here
    Be the first to comment
No Downloads

Views

Total Views
1,039
On Slideshare
0
From Embeds
0
Number of Embeds
0

Actions

Shares
Downloads
28
Comments
0
Likes
1

Embeds 0

No embeds

Report content

Flagged as inappropriate Flag as inappropriate
Flag as inappropriate

Select your reason for flagging this presentation as inappropriate.

Cancel
    No notes for slide
  • In this talk, we’ll look at basic SSH operation, port forwarding, X Windows forwarding, and the installation and use of SSH keys. By the time we’re done, you should have the background needed to start using ssh and ssh keys to encrypt terminal sessions, X applications, and other types of TCP traffic. Copyright 2001, William Stearns <wstearns@pobox.com>
  • SSH’s first use was as a replacement for rsh, the Unix r emote sh ell application. This tool allowed one to connect to a shell on a remote machine. The tool suffered from two major shortcomings. First, like telnet it sent all traffic in cleartext, meaning that a sniffer tool at any point between the two machines could read all commands sent and replies received. Secondly, the /etc/hosts.equiv and ~/.rhosts files listed trusted machines and users; these could make rsh connections without any further authentication. If an attacker compromised any of these trusted hosts, they would immediately get access to the rsh server with no more effort. Also, if the attacker was successfully able to spoof the IP address of a trusted host, they’d get the same access. SSH encrypts all traffic, including the password or key authentication. It also uses host keys to definitively identify both hosts involved in the communication, getting around man-in-the-middle attacks and IP spoofing.
  • The licensing issue is rather complex; depending on which release of the ssh1 and ssh2 applications you choose: Source code may or may not be available Use may be free or for cost for educational institutions Use may be free or for cost for companies The O’Reilly SSH book covers this in good detail. The SSH1 protocol has some shortcomings that aren’t easily fixed except by using the newer, but incompatible SSH2 protocol. If possible, you should use SSH clients and servers that support SSH2 and prefer it over SSH1 protocol connections.
  • See http://www.openssh.org for downloadable tar files and compiled versions for your particular Unix flavor. While this presentation is primarily concerned with the syntax used in the command-line versions of SSH on Linux, the concepts apply to the GUI versions and command-line versions for other platforms. http://www.openssh.org and http://www.freessh.org have links to other SSH client and server implementations for all sorts of operating systems and platforms. While I might not use it frequently, there are SSH implementations for the Pilot and compatibles. Logging in can take a while with my poor handwriting…
  • The normal terminal use on the first line will open a connection from your machine to the SSH Server. The two ends will exchange identification information (so both know that the other has not been compromised or replaced). At that point, you need to authenticate yourself. The easy way is with a password, but we’ll look at how to use ssh keys and the advantages of doing so. The password you’ll use is the exact same password you’ve been using with telnet in the past; ssh understands how passwords are stored in /etc/shadow * Instead of starting up a terminal session as the first two examples, one can specify a single remote command to run on the remote machine as in the third example. In the last example, the “-v” instructs the local ssh client to be verbose about the login process. It’s marvelously useful when you’re unable to login for some reason as it displays all the negotiations going on between client and server. Each time you first connect to an SSH server, it will send back its Host Key. At the first connection, you’ll be asked to verify that the the key received is in fact from the host to which you wanted to connect; you can check this by comparing the key to the one stored in the server’s /etc/ssh directory. In future connections, the key received will be compared to the one stored on the client during the first connection; if they differ, ssh will complain loudly because some machine might be impersonating the machine to which you wanted to connect. * You have converted your system over to using shadow passwords, right? To check, does the /etc/passwd contain “:x:” immediately after each username? If not, look at “man pwconv” man page and see http://ww.linuxdoc.org/HOWTO/Shadow-Password-HOWTO.html for background information.
  • The “-L” is a shorthand for listen for connections on L ocal (on this client computer) port (in this example 5110), and when you hear one, send all its packets to the remote machine (mailserver) and feed them into port 110 on mailserver. The above example would be a great way to encrypt the pop email download from a remote mail server. Before pressing “Get New Mail”, one starts up the above ssh command. The ssh terminal will sit at a prompt, waiting for a command – let it sit. In the mail software, tell it that your pop mail server is on the machine “localhost” and is listening on port 5110. When you press “Get New Mail”, the mail server will talk to port 5110 on the local box. The ssh software, told to listen there, will take all the pop mail requests, encrypt them, and carry them to port 110 on the real mail server. Likewise, it will bring back all the pop responses – your mail messages -, encrypt them, and carry them back to your local mail software. Your mail server doesn’t need to know anything about encryption at all. You can have multiple port forwards on one command line, such as: ssh –L 5110:mailserver:110 –L 5143:mailserver:143 –L 5025:mailserver:25 mailserver , allowing you to transparently encrypt any and all traffic heading to the pop, imap, or smtp mail services on mailserver. As soon as you close the ssh session, the port forwarding stops and you need to connect to the mail server directly as you’ve done in the past.
  • The “-R” is a shorthand for listen for connections on R emote (on the ssh server computer) port (in this example 80), and when you hear one, pull all its packets back to the local machine (MyMachine) and feed them into port 8000 on MyMachine. The crucial difference here is the fact that ssh listens on the remote machine for incoming tcp connections and carries them back to a server on the local machine. The server that will actually handle the requests needs to be running on the local machine. Please note that port forwarding in ssh only works for TCP ports; that’s why we don’t need to specify a protocol on the command line. If you want to do port forwarding for UDP, you’ll need to look at Network Address Translation (NAT) facilities in the Linux kernel or use a UDP proxy. Remember that that approach loses the encryption that SSH gives for free for TCP.
  • With this arrangement, the application is actually exectuing its instructions on the remote machine’s processor, using the remote machine’s memory, and interacting with the remote machine’s disk; only the keystrokes and mouse movemenents come from the local machine, and all the X screen output comes back to the local machine’s display. This setup is the exact graphical equivalent of running text applications inside the ssh terminal. Because X Windows apps were designed from the start to handle this split between the machine running the code and the machine showing the display, this SSH X Forwarding works even between machines with different processors and Operating Systems. By the way, if this doesn’t work, check for the following message at login time: Warning: Remote host denied X11 forwarding. If you see this, it means that the ssh server configuration file (usually something like /etc/ssh{2}/sshd_config has a line such as X11Forwarding No
  • The local and remote file specifications are of the form user@host:/path/to/file If you're including wildcards, you should include the block in quotes, such as: scp –p "wstearns@mailserver:/home/wstearns/mail/*" /home/wstearns/mailtransfer/ In this example, we're copying all the mail files from the mail machine to the mailtransfer directory on the local machine. If omitted, user, machine, and directory default to local username, local machine, and current directory, respectively. The "-p" preserves ownership and permissions. By specifying remote machines for both the source and destination, files can be copied between two remote machines.
  • The serious problem with the password approach, whether used with telnet or with ssh, is that the password you need to enter at the client end is stored on the server. Even though it’s stored in an encoded form in /etc/passwd or /etc/shadow, this password can be cracked with brute force once one has access to that file. The difference with the public/private key split is that if an attacker gets the public key stored on the server, that public key cannot be used to get back into the server! Only the private key, kept on the client only, can be used to get into a server with the public key.
  • “ man ssh-keygen” will give you the exact syntax for the version of SSH on your machine. Running this command will create two files: ~/.ssh/identity_file (the private key) and ~/.ssh/indentity_file.pub (the public file). The private file is an unreadable binary file; this one should never leave your control. ~/.ssh/identity_file.pub is the public key that needs to be copied over to each server you want to access. The passphrase is a long phrase with lots of varied characters. It’s like a password, but longer and with more strange characters. It encrypts the private key before storing it on the disk; this makes the file useless to someone who manages to steal it from your disk unless they also know the passphrase. If you’re worried that we’ve traded short passwords for a lot of complexity and long passphrases, don’t worry! We’ll see that ssh-agent can let us enter the passphrase once and remember the private key. Also, by putting the public key on many machines, the one private key can give us access to lots of remote machines.
  • The three major flavors of SSH are: Commercial SSH1 (which supports the SSH1 protocol), Commercial SSH2 (which supports the SSH2 protocol) and OpenSSH (which can talk both protocols). OK, that’s not too bad. Here’s the problem: All three applications store the private and public keys in different files, in different directories, and in different formats. When the public key is copied to the server, it may need to go in a few different files, occasionally requiring editing more than one file on the server. In short, if the client and server in question at least can talk the same protocol, there’s a way to set up a keypair so that you can get from the client to the server. After I learned how it was done (read on), I wrote a tool that automates the process of creating the keys and installing them to the remote machine. ssh-keyinstall is a free (GPL’d) script that creates the keys and installs them on as many servers as you’d like. You’ll need a valid password on the remote machine only long enough to run the script; after it’s done you can use keys from that point on. See chapter 6 of “SSH, The Secure Shell, The definitive guide” for the gory details (it happens to be online at http://www.oreilly.com ; this generous act by O’Reilly prompted me to buy the entire book).
  • Look familiar? You can do exactly the same kinds of things when you used a password to authenticate yourself. The only difference is that ssh will prompt you for the pass phrase you assigned to the private key when you try to log in.
  • ssh-agent has a weird quirk; it needs to start up as a background daemon, but it also needs to tell the applications that need to use it where to ask for keys. It does this by setting environment variables, so it has to start up a shell or X windows. Any applications you start inside that shell or X Windows session can then ask ssh-agent to provide them with an ssh key. In some X Windows setups, one can add the following lines to ~/.xsession to automatically start ssh-agent: eval `ssh-agent` ssh-add When ssh-agent starts up, it doesn’t have any keys in memory; the ssh-add command asks you for the passphrase for a given key, then hands the unlocked key to ssh-agent so it can later hand it out to future ssh sessions. For reference, SSH supports agent forwarding, where you can ssh to Machine1, logging in with a key provided by your client’s ssh-agent, and ssh from Machine1 to Machine2, and have the ssh-agent request sent back to your original client’s ssh-agent as well. This allows you to keep the private key only on the local machine, but jump from machine to machine without having to start fresh sessions directly from the client machine.
  • Fanout is great when you have to run checks on multiple machines, for example: fanout “localhost mailserver webserver” “cat /etc/redhat-release” will return the RedHat version number of each machine. fanout “localhost lab1 lab2 lab3 lab4 lab5” “rpm –Uvh ftp://mirror.stearns.org/pub/redhat/telnet-server-0.13.1-6.i386.rpm” The top of the script shows other examples.
  • Rsync duplicates the local file tree on the remote machine by: Ignoring files that are identical on the local and mirror machines. Copying any files that don't exist on the mirror. Deleting any files on the mirror that aren't on the local machine. Sending over only the changed portions of any files that differ between the local and remote machines. This last feature sets it apart from other synchronization tools; by only sending over the changed portions, one conserves bandwidth by only sending over the changed bytes. Rsync was written with ssh in mind. By adding the "-e ssh" to the command line, rsync carries all its communication over ssh. The tool, and more info, are available at http://rsync.samba.org
  • Rsync and ssh provide the first three features. By using a Unix feature called hardlinks, 10 daily snapshots of a 5 megabyte file that hasn't changed take only 5 megabytes of space on the backup server. If that file is used on 10 machines (because, perhaps, it comes with the distribution used on all 10), those 50 5 megabyte files take up only 5 megabytes on the server! As the documentation mentions, the freedups package from http://www.stearns.org/freedups/ is required to get this benefit.
  • Because of the way the way the client gains access to the server, passwords cannot be used. When the client on 1.2.3.4 logs into the server, the backup process moves into /backups/1.2.3.4/current/ . Running the backup with password authentication bypasses this step, with potentially disastrous results to the servers main drive.
  • The first performs a full backup of the client, with the exception of any files listed in ~/.rsync-backup/localbackuponly and ~/.rsync-backup/exclude. Files listed in the former aren't sent to the server because of their sensitive nature (/etc/shadow, ssh private keys, password files, etc.). These are tarred up locally and should be moved onto a floppy. Files listed in exclude are files that don’t need to be backed up at all (cache directories, coredumps, etc.). The second form simply limits the backup to a few local directories. While both forms appear to be backing up to the backup servers top level directory, the use of ssh keys forces the backup to start in the /home/1.2.3.4/current/ directory.
  • “ SSH, The Secure Shell, The Definitive Guide” was written by Daniel J. Barrett and Richard E. Silverman and published by O’Reilly and Associates ( http://www.oreilly.com ). ISBN 0-596-00011-1 I have more information about ssh in the Ssh-Intro and Ssh-Techniques documents on my web site. The entire site is mirrored at a number of mirrors, including ftp://ftp.stearns.org/ and ftp://uml.ists.dartmouth.edu/wstearns/ .

Transcript

  • 1. SSH Operation The Swiss Army Knife of encryption tools…
  • 2. SSH Features
    • Command line terminal connection tool
    • Replacement for rsh, rcp, telnet, and others
    • All traffic encrypted
    • Both ends authenticate themselves to the other end
    • Ability to carry and encrypt non-terminal traffic
  • 3. Brief History
    • SSH.com’s SSH1, originally completely free with source code, then license changed with version 1.2.13
    • SSH.com’s SSH2, originally only commercial, but now free for some uses.
    • OpenSSH team took the last free SSH1 release, refixed bugs, added features, and added support for the SSH2 protocol.
  • 4. Installation
    • OpenSSH is included with a number of Linux distributions, and available for a large number of Unices
    • On RPM-based linuxes:
      • “ rpm –Uvh openssh*.rpm”
  • 5. Basic use
    • ssh SshServerName
    • ssh –l UserName SshServerName
    • ssh SshServerName CommandToRun
    • ssh –v SshServerName
    • Server Host Key checks
    • Uses same login password
    • And if we need to encrypt other traffic?
  • 6. Port Forwarding – real server on remote machine
    • I want to listen on port 5110 on this machine; all packets arriving here get sent to mailserver, port 110:
      • ssh –L 5110:mailserver:110 mailserver
  • 7. Port Forwarding – real server on this machine
    • All web traffic to my firewall should be redirected to the web server running on port 8000 on my machine instead:
      • ssh –R 80:MyMachine:8000 firewall
  • 8. X Windows forwarding
    • No setup – already done!
    • Run the X Windows application in the terminal window:
      • xclock &
      • The screen display shows up on your computer, and any keystrokes and mouse movements are sent back, all encrypted.
  • 9. Securely copying files
    • scp
    • scp –p localfile remotemachine:/remotepath/file
    • Prompts for authentication if needed
    • All traffic encrypted
    • Replaces ftp, rcp, file sharing
  • 10. SSH key background
    • Old way: password stored on server, user supplied password compared to stored version
    • New way: private key kept on client, public key stored on server.
  • 11. SSH key creation
    • General command:
      • ssh-keygen –b 1024 –c “Comment” –f ~/.ssh/identity_file
    • Different forms for each of the SSH flavors
    • Assign a hard-to-guess passphrase to the private key during creation.
    • Key can be used for multiple servers
  • 12. SSH key installation
    • 3 versions of ssh: interoperability is good, but poorly documented
    • ssh-keyinstall utility automates the creation and installation
      • “ ssh-keyinstall –s SshServerName” creates keys, if needed, and installs them on the remote server
      • Need password during key install only
  • 13. Using SSH keys
    • ssh SshServerName
    • Ssh –l UserName SshServerName
    • ssh SshServerName CommandToRun
    • Ssh –v SshServerName
  • 14. ssh-agent
    • Remembers your private key(s)
    • Other applications can ask ssh-agent to authenticate you automatically.
    • Unattended remote sessions.
    • ssh-agent bash
    • ssh-agent startx
    • eval `ssh-agent` #Less preferred
    • ssh-add [KeyName]
  • 15. Fanout
    • Runs command on multiple machines by opening separate ssh session to each
    • fanout “machine1 machine2 user@machine3” “command params”
    • Gives organized output from each machine
  • 16. File synchronization - Rsync
    • Rsync copies a tree of files from a master out to a copy on another machine.
    • Can use ssh as its transport.
    • rsync –azv –e ssh /home/wstearns/webtree/ mirror.stearns.org/home/web/
  • 17. Rsync-backup
    • Rsync-backup automates the process of backing up machines with rsync and ssh.
    • Features:
      • Only changed data shipped
      • All permissions preserved
      • All communication encrypted
      • Unlimited snapshots
      • Use <= 2X-4X combined client capacity
  • 18. Rsync-backup client install
    • Install ssh, rsync, and rsync-backup-client rpms (see http://www.stearns.org
    • Install ssh-keyinstall on client to create a backup key with
      • ssh-keyinstall –s backupserver –u root –c /usr/sbin/rsync-backup-server
  • 19. Rsync-backup server install
    • Install ssh, freedups, rsync-static, and rsync-backup-server rpms
    • Turn off password authentication in /etc/ssh/sshd_config
  • 20. Rsync-backup examples
    • Examples of backup commands:
      • rsync-backup-client / root@backupserver:/
      • rsync-backup-client /usr /home/gbk root@backupserver:/
  • 21. Links and references
    • http://www. ssh .com
    • http://www.openssh.org
    • SSH, The Secure Shell, The Definitive Guide
    • ssh-keyinstall, fanout, rsync-backup, freedups and other apps at http://www.stearns.org/
  • 22. More links
    • Docs at http://www.stearns.org/doc/
    • http://www.employees.org/~satch/ssh/faq/ssh-faq.html
    • http://rsync.samba.org
    • William Stearns [email_address]