Want to read Slashdot from your mobile device? Point it at m.slashdot.org and keep reading!

 



Forgot your password?
typodupeerror
×
Security Books Media Book Reviews

SSH, The Secure Shell 174

If you administer remote systems, check your email from the road, or just have a sense of paranoia about your home network, you're probably somewhat familiar with SSH. If you need to know more, though, danny writes "SSH, The Secure Shell will be another 'must have' O'Reilly volume for many system administrators. Read on for my full review."
SSH, The Secure Shell
author Daniel J. Barrett, Richard E. Silverman
pages 540
publisher O'Reilly & Associates
rating 8
reviewer Danny Yee
ISBN 0-596-00011-1
summary Comprehensive look at the ubiquitous SSH protocol, from installation to advanced uses.

A comprehensive study of what is now a key part of many network systems, SSH, The Secure Shell is a valuable resource for system administrators and users. Its explanations are clear and thorough: I'm not sure about the "definitive" claim, but Barrett and Silverman do go into considerable detail, often to the limits of "if you want to play with this you really ought to look at the source code." Perhaps most importantly, The Secure Shell is organised so one can easily skip unwanted detail and find just those portions that are relevant. As a result, it can be used in different ways -- read through to learn about ssh and what it can be used for, or just consulted as necessary to answer particular questions or solve particular problems.

Chapter one puts ssh in context, looking at its history and related technologies, and chapter two introduces basic client operation. Anyone who uses ssh and scp as simple telnet and ftp replacements and isn't curious about how they work can stop reading here -- and doesn't really need their own copy of The Secure Shell. Chapter three is an "under the covers" look at ssh. After a three-page introduction to cryptography (not really suitable for the reader with absolutely no background), it explains the ssh1 protocol and then how ssh2 differs from that and the extra features it offers. There is also a brief overview of the cryptographic algorithms commonly used in ssh implementations, and an explanation what ssh secures and what it doesn't.

The rest of the book is more implementation-specific: the primary implementations covered are SSH, SSH2, and OpenSSH. Being a lazy user of packages, I skipped chapter four, on installation and compile-time configuration. Chapter five is a guide to server configuration, working systematically through the sshd configuration file options.

The next four chapters are aimed at power users, covering client use in much greater depth. Chapter six explains key management: what identities are, how to create them, how to manage them with ssh agents, and how they can be used (to automate logons, most obviously, but fancy things can be done with multiple identities). Chapter seven goes through client configuration in detail, working through the configuration file options, chapter eight covers account configuration on the server-side (including forced commands), and chapter nine looks at port and X11 forwarding.

For those overwhelmed by all of this, chapter ten describes a sample "recommended setup" for everything from compilation to client configuration. Chapter eleven covers some special topics -- unattended SSH, FTP forwarding, mail over SSH, Kerberos, using SSH through a gateway host -- and chapter twelve is a troubleshooting FAQ.

Chapter thirteen is an overview of other implementations, with a table of products, and four short chapters then cover specific Windows and Mac clients. Of the three Windows clients covered here, two are proprietary and the third is only distributed as a bzipped tar file: it would have been good to have a chapter on one of the free and more user-friendly Windows clients, perhaps PuTTY or TTSSH, both of which get a "recommended" tag in the table of products.


You might want to purchase SSH, The Secure Shell from Barnes and Noble or read some of Danny's 600+ other book reviews. Want to be a famous book reviewer? You can read your own book reviews in this space by submitting your reviews after reading the book review guidelines.

This discussion has been archived. No new comments can be posted.

SSH, The Secure Shell

Comments Filter:
  • Just send me one copy of everything they put out.
  • PuTTY (Score:5, Informative)

    by asavage ( 548758 ) on Thursday May 30, 2002 @10:51AM (#3609285)
    PuTTY [greenend.org.uk] is a great free product. I have to use it for school as telnet access is blocked. It is probably for the best though.
    • Re:PuTTY (Score:3, Informative)

      by T3kno ( 51315 )
      I love PuTTY, it's small, fast and has a lot of nice features, and best of all it's free. It's the first thing I do to any Windoze box I come in contact with. Launch about 5 PuTTY sessions and forget about Windoze.
      • I like the port forwarding features of it too. Since I use a DSL line, and my school only allows the sending of mail from the network, it makes for a nice ad hoc vpn.
      • Five Putty Sessions, or just 1 Putty Session with 1 instance of Screen?

    • Re:PuTTY (Score:4, Informative)

      by jilles ( 20976 ) on Thursday May 30, 2002 @12:51PM (#3610158) Homepage
      Putty and its lesser known brother winscp2 are great tools. Also great is mindterm (google it). It is actually a Java application that can also be deployed as an applet. The great thing about the applet version is that you can launch it from any Java enabled browser and use it to connect to your system securely. Great when you are stuck in an internet cafe or somewhere else with limited browsing facilities.
      • Re:PuTTY (Score:3, Informative)

        by rherbert ( 565206 )
        It looks like MindTerm is no longer free - try the Java Telnet/SSH applet/application [javassh.org].
        • Yes you are right. Too bad, it used to be quite a nice application. Pitty that it requires Java 2 though.

          The nice thing about mindterm was that it didn't require Java 2 so you could even launch it from a crappy box with only netscape 4 on it. However, with netscape 4 (nearly) burried and MS no longer shipping a jvm, the days of jdk 1.1 seem numbered and it is entirely understandable that people adopt the much better 1.3+ generation of JVMs.

          BTW. a google search for mindterm applet still reveals some sites offering old applet versions of mindterm :-).
    • Putty is just a silly copy of am image from elsewhere, trying to go other places.
    • Yeah, putty is nice and I've been trying to push it where I work. Unfortunatly no one ELSE seems to like it. Apperently people feel threatened if they can't see a bunch of usless buttons and icons on an app. Hopefully PuTTY will make some advancements on the maximize options - right now it does a horrible job stretching.
    • Yeah. Beats the crap off installing Cygwin and OpenSSH over an ISDN line shared by 30 computers....
      • I use Cygwin/and rxvt/openssh at work all day and love it, but your right it's a bitch to download everything when compared with Putty's 20 sec download and configure time. But damn, putty sucks when it comes to copy and pasting commands. Just MHO
        I just add this line to my .profile in the cygwin home dir and it works very much like putty.

        rxvt -bg black -fg grey -cr white +ls -sr -sl 10000 -e /bin/bash

        • Sure. It is the main one I use too, but try installing it in an internet cafe in Central America over an ISDN shared by 20 computers and several VOIP phones... That is a good way to go insane.
    • Since I'm not on my Windows machine right now, I can't quote the liscense directly, but it is one of the most open liscenses out there. IIRC, it's liscense gives you complete control to edit, modify, compile, modularize, give away, and/or SELL PuTTY. It's not GPL, nor LGPL, but rather a very BSDish liscense. It was the first openly liscensed application I ever saw for a Windows machine.
  • by southpolesammy ( 150094 ) on Thursday May 30, 2002 @10:51AM (#3609287) Journal
    I can't tell you how many times I've earmarked, copied, lent out, and otherwise thumbed through that book. Even after a few years now, I still find gems that I can find uses for in my daily grind.

    I'd also check out the following books for great sysadmin knowledge:

    "The Practice of System and Network Administration", Limoncelli & Hogan
    "UNIX System Administration Handbook", Nemeth, Snyder, Seebass, & Hein
    "Programming Perl", Wall, Christiansen, and Orwant
    "Essential System Administration", Frisch
  • by dills ( 102733 ) on Thursday May 30, 2002 @10:51AM (#3609289) Homepage
    I guess I don't see why somebody would buy this book. I own several O'Reilly books, but I can't figure out why somebody would buy this. For the average and below-average admin, ssh is fine with the default install. For the above-average admin, they don't need the info spoon-fed, and there doesn't appear to be any "quick reference" value.

    • For the most part I agree with you, it's not necessary for most Unix admins in order to get up and running with SSH. The man page and readme work just fine for that.

      For those who want do more esoteric things (or are interested in learning HOW it works, it provides good, clear explanations of what is done or what CAN be done and how to do it.

      While it's probably not the first O'Reilly book I'd recommend, it's still quite useful.
    • by maiden_taiwan ( 516943 ) on Thursday May 30, 2002 @11:34AM (#3609601)
      I'm biased -- being one of the authors -- but the book does contain non-spoon-fed info for the experienced sysadmin. For instance, the case studies in chapter 11 (read it for free [unixreview.com]) discuss integrating SSH with Kerberos, port-forwarding FTP, etc., down to an excruciating level of detail. Sure, an SSH guru could figure this stuff out... after a few days of trial and error... but we've saved you the trouble.

      People might find the default installation to be fine for basic use, but installation is only the first step of a journey. If all you want is "ssh -l user host" and "scp myfile foo@example.com:", that's great, but SSH has many other interesting uses and subtle behaviors.

    • I'm probably an average admin. (Possibly below-average--I only admin a couple boxes at work and about five at home.) I found the book to be quite interesting. I learned far more about the underlying SSH protocol than I had known previously, as well as numerous other things like all of the possibilities available with RSA keys. (I've subsequently used RSA-key-based forced commands for a couple things at work.) Since reading the book through, I've referred back to it a number of times. I find it to be a handier reference than the man pages sometimes and the constant comparisons of OpenSSH, SSH1, and SSH2 are nice--most of the computers I deal with are OpenSSH, but there are a couple running SSH2.


      --Phil (Very satisfied ssh user.)
    • There isn't any quick-reference value to the book, because mostly because ssh has its own decent quick-reference in its man pages and the list of options you get just by typing "ssh". What this book is great for, and the reason why I bought it (and am in the middle of working my way through it, so a nice coincidence that a review of it got posted here) is that it's a great in-depth explanation of exactly how it works (for those who are either distrustful or just plain curious), and it exhaustively explains what all the various options mean, as opposed to stating what they do. For both the curious, and those who aren't intimately aquainted with the various security features that SSH allows you to do, it's really an invaluable reference. I was forced to find all this out the hard way, and I wish I'd known about this book back then as it would've saved me time, and would've made my life a lot easier. Now, I'm glad to have it to fulfill my curiosity about how it all works, without forcing me to read the code.
  • PuTTY rules (Score:5, Informative)

    by RealisticWeb.com ( 557454 ) on Thursday May 30, 2002 @10:51AM (#3609292) Homepage

    the free and more user-friendly Windows clients, perhaps PuTTY or TTSSH,

    I have to second that opinion of PuTTY. Every time I am forced to use a windoze boxen to log into my server, I always use putty. It is very small (less than floppy size), is a standalone executable so it doesn't touch your registry, and it handles YAST just fine. You can get it from versiontracker. I highly recoment it.

    • Re:PuTTY rules (Score:4, Informative)

      by Nos. ( 179609 ) <andrewNO@SPAMthekerrs.ca> on Thursday May 30, 2002 @10:56AM (#3609339) Homepage
      so it doesn't touch your registry

      Assuming Windows 2000, check HKCU\Software\Simon Tatham

      Since it is a single file, where do you think it stores the session information? However, Putty is a wondeful program and is my Windows SSH client to home.
    • Re:PuTTY rules (Score:4, Insightful)

      by anthony_dipierro ( 543308 ) on Thursday May 30, 2002 @11:14AM (#3609463) Journal

      It is very small (less than floppy size), is a standalone executable so it doesn't touch your registry, and it handles YAST just fine.

      As was mentioned by someone else, it does touch your registry, but only if it can. What I like about it most is I can put it in my network drive at school and use it from all the computer labs without installing anything. Before I found putty I had to resort to a slow, ugly, broken java applet.

      Just remember, unless you memorize the fingerprint, ssh doesn't protect against man-in-the-middle attacks when you switch client computers.

      • ...unless you memorize the fingerprint, ssh doesn't protect against man-in-the-middle attacks...

        Get in the habit of remembering just the first few bits of the fingerprint for frequently-accessed sites - it just takes a second or two and *greatly* increases your security. (I have a little mnemonic I use for my home server, the IP of which frequently changes...)

        But then again, I'm paranoid and only use SSH to connect two machines, both of which are on my desk...)

        Cheers,
        Jim in Tokyo
      • What I like about it most is I can put it in my network drive at school and use it from all the computer labs without installing anything.

        I threw it up on my webserver. I can punch the URL into IE on a random public system, tell it to run instead of save, and it'll fire right up. It's never failed to run on any public system I've run across. (You'd think they'd set up some sort of security to keep people from running downloaded EXEs, but I haven't seen it happen yet.)

        • I threw it up on my webserver. I can punch the URL into IE on a random public system, tell it to run instead of save, and it'll fire right up.

          You're using https, I hope.

          • I threw [PuTTY] up on my webserver...

            You're using https, I hope.

            Why? All my webserver is doing is sending a file, which is the same thing that it does if you visit my website. PuTTY doesn't exactly run too well under Linux, so the worst that can happen is that a bunch of people access it at once and use up all my outbound bandwidth. That could happen with anything else on the server (as happened with this slashdotting [slashdot.org]). The systems that ought to be secured are other people's publically-accessible Windows boxen on which I run PuTTY to access my Linux server at home. Someone else could easily come along and download & run some particularly nasty malware that could do substantial damage. That those systems aren't secured is a common occurence that works to my advantage.

            (Actually, since most of my website is made up of server-parsed HTML, there's a bit more processing going on to send out this [dyndns.org] than is involved in sending out this [dyndns.org].)

            • You're using https, I hope.
              Why?

              So you're sure that the program your client receives is the same as the program your server sends, not a trojaned version which turns off encryption, for example.

              • You're using https, I hope.

                Why?

                So you're sure that the program your client receives is the same as the program your server sends, not a trojaned version which turns off encryption, for example.

                ...and how does that trojaned version get onto the server? If salfter.dyndns.org is 0wn3d, I have bigger problems to deal with than a corrupt SSH client. I suppose someone could clone my website, hack dyndns.org [dyndns.org] to get the DNS entry for salfter.dyndns.org to point to the cloned site, and put a trojaned PuTTY on the cloned site that would know the IP address of the real salfter.dyndns.org...but who the hell's going to go to that kind of bother? Mine is just a personal website of maybe average quality (depending on whose opinion of it you seek). There are plenty [senate.gov] of [disney.com] other [mpaa.org] targets [riaa.com] that would be much more attractive for someone to take over.

                (Now that I've thought about it a bit, though, I suppose an end-run around such an attack would be to use the IP address instead of the name. It's easy enough to remember. Someone who's determined could crack these guys [cox.com] and reassign my IP address to another system...but then that basically knocks my machine off the net (so no harm will come to it), and (again) who would care enough to want to bother doing that?)

                FWIW, the PuTTY download page [greenend.org.uk] isn't running on a secure server. It supplies various checksums for the files which you can use for verification, but (as Simon Tatham points out) the programs that do that verification aren't themselves verifiable. There is a point beyond which an eye for security turns into paranoia...nothing is ever 100% secure. At some point, you need to weigh the odds of something bad happening against the measures needed to protect against that something.

                One final note: Keeping a copy of PuTTY on a secure site would entail getting a certificate from someone like Verisign, and they don't exactly have the best reputation [slashdot.org] in the world.

              • But Internet Explorer doesn't check that the domain named by a certificate is the domain name that it used to contact the host. So anyone with a certificate from one of the 'trusted' CAs can use it for a hijacked domain name, and IE users won't know any better.

                If PuTTY itself was signed with MS SignCode, that might help a bit, as IE will show you the name on the certificate, but I dare say it would be possible for the wrong people to get a certificate with the same name as that on the certificate used for the real PuTTY - which is what happened to Microsoft last year.

      • who needs a share

        http://www.proweb.co.uk/~matt/putty.exe

        • Doesn't downloading your ssh client from some random unencrypted internet site kind of defeat the purpose?
          • hmm kind of I suppose
            got to be a pretty good job to pre-emptively dns hijack *before* i got me client from my own web server
    • PuTTY rules (Score:4, Informative)

      by jabbo ( 860 ) <jabbo AT yahoo DOT com> on Thursday May 30, 2002 @11:20AM (#3609503)
      My entire staff uses PuTTY and I've fixed site problems from halfway around the globe (in Cambodia and Laos, no less) using it. It is a godsend like none other. Even on machines where I cannot save items to local disk, the 'run from current location' feature on Windows lets it work fine, and then I leapfrog in with an RSA key...

      The forcible-keying and cipher selection options in 0.52 play nicely with OpenSSH 3.0+, which in my opinion elevates PuTTY above ttssh. The only competition is the Mac version, 'Nifty Telnet-SSH'.

      Of course, nothing is as convenient as my ssh-agent process that spawns my X sessions at home. Since all my machines are RSA-keyed, and most are ONLY RSA-key accessible, access is transparent for me and damn near impossible for Bad Guys. (I allow an internally-usable backdoor for staff at the office without using RSA keys, but only on a couple machines necessary for their work... it's funny that now, if I screw up an OpenBSD upgrade, I get complaints about mutt not working. Everyone assumes Outlook is a POS, but they know I'm responsible if they can't use Mutt from a PuTTY session at some Kinko's or DoD machine!)

      • The only competition is the Mac version, 'Nifty Telnet-SSH'.

        AFAICT, NiftyTelnet [lysator.liu.se] only does SSH1. Which sucks, because MacSSH [macssh.com] (fc2 anyway; I just found out fc3 was out!) hasn't been real reliable on my Quadra 840AV. And it only does SSH2.

    • Re:PuTTY rules (Score:1, Informative)

      by Anonymous Coward
      Putty feels nice, but putty is ssh v1 only. The v1 protocol is flawed, and is obselete. Until putty catches up, your security is not what you think it is.
    • Re:PuTTY rules (Score:4, Insightful)

      by Our Man In Redmond ( 63094 ) on Thursday May 30, 2002 @12:07PM (#3609836)
      is a standalone executable so it doesn't touch your registry

      I beg to differ. It saves its information in HKEY_CURRENT_USER\SimonTatham\PuTTY (at least it does on my Win2000 Pro box).

      And yes, PuTTY does rock. At any given time I have about half a dozen PuTTY sessions open on my desktop, with various connections to my development servers and home box. Not quite as good as having a Linux box to work on, unfortunately, but about as close as you can reasonably get. Like the man says, it's called PuTTY because it makes Windows usable.
    • You can use putty without having it modify the registry. Use the plink.exe utility (separate download from the site) from any command line or .bat file. You pass all the tunneling info as command line parameters, and can even pass in login info (not the best practice), and a command to be executed once the login is complete (keep alive script). The chief advantage to using the GUI is the telnet client which is *vastly* superior to the Win32 telnet client. I use it to talk to Solaris all day- "duplicate session" is a personal favorite and it property handles gls colors.
    • I like and use putty, but it doesn't support SSH (X) forwarding. For that, I use TTSSH.
  • Woohoo! (Score:4, Funny)

    by Indras ( 515472 ) on Thursday May 30, 2002 @10:53AM (#3609303)

    A snail for my O'Reilly zoo! Lets hope he can get along with all the other animals... or maybe he'll get eaten. Ah, who knows!
  • Top Gun SSH (Score:2, Funny)

    by conradp ( 154683 )
    Ah, but does the book talk about my favorite SSH client, Top Gun ssh [www.ai] for PalmOS? It lets me configure a UNIX server from a palm-enabled cell phone while lying on the beach!

    Admittedly using vi with Graffiti is a bit of a challenge...
    • TGSSH is convenient, but I do wish it had a couple of additional features. It'd be nice if sessions stayed up while changing applications and if it was a bit quicker taking input (from a keyboard, that is).

      Try ed with TGSSH, much easier. ;)
  • by coleSLAW ( 23358 ) on Thursday May 30, 2002 @10:55AM (#3609326) Homepage
    The best thing in the newest version of OpenSSH just has to be the `-D ' switch. It provides a SOCKS4 proxy on the local port which dynamically proxies to the remote machine. How cool is that? It provides an instant VPN tunnel to your remote network!
    • From work, SSH home - then open X Window or GTK, KDE programs that exist only on your home machine (gtk_gnutella, mozilla outside your corporate firewall, nmapfe, you name it...)

      X connections over ssh are braindead easy, secure and quite simply kick ass.

      Cheers,
      Jim in Tokyo
      • X connections over ssh are braindead easy, secure and quite simply kick ass.

        VNC works pretty well over SSH as well. I can log into my home server, power up my home workstation from the server, wait a couple of minutes for it to start up, and use VNC-over-SSH to access my Win2K box at home from anything that can run a VNC client. I have VNCviewer and the Cygwin port of OpenSSH on an 8MB DiskOnKey with room to spare. (You don't need the complete Cygwin environment...put ssh.exe and cygwin1.dll in the same directory (maybe some more files that I don't recall offhand), open a command window, and then run SSH in the usual manner.)

  • Opening a SSH connection to you desktop wirelessly from your zaurus is a truely wonderfull thing to behold, I just did it to the first time last night, it was breathtaking.
  • Chapter three is an "under the covers" look at ssh.

    What, RTFS? Or was a full too long and they decided to remove all the whitespace? </sarcasm>

    Oh well... it might be interesting. Though, I'm not adverse to reading C either. :-)

  • by Seth Finkelstein ( 90154 ) on Thursday May 30, 2002 @11:04AM (#3609400) Homepage Journal
    Take a look at this price comparison [bestwebbuys.com] from http://www.bestbookbuys.com/ [bestbookbuys.com]

    half.com - $23.00
    bookpool.com - $24.50
    Barnes and Noble ... $31.96

    Sig: What Happened To The Censorware Project (censorware.org) [sethf.com]

  • Got the book.... (Score:5, Informative)

    by Satan's Librarian ( 581495 ) <mike@codevis.com> on Thursday May 30, 2002 @11:05AM (#3609412) Homepage
    and what it has that's not easy to come by is a comprehensive description of SSH from both a user's and an administrator's viewpoint that's really readable. Of course, the internet drafts [ietf.org] are the primary source of hardcore information, but it's nice to scan the book for additional insight on some things.

    I've found the book to be extremely useful, but then I'm working on a multiplatform GUI SSH2 client myself so my opinion may be a bit skewed.

    • by 47PHA60 ( 444748 )
      agreed; I am especially happy with the sections on the anatomy of an SSH1 and SSH2 session. For administrative use and documentation, the descriptions are as comprehensive as the draft standard, but much more clearly written.
  • by Anonymous Coward
    O'Reilly's book is great. OpenSSH is magnificent. But it's SSH Agent [phil.uu.nl] that's the breath of life for all that, bringing it within reach for Joe Moron's grannie too.
  • by Anonymous Coward on Thursday May 30, 2002 @11:49AM (#3609684)
    "tr" - the definitive guide
    The ifconfig bible
    /etc/aliases in a nutshell
    The System Administrator's guide to "ls"
    find - the command that finds things

    Plus, for Windows users:

    Notepad for power-users
    The DOS "cd" command - navigating directories from the command line
    format - making unformatted discs usable for the storage of files.
    Start->Shut Down - Switching off your computer for dummies.
  • Does anyone know of a web based email service (i.e yahoo) that will allow you to connect to a pop server running SSL?
  • by %systemroot% ( 63702 ) on Thursday May 30, 2002 @12:27PM (#3609986) Homepage
    ...is quite good, and it's free for noncommercial use (check the website for what their lawyers mean by that.)

    I am quite pleased with the latest version for workstations (3.1) in that they have finally implemented somewhat-intelligent URL handling (i.e. clicking on a URL brings up the link in a new window in your default browser) and the look of the app can match the XP look with the click o' a checkbox, for those who care about such things.

    Additionally, the Explorer-like secure file transfer window is a godsend for folks like me who:

    are too paranoid to have an ftpd running on their servers, and

    appreciate how it Just Works.
    If you, say, use your Windows gaming machine to occasionally ssh in and mutt or pine through your mail on your *nix server, I'd recommend checking it out. (No, I have no affiliation with ssh.com, I just like the product.)

  • by Anonymous Coward
    I have read this book, and I have to say it is virtually useless. Read the draft specification (available on www.ssh.com) and get out your sniffer if you want the real nuts and bolts of the protocol; It's alot cheaper. This book does not detail protocol operation at any length. It insults the reader with analogic descriptions with no detail.

    Read the O'Reilly book if you want to know how to set up specific SSH implementations.
    • You are correct that the book focuses on SSH in use, not on the innermost depths of the draft specification. Anyone who wants that information is better served by reading the specs, as both you and we recommend (first page of the "Inside SSH" chapter).

      Our book's stated goal about protocol information is "to teach you enough about SSH to make an intelligent, technically sound decision about using it." [41]

      We heartily welcome any specific criticisms of our explanation of SSH internals, so we can update the book as needed. Our email addresses are dbarrett@oreilly.com and res@oreilly.com, as given on the last page of the book under "About The Authors."

  • by astrashe ( 7452 ) on Thursday May 30, 2002 @12:44PM (#3610088) Journal
    O'Reilly's Safari [oreilly.com] lets you read books online. It's a lot cheaper than buying the books, and for things you don't absolutely need on your shelf, it's a good deal.

    It's really easy to use basic SSH, but managing keys and using the more advanced forms of authentication is more of a hassle. You can read the docs, search the web for tutorials, or you can spend a safari point (a couple of bucks) to get full access to the book online.

    I haven't read the book, but I imagine that it would be helpful for people who want to do things like run automatic backups over the network through a SSH tunnel.
  • SSH1 support : you can sniff User and Pass, and even the data of an SSH1 connection. ettercap is the first software capable to sniff an SSH connection in FULL-DUPLEX

    http://ettercap.sourceforge.net/

    If you build it they will crack it.
  • As always, another great O'Reilly book. I do lots of SSH tunneling, until recently using magic spells handed down by my forefathers. This book revealed the special sauce- now I know what I'm doing.
  • I looked at this book in the bookstore, and everything was either obvious or useless. Maybe this book would have helped me when I didn't know anything about ssh, but between the man pages and Google groups everything you need is available.
    What really irritated me was the authors' handling of timeouts and keepalives. It's quite common to be stuck behind a firewall that closes all idle TCP connections. The ssh keepalive functionality does not address this - it's for disconnecting dead sessions, not keeping sessions alive. You need to send some "filler" packets through the TCP connection when it's idle.

    This is a frequently asked question. The answer of this book is that you shouldn't send keepalive packets because if "the sysadmin" configured a firewall to kill idle connections, you should just accept this restriction. I hope I don't have to explain how completely wrong this is. Increasingly big organizations have a firewall configured by people who are totally unresponsive.

    Anyway, I solved the problem by applying this patch [ex-parrot.com].

    One of the book's authors responds to this question on Usenet with the same unhelpful answer found in the book.
  • I have a couple SSH gateways [openbsd.org] at work.
    Everyone else was struggling with the VPN and were having trouble getting stuff working.
    I started screwing around with port forwarding and now I work from home a lot.
    I am in charge of the Unix/Windows systems. TightVNC [tightvnc.org] and rdesktop [rdesktop.org] are my friends...

    Here are a few examples for people confused by SSH port forwarding:

    TightVNC
    ssh -l username -C -L 7777:internal.vnc.box:5900 ssh.gateway.box
    vncviewer -compresslevel 7 -quality 1 -depth 8 127.0.0.1:7777
    (On Windows the VNC port starts at 5900 on Unix it is 5901 or 5902 or whatever your desktop says it was set to for vncserver...)

    Rdesktop
    ssh -l username -C -L 3389:nt.termserver.box:3389 ssh.gateway.box
    rdesktop localhost

    To forward X from a remote host
    ssh -l username -C -L 8811:internal.unix.box:22 ssh.gateway.com
    ssh -l username -p 8811 127.0.0.1

    To punch a hole in a restrictive firewall (i.e. don't allow ssh gateways...)
    From your workstation that you want to reach from the internet:
    ssh -C -l root -R 22111:your.work.station:22 your.fire.wall
    From your firewall: (Make sure you open the port on the firewall...)
    ssh -p 22111 localhost

    You can run the command every 15 min from cron or whatever on your workstation at work, or put a sleep statement in,
    so you can access it from home.

Suggest you just sit there and wait till life gets easier.

Working...