Subject:
Re: SSH Howto
From:
"Martin A. Brown" ####@####.####
Date:
25 Jan 2004 07:18:54 -0000
Message-Id: <Pine.LNX.4.58.0401242351200.18829@copula.wonderfrog.net>
Jeff,
I, too, would support such a document, and would happily provide
some help if asked.
: -Telnet, ftp, and insecure transmission elucidation. Supporting
: examples: tcpdump packets showing the transparency of unencrytped data.
: Define the problem and propose SSH as a solution.
I like your wording "a solution", not "the solution".
I'd also include a note about what SSH doesn't do, and/or what
functions can and should be fulfilled by other pieces of software.
- security for messages transmitted via mail (although the POP or
SMTP connection might be tunneled); go visit GPG / PGP
- network layer encryption; see IPSec
- instead of forwarded TCP tunnels; SSL wrapped services, see
stunnel, openssl and GnuTLS
: -Brief historical summary: SSH1, SSH2 and OpenSSH (which is the focus of
: the document).
Differentiate the SSH protocol from the implementations.
I'd recommend identifying the common implementations of ssh before
mentioning that all of your examples (or most of them) have been
made with OpenSSH. Commercial SSH, LSH, OpenSSH... It's perfectly
fair to allude to the other implementation and then say that your
HOWTO will only discuss the OpenSSH implementation because of its
overwhelming popularity and availability under Linux.
Perhaps also include a brief section about the importance of keeping
your sshd up to date and accessible only from trusted networks.
Point out historical SSH attack vectors and announcements, and
maybe also the theoretical attacks.
- timing analysis and timing attack (AKA "Use keys not passwords.")
http://www.ece.cmu.edu/~dawnsong/papers/ssh-timing.pdf
- OpenSSH v1/v2 (1.99) attack vector (AKA "Don't run SSH v1.")
http://www.securiteam.com/securitynews/5BP0M157PG.html
There's no point in rewriting all of the different historical
problems with ssh, but a few notes about the routine use of network
scanners (by black hats) to gather version information and identify
vulnerable SSH servers would help to explain the suggested use of
network firewalls, host level packet filters and/or tcp_wrappers
to limit exposure.
: -SSH as a secure replacement for telnet, ftp, rsh, rcp and rlogin. Also
: hint at the possibilities for tunneling other plain text protocols (to
: be covered in more depth later).
Excellent.
: -Touch on X11 forwarding.
Here are a few things about X forwarding I'd want to see, if I were
a user.
- difference between these two commands, and why/when to use
"ssh -X $REMOTE" and "ssh -X -f $REMOTE $REMOTEPROGGIE"
- Xauth cookies (required)
- the 127.0.0.1:6xxx listener created on the host running the
sshd ($REMOTE)
(Also "ssh -C -X $REMOTE".)
: 2. Installation and key generation
:
: -As OpenSSH is standard on most distros, the description of the
: installation proper will be somewhat cursory, but will include a nod to
: the necessary ancillary packages (i.e OpenSSL and zlib).
I'd think something more like "go look at the installation docs"
would be better. No point in rehashing, especially when this may
change periodically, and you may not wish to stay up to date on the
vagaries of installing a particular version. Then again, if it's
relevant for a particular feature you are describing....
: -A Brief description of RSA/DSA and public key encryption (at least as
: much as my limited mathematical mind can wrap itself around).
Brief. Keep it very brief.
: -Key generation (ssh-keygen) and touch upon key management.
Excellent! Include, also, perhaps:
- the use of the keyfile by the client, "-i $HOME/.ssh/id_dsa"
"-o IdentityFile=$HOME/.ssh/some-other-key"
- protecting the keyfile (and user-level directories)
- the difference between passwords and passphrases
- restricting the use of a key to a particular IP address or to a
particular command
: 3. SSH Client Use and Configuration.
:
: -ssh from the command line and some of the more commonly used options
: (with supporting examples).
Absolutely! And this is probably the section that users will be
looking at most often in the early moments of their OpenSSH usage.
: -scp and sftp
Explain that sftp requires the sftp subsystem in sshd_config.
Explain that scp requires only a working sshd (and a remote scp).
: -In depth key management including using keys for connecting to remote
: machines without a password. In this section I will cover ssh-add from
: the command line as well as using it at cli login (.bash_profile) and
: GUI (gnome) login.
A wonderful idea! While on key management, after introducing
ssh-agent, maybe mention keychain, as well.
http://www-106.ibm.com/developerworks/library/l-keyc.html
: -Client side config files (i.e. ~/.ssh/*)
Permissions on client-side files and directories.
: 4. The SSH Server and Configuration
:
: -The sshd daemon
: -sshd logging
: -Server side config files (i.e. /etc/ssh/*)
: -Server side security (tcp wrappers)
Allude also to host based iptables/ipchains and network firewalls
: -Port forwarding (X11, TCP, etc.)
Running a remote command or rsync.
- "echo test | ssh $REMOTE mail -s 'from remote' $MAILADDR"
- "rsync -e ssh -az $HERE $THERE"
: -Examples
Indeed. As many examples as you can stomach!
: -Print sources (The O'Reilly "snail" book comes to mind here)
Bing! When I first saw your post, I thought of this book.
: -Client software for non-linux systems (i.e. MindTerm for Java, and
: Putty for MS-Windows).
Sure. We aren't always lucky enough to be supporting only OpenSSH
under Linux. In addition to PuTTY, you could mention that OpenSSH
(server and client) is available under CygWin on Windows (blech).
A few other things I would add:
- Add an example of debugging an SSH connection.
- What does a permissions error on $HOME/.ssh/ look like? In the
server log? From the client's perspective (depending on server
config)?
- The different ToS used at the network layer (0x10 for
interactive sessions).
- Introduce PPP over SSH VPN tunnels (and why they are ugly).
Well! There are a handful of ideas. I think a complete SSH HOWTO
would be a welcome document in the collection.
-Martin
* Thanks also to Mark Tinberg for some brainstorming with me on
good things to have in an SSH HOWTO.
--
Martin A. Brown --- Wonderfrog Enterprises --- ####@####.####
