Eleven SSH Tricks
Ports are the numbers representing different services on a server; such as port 80 for HTTP and port 110 for POP3. You can find the list of standard port numbers and their services in /etc/services. SSH can translate transparently all traffic from an arbitrary port on your computer to a remote server running SSH. The traffic then can be forwarded by SSH to an arbitrary port on another server. Why would you want to do this? Two reasons: encryption and tunneled connections.
Many applications use protocols where passwords and data are sent as clear text. These protocols include POP3, IMAP, SMTP and NNTP. SSH can encrypt these connections transparently. Say your e-mail program normally connects to the POP3 port (110) on mail.example.net. Also, say you can't SSH directly to mail.example.net, but you have a shell login at shell.example.net. You can instruct SSH to encrypt traffic from port 9110 (chosen arbitrarily) on your local computer and send it to port 110 on mail.example.net, using the SSH server at shell.example.net:
ssh -L 9110:mail.example.net:110 shell.example.net
That is, send local port 9110 to mail.example.net port 110, over an SSH connection to shell.example.net.
Then, simply tell your e-mail program to connect to port 9110 on localhost. From there, data is encrypted, transmitted to shell.example.net over the SSH port, then decrypted and passed to mail.example.net over port 110. As a neat side effect, as far as the POP3 dæmon on mail.example.net knows, it is accepting traffic from shell.example.net.
SSH can act as a bridge through a firewall whether the firewall is protecting your computer, a remote server or both. All you need is an SSH server exposed to the other side of the firewall. For example, many DSL and cable-modem companies forbid sending e-mail from your own machine over port 25 (SMTP).
Our next example is sending mail to your company's SMTP server through your cable-modem connection. In this example, we use a shell account on the SMTP server, which is named mail.example.net. The SSH command is:
ssh -L 9025:mail.example.net:25 mail.example.net
Then, tell your mail transport agent to connect to port 9025 on localhost to send mail. This exercise should look quite similar to the last example; we are tunneling from local port 9025 to mail.example.net port 25 over mail.example.net. As far as the firewall sees, it is passing normal SSH data on the normal SSH port, 22, between you and mail.example.net.
A final example is connecting through an ISP firewall to a mail or news server inside a restricted network. What would this look like? In fact, it would be the same as the first example; mail.example.net can be walled away inside the network, inaccessible to the outside world. All you need is an SSH connection to a server that can see it, such as shell.example.net. Is that neat or what?
If a port is reassigned on a computer (the local port in the examples above), every user of that computer sees the reassigned port. If the local system has multiple users, tunnel only from unused, high-numbered ports to avoid confusion. If you want to forward a privileged local port (lower than 1024), you need to do so as root. Forwarding a lower-numbered port might be useful if a program won't let you change its port, such as standard BSD FTP.
By default, a tunneled local port is accessible only to local users and not by remote connection. However, any user can make the tunneled port available remotely by using the -g option. Again, you can do this to privileged ports only if you are root.
Any user who can log in with SSH can expose any port inside a private network to the outside world using port forwarding. As an administrator, if you allow incoming SSH connections, you're really allowing incoming connections of any kind. You can configure the OpenSSH dæmon to refuse port forwarding with AllowTcpForwarding no, but a determined user can forward anyway.
A config file option is available to forward ports; it is called LocalForward. The first port-forwarding example given above could be written as:
Host forwardpop Hostname shell.example.com LocalForward 9110 mail.example.com:110
Fast/Flexible Linux OS Recovery
On Demand Now
In this live one-hour webinar, learn how to enhance your existing backup strategies for complete disaster recovery preparedness using Storix System Backup Administrator (SBAdmin), a highly flexible full-system recovery solution for UNIX and Linux systems.
Join Linux Journal's Shawn Powers and David Huffman, President/CEO, Storix, Inc.
Free to Linux Journal readers.Register Now!
- Download "Linux Management with Red Hat Satellite: Measuring Business Impact and ROI"
- Chris Birchall's Re-Engineering Legacy Software (Manning Publications)
- The Italian Army Switches to LibreOffice
- Linux Mint 18
- Petros Koutoupis' RapidDisk
- ServersCheck's Thermal Imaging Camera Sensor
- Oracle vs. Google: Round 2
- The FBI and the Mozilla Foundation Lock Horns over Known Security Hole
- Privacy and the New Math
Until recently, IBM’s Power Platform was looked upon as being the system that hosted IBM’s flavor of UNIX and proprietary operating system called IBM i. These servers often are found in medium-size businesses running ERP, CRM and financials for on-premise customers. By enabling the Power platform to run the Linux OS, IBM now has positioned Power to be the platform of choice for those already running Linux that are facing scalability issues, especially customers looking at analytics, big data or cloud computing.
￼Running Linux on IBM’s Power hardware offers some obvious benefits, including improved processing speed and memory bandwidth, inherent security, and simpler deployment and management. But if you look beyond the impressive architecture, you’ll also find an open ecosystem that has given rise to a strong, innovative community, as well as an inventory of system and network management applications that really help leverage the benefits offered by running Linux on Power.Get the Guide