As anyone who has opened a mailbox full of spam knows, some successful Internet technologies show serious shortcomings in the current hostile Internet environment. OpenSSH is a modern toolkit intended to protect users from both eavesdropping and system breakins; by amateur vandals, professional criminals, governments, etc.
Due to its packet-switching architecture, data traveling between two computers normally flows through several others in transit. The consequence of this is that there are many computers (mostly owned by ISPs) which "see" our transmissions. To get a feel for this, you can use the traceroute command. traceroute www.tidbits.com, for example, shows (at least part of) a path information can travel to www.tidbits.com, including systems belonging your own ISP and several other computers between you and TidBITS. Any of these computers can be configured to record the computers you communicate with, or even to make a copy of all your communications. If this concerns you, the options are either not to use the Internet (increasingly impractical) or to use encryption.
In conventional single-key encryption, a data transmission is protected ("encrypted") with a key (a number, often derived from a password), which is used to modify the data so it's not readable; the recipient can use the same key to easily decrypt the received transmission, restoring the original data (the "plaintext"). All encryption can be broken, but the key to mathematical (computer) encryption is to make it much easier with the key than without. If it takes you 2 seconds to encrypt something, and your recipient 2 seconds to decrypt it, but would take the NSA 50 years to break the encryption, your email is probably safe. This trade-off (difficulty with the key vs. difficulty to break without the key) is a critical factor in all encryption systems. As the state of the art in both hardware and software advances, the time to break a particular encryption decreases, but the feasibility of using stronger encryption tends to keep pace. For example, the Data Encryption Standard (DES) developed in 1975 used 56-bit keys. DES is no longer sufficient for normal use, and was superseded by Triple DES, which provides effectively 112-bit keys. The Advanced Encryption Standard (AES) is in turn the Triple DES successor, and uses 128, 192, or 256 bit keys.
http://en.wikipedia.org/wiki/Data_Encryption_Standard
http://en.wikipedia.org/wiki/Triple_DES
http://en.wikipedia.org/wiki/Advanced_Encryption_Standard
Symmetric encryption is very effective, but raises a major question: how can the sender and receiver establish the key(s) used for communication? In conventional encryption, establishing the key must be done before the encryption can provide any privacy.
http://www.ladlass.com/intel/archives/010256.html
Cryptographers addressed the key-exchange problem with public key encryption, also called "asymmetric cryptography". In public-key cryptography systems such as DSA/DSS, & RSA encryption, there are two linked keys. If key #1 is used to encrypt a message, it can only efficiently be decrypted with key #2 (instead of key #1, as in symmetric encryption); if key #2 is used to encrypt, then key #1 is used to decrypt. It's then possible to keep one key secret (the "private key") and publish the other (the "public key").
If I create both keys and publish my public key, three useful things can happen. First, I can distribute the public key freely, since it's not a problem if attackers get it. Second, people can safely encrypt messages to me with it public key (nobody else can decrypt them without my private key). And third, people can decrypt messages from me with my public key, in the process confirming that they were encrypted by my private key (me). In addition to privacy, this can also provide authentication -- if my private key successfully decrypts a message, the encryptor must have had my private key.
Public-key cryptography underlies SSH, SSL/TLS (mostly used for website encryption, as HTTPS, but also used to decrypt various other protocols, such as IMAP, POP3, SMTP, LDAP, etc.), PGP, and various VPN systems. Unfortunately, public-key cryptography is substantially slower than conventional cryptography. To get around this, public-key systems are used for initial authorization, and after that to transmit encryption keys for fast symmetric encryption systems. The symmetric keys are randomly generated and only used for a single communications session, so they are called "session keys".
Aside from performance, there are several advantages. With email, by encrypting the session key multiple times (with multiple public keys), a message can be encrypted to multiple recipients. Each recipient gets a block of ciphertext which can be decrypted with her own private key (and cannot read the equivalents for the other recipients). Because the session keys are only used for a single session, breaking them is both more difficult and less worthwhile than breaking encryption keys which are used repeatedly. And most importantly, there is no need to establish, exchange, or securely retain encryption keys for every correspondent.
A disadvantage to public-key cryptography is that it cannot guarantee that the possessor of a given key is actually the person or entity it claims to be. There are several ways to handle this. One is to have a trusted party ("Certification Authority") vouch that the key belongs to the claimed identity; this is common with web sites, and can be checked by clicking on the browser's lock icon, which shows the CA and who they believe owned the certificate. Because SSH is normally used between a human (running the ssh command) and a computer, rather than between two humans (as with email), the authentication is asymmetric too. Computer identification is mostly delegated to the Domain Name System (DNS). If I ssh to emperor.tidbits.com, I can generally assume that I'm connecting to a machine under the control of TidBITS (Adam Engst, according to the whois database). Humans may be identified by encrypting/decrypting with their public keys, installed by the user or an administrator
either a) handled by the operating system, outside the scope of public-key cryptography, or handled with priva
This is what the lock in a web browser means. For instance, when I go to https://www.amazon.com/ and click on Safari's padlock, I see that RSA Data Security, Inc. confirms that the SSL certificate I'm using belongs to Amazon.com Inc. PGP uses a personal "web of trust" to tie PGP keys to identities. With SSH, the identity of the server is normally taken on faith, a
http://en.wikipedia.org/wiki/Public-key_cryptography
Since interception of communications is basically unavoidable on the Internet, privacy is gained by encrypting communications, so unauthorized parties are unable to decipher them. Aside from special-purpose encryption techniques, there are three types of encryption that are used in multiple different roles: SSL, SSH, and VPN. SSL works by encrypting an end-to-end connection, such as a web surfer to a web server. This is indicated by the prefix "https" in web URLs. VPNs are comprehensive. As described in "For Your Eyes Only: Virtual Private Networks" they encrypt all traffic from the protected computer(s) to the VPN server. SSH, however, is a bit more complicated.
http://db.tidbits.com/getbits.acgi?tbart=08209
The OpenSSH suite directly replaces a whole host of standard Unix tools, including telnet, rlogin, rsh, rcp, and ftp. In addition, OpenSSH can be used to provided a point-to-point encrypted tunnel (effectively a partial VPN) for TCP connections. This is typically used to protect communications when SSL is not available, and VPN is either not available, or too much trouble.
The classic telnet program is fairly simple and very important -- it connects to another computer, running a telnet server (also called a "daemon"), and allows the telnet user to log in; the telnet program then transfers characters back and forth, as if the user was using a physical terminal attached to the remote computer. SSH goes this one better, by encrypting all the characters before transmitting them over the Internet. The rlogin and rsh programs are similar, but were typically used with a concept of trust. The destination computer has an idea of trusted users and computers, and allows them to connect without logging in.
Similarly, the scp program replaces the rcp remote copy tool with an encrypted version, based on an underlying ssh connection, and the sftp program replaces old-style FTP.
Additionally, SSH offers tunnels: encrypted connections between two machines, which can be used to convey various different types of traffic securely; tunnels are typically used to secure protocols which don't include sufficient built-in security, such as X11 and VNC. Tunnels are useful in many different scenarios.
In the current hostile Internet environment, it's not feasible to trust users or computers based on who or what they claim to be, so SSH adds public-key (also called Diffie-Hellman cryptographic credentials. In the super-abbreviated version, public-key cryptography works by generating two linked pieces of information, called keys, which are basically large numbers (1024 bits is typical, encompassing 2^1024 possibilities, more a google cubed). One of these numbers is kept secret (the "private key"), and the other is not (the "public key"). Information encrypted using the private key can be decrypted using the public key; information encrypted with the public key can only be decrypted by the private key.
There's a lot more to it, of course. In particular, public-key cryptography is much slower than conventional (single-key) cryptography, so public keys are typically used to exchange a disposable "session" key for single-key encryption. But that's enough to get by on for this discussion.
SSH provides several basic capabilities (all with privacy and authentication). First, ssh can carry an interactive session between two computers, allowing humans to interact with remote machines (comparable to telnet/rlogin/rsh). Second, sftp and scp can transfer files to/from remote machines, either interactively or non-interactively. Third, it can provide an encrypted transport for other tools, such as rsync and the X Window System.
OpenSSH uses a directory named .ssh in the user's home directory (written as ~/.ssh) for personal SSH files. System files either go in /etc/ (under Mac OS X) or /etc/ssh/ (on most other systems).
BBEdit has good SSH support, starting with the sftp client (File:Open File from FTP/SFTP Server...) which Bare Bones built into BBEdit. Alternatively, the included bbedit command-line tool can be used to edit files via sftp, or to receive files piped in from other programs, including ssh/scp. BBEdit can be used with ssh-agent/keychain, although this is more complicated than it should be (see BBEdit keychain support, below).
To enable SSH logins to a Mac, open System Preferences, click on Sharing, and check the Remote Login item. This activates sshd (the ssh server, or "daemon").
Here are some sample commands:
ssh reppep@myhost.com (equivalent to ssh -l reppep myhost.com): Log into myhost.com as user reppep.
scp ~/.ssh/id_dsa.pub myhost:.ssh/authorized_keys: Copy my public key to myhost, and install it as the authorized key. Once it's installed, if I have the matching private key, I can login without using the UNIX password on myhost. If there is already an authorized_keys files with keys to retain (as when the account is shared by multiple people with their own public keys), don't do this, as it would overwrite the other people's public keys
ssh www cat .ssh/authorized_keys | bbedit --clean: Read the authorized_keys file on www and open it up in a new BBEdit window; don't prompt me to save the BBEdit window when closing it.
sftp myhost:/etc: Start an sftp session to myhost. If no directory is specified, it starts in the home directory. If a relative path (not starting with a slash) follows the colon, the path is relative to the home directory.
sftp www:.ssh/authorized_keys keys: Copy authorized_keys from www into a file named keys in the current directory on the local system. Note that this only works for "get", not "put" -- use scp or interactive sftp to put files onto a remote system.
So what are some advanced things you can do with SSH?
On my own systems, I use the username pepper. On some other systems, I use a different username. By creating ~/.ssh/config and adding a couple lines to it, I no longer have to specify the username when connecting to these systems. The asterisk is a wildcard, so it matches tidbits.com or www.tidbits.com, emperor.tidbits.com, etc. This applies to any OpenSSH connections, including ssh/scp/sftp, or rsync-over-ssh.
pepper@pepperbook:~$ cat ~/.ssh/config Host *tidbits.com User reppep
The X Window System, used for graphical display on UNIX/Linux systems, is network-aware, but does not use encryption by default, so passwords could be sniffed. OpenSSH can automatically tunnel X11 sessions alongside ssh login sessions. X11 uses the DISPLAY variable to identify the X11 display to use; if it is set before an ssh session is established, ssh can automatically create virtual DISPLAY on the remote system, and connect it through an ssh tunnel to the local DISPLAY. This means X11 "just works" automatically over ssh, as long as X11Forwarding yes is set in sshd_config on the server, and ForwardX11 yes is set in ssh_config on the client (ForwardX11Trusted yes may also be required for use of certain X11 applications, such as Red Hat's python administration tools).
ssh auth & agents explained first.]]
It may not be possible to ssh directly into the desired computer. If forced to go through an intermediate (often called a "bastion host"), it's useful to still have access to encrypted keys on the original client. ssh supports this with "authentication forwarding". For example, I might be sitting at a machine named client, and ssh into another machine called intermediary; then I need to ssh into server. My key is on client; intermediary doesn't have it, as it isn't a fully trusted system. When I ssh server from intermediate, intermediate receives a public-key authentication request (which it can't satisfy) from server. Authentication forwading enables intermediate to securely connect client to server, so they can negotiate public-key authentication for me. It must be enabled with "ForwardAgent yes" in ssh_config on intermediate.
A VPN works by passing all or most Internet traffic through an encrypted tunnel, to protect otherwise-insecure traffic while it travels across the Internet. SSH can do most of this as well. ssh -L securely connects a local port to a remote port. This works well for a variety of protocols which lack sufficient security themselves. For example: ssh -C -4 -L 5901:127.0.0.1:5900 www opens a new listener (fake server) on the client's port 5901 (VNC display #1). Everything sent to this port is encrypted and redirected to port 5900 on the ssh server www (which is VNC port 0, also used by Apple Remote Desktop 2.x). Once this is done, a normal VNC client can connect to 127.0.0.1, port 5901 (VNC display #1), but the connection is actually to www's VNC/ARD2 server. Unfortunately, ARD2 uses both TCP and UDP ports, and doesn't support connecting to alternate ports, so the ARD2 client doesn't work well with SSH tunneling. The version of OpenSSH inlcuded in Mac OS X Tiger 10.4.5 only supports tunneling TCP ports (although multiple ports can be tunneled in a single connection. The latest version of OpenSSH (4.3), however, adds an experimental full VPN (including UDP) tunneling implementation (not yet supported on Mac OS X).
[[root warning]]
-L -R ssh-agent keychain (clear, restart) batch (crontab) |bbedit bbedit sftp:// rsync ssh host command VPN alternative scp remote remote http://www.dyndns.com/ sudo touch /etc/hosts.allow /etc/hosts.deny; bbedit -u /etc/hosts.allow /etc/hosts.deny pepper@pepperbook:~$ ssh pb ssh_exchange_identification: Connection closed by remote host Feb 20 00:25:48 pepperbook /usr/sbin/sshd: refused connect from pb.reppep.com
To make this work, I don't launch BBEdit automatically at login, or from the Dock. Instead I use bbedit -u to start it up, from a window with ssh-agent/keychain running. Additionally, I never stop ssh-agent/keychain, because BBEdit couldn't be reconnected to an agent later without quitting & relaunching it. Instead I simply clear my keys, so BBEdit is always connected to a long-running ssh-agent, and re-loading keys makes them available for BBEdit too.
This is really a shell trick, but [[show tunnels, etc.]]
Note: I hate "SSH", all caps, since it's not a proper acronym, but it's probably not worth fighting that battle here. I am using OpenSSH where possible, ssh as the command, and SSH where necessary to identify the ssh suite in general (where I'm also describing other implementations).
TARGETS=ssh$(EXEEXT) sshd$(EXEEXT) ssh-add$(EXEEXT) ssh-keygen$(EXEEXT) ssh-keyscan${EXEEXT} ssh-keysign${EXEEXT} ssh-agent$(EXEEXT) scp$(EXEEXT) ssh-rand-helper${EXEEXT} sftp-server$(EXEEXT) sftp$(EXEEXT)
/etc/ssh_config Protocol 2 ForwardAgent yes ForwardX11 yes ForwardX11Trusted yes /etc/sshd_config X11Forwarding yes PermitRootLogin without-password