|
|
|
|
|
|
|
|
|
||
|
|
||
|
Partner With Us |
SSH: From Secure Administration to Virtual Private Networking |
Running the OpenSSH Client
OpenSSH
includes SSH client applications; these can be used to establish SSH connections
from any supported *NIX platform. Default client settings are taken from /usr/local/etc/ssh_config,
but can be customized by placing a modified ssh_config
in each user's .ssh directory. We made changes to enable DSA and disable password
authentication in accordance with our security policy:
DSAAuthentication yesSo that we could easily test SSH1 features, we made our client propose protocol version 1 by default. We then used a command line option to override this whenever we wanted to propose SSH2.
PasswordAuthentication no
IdentityFile2 ~/.ssh/id_dsa
Protocol 1
The first time any user connects to a host, SSH offers to add that host's public key to the user's local knownhosts file. In other words: "Do you want to blindly accept that this host is who you think it is?" Config options can close this loophole by allowing only previously-known hosts. Knownhosts files can be seeded by automated update during installation, then locked for production use.
When executed without further qualification, 'ssh hostname' establishes a secure shell session with the named host. Commands can be executed remotely by adding them to the command line: for example, 'ssh hostname xterm'. To create a circuit-layer VPN, use the -L and -R options to forward a specific port. For example:
ssh -L 8001:mailserver:110tells the SSH client to take any traffic addressed to localhost port 8001 and shove it through the secure tunnel to the SSH server. Upon receipt, the SSH server forwards the traffic (now clear text) to mailserver port 110. The -R option permits reverse port forwarding from remote hosts, through the SSH server, to the SSH client. This mechanism allows simple forwarding for protocols that use a single, well-known port: POP, SMTP, Telnet, HTTP, etc.. But it doesn't work for protocols that use arbitrary ports: typically, a well-known control port and a dynamically-chosen data port such as that used by FTP. We'll see later how this limitation has been overcome for FTP. SSH's inability to forward port ranges and dynamic ports is a major issue to contemplate if you're considering using SSH to create a circuit-level VPN.
Another issue is the ability to restrict SSH port forwarding or prohibit shell access. SSH clients must have login accounts on your SSH server. If these accounts exist for a limited purpose, you need to be able to enforce those limitations. Port forwarding can be restricted by options added to the authorized_keys file. The following example illustrates a login limited to forwarding telnet. Once the SSH session is connected, it automatically telnets to localhost. The connection is forwarded to "private", the telnet server specified in the SSH client command line argument. This example restricts the command the SSH client can issue, but has no control over the forwarded destination and port. The following example blocks all port forwarding. We were only successful using these options with SSH1, but hope that SSH2 support will soon be added.
Rounding out the SSH client apps supported by OpenSSH are secure versions of rcp and rlogin, called scp and slogin. However, OpenSSH 2.1 does not include secure FTP (see F-Secure).
|
Running
the OpenSSH Client | |
ISP-Planet's
RSS feed
The Network for Technology Professionals
Legal Notices, Licensing, Permissions, Privacy Policy.
Advertise | Newsletters | E-mail Offers
Webcasts
|
Video: How System Center Helps Reduce IT Costs IBM Cloud Computing for Developers Virtual Event, April 6-8 |
Microsoft Video: OCS and Exchange: Platform Futures MORE WEBCASTS, PODCASTS, AND VIDEOS |