Ssh
Contents |
What is it, and what do I use it for?
ssh (a semi-acronym for Secure SHell), which under FreeBSD is generally the version found under the openssh-portable port, is the command-line tool used to securely access a shell prompt on a remote network computer. Doing this is commonly referred to as "shelling in" to the remote server and can be done from a computer that is not unix-based in the traditional sense (such as Microsoft's Windows OS or Apple's OS X, which is unix-based, but places more emphasis on the GUI and desktop-friendly sensibilities than a more traditional unix).
ssh distributions also typically include such as the command scp for copying files from remote computers, and/or piping arbitrary data streams through SSH tunnels.
There are many Windows-based ssh programs such as TeraTerm SSH (which doesn't support the cryptographically stronger SSH2 protocol but will also allow you to connect via a serial port), MSSH, secure iXplorer, FileZilla (an SFTP GUI), WinSCP (which does SCP via a GUI), and the commercial (but free for non-commercial use) client from SSH Communications. By far the most commonly used non-Cygwin Windows ssh client, however, is the open source application PuTTY.
Technical details and comparisons
In older days the cryptographically-lacking telnet and related applications such as rsh were used to control headless or remote devices. However, telnet is now largely obsolete, surviving mostly only on distinctly aging legacy equipment and physical console access to serial ports on industrial routers. "Serious equipment" such as unix-like servers and heavyweight routers is moving toward access via ssh, while the smaller embedded equipment such as small-office/home-office routers and embedded printservers are moving towards embedded web-based access and configuration (often with SSL connections).
It is historically important to recall that telnet evolved as a standard for use over non-routable networks that were not considered very likely to be tapped, such as VT100-style serial networks and local console ports. As modern networking began drastically increasing the exposure of networked data to more and farther-flung locations, however, packet sniffing became more and more of an issue. An enterprising black-hat who had access to a router, hub, or switch anywhere in between you and the machine you were trying to telnet into didn't necessarily need to know your password ahead of time - he could just log all the packets going to the machine and wait until a login sequence went by, and presto change-o, he's got root. A more patient black-hat might sit and monitor quietly without doing anything for weeks, months, or even years - the longer time went by with no alarm raised, the more sensitive data would go his way down the pike.
Ssh changed all that, by introducing automatic public/private key-based security and authentication across the channel. A black-hat lurking on the network and sniffing packets moving to and from a server controlled via ssh has much less to work with. Since even the authentication challenge and response itself is encrypted against third-party interception, it is very difficult to gain much of value out of sniffing an ssh session.
Of course, things do tend to evolve, and it's always wise to make sure that your version of ssh is up to date before you decide that you're the Fort Knox of the IT world - fairly recently at the time of this writing, serious cryptological flaws were discovered in the older (version 1) ssh protocol, and so currently it is considered best practice to disable ssh1 sessions, forcing ssh2 or nothing.
Using ssh (client)
The syntax is easy:
ssh (options) username@host
where host can be an IP, a hostname in your domain or a FQDN.
for example:
dave@kadath$ uname -a SunOS kadath 5.10 Generic sun4u sparc SUNW,Ultra-60 dave@kadath$ ssh dave@rlyeh The authenticity of host 'rlyeh(10.10.0.254)' can't be established. DSA key fingerprint is 60:53:77:84:ef:9a:7e:3a:dd:e5:9b:d9:68:e0:77:40. Are you sure you want to continue connecting (yes/no)? yes Warning: Permanently added '10.10.0.254' (DSA) to the list of known hosts. Password: Last login: Tue Nov 22 12:38:12 2005 from 10.10.1.4 %uname -a FreeBSD rlyeh.domain 6.0-RELEASE FreeBSD 6.0-RELEASE #0: Thu Nov 3 09:36:13 UTC 2005 root@x64.samsco.home:/usr/obj/usr/src/sys/GENERIC i386 %
Options
As mentioned above, ssh has two major versions: ssh1 and ssh2. For security reasons, it's better to use SSHv2, but you may be forced to use v1 on some servers so:
ssh -1 username@host
If you're using ssh public/private keys, you can specify the key to use with the -i switch:
ssh -1 -i /home/dave/.ssh/smtp.key dave@smtp.domain.tld
What's all this stuff about keys?
SSH can use public/private key pairs for both stronger encryption and authentication. You increase security by adding another layer -- something you know (your password) and something you have (the key you provide to the server) -- and you can prove to the server that it is your key by giving it the password that the key was made with. That said, one common use of ssh keys is passwordless authentication, which is less secure but very handy (e.g., with scripts). The downside of using passwordless authentication with keys is that you have to be very careful to keep your keys secure, since that key is the only thing a black-hat would need to breach your security.
SSH keys are made in pairs, one public and one private. They match each other -- not unlike a physical lock and key. For more information on the theory behind this, see public key infrastructure or PKI.
As it relates to ssh, this is a topic that is sufficiently hairy that there are separate wiki pages for the various aspects of it:
SSH:_Passwordless_authentication
OK, I can use the client, how do I run the server?
SSH is part of the FreeBSD base system, and if you enabled ssh logins during your install, you don't have to do much except verify that the server is running:
rlyeh# ps aux | grep sshd root 468 0.0 0.1 3352 2768 ?? Is 12:14PM 0:00.00 /usr/sbin/sshd
Any changes to your config are made in /etc/ssh/sshd_config, which can be made intricate enough to require it's own wiki page. Go there for info on the server config.
