OpenSSH New Feature: “Netcat mode”

The new version (5.4) of OpenSSH has been released early this morning. OpenSSH is THE free implementation of the SSH protocol available on common devices and operating systems.

The primary goal of OpenSSH is to allow remote access to hosts for management purpose. But many other features make OpenSSH a real Swiss-army knife for all network and system administrators:

  • Multiple encryption methods,
  • Files transfer using SCP or SFTP,
  • Port forwarding,
  • SOCKS proxy server,
  • VPN (tunneling),
  • X11 forwarding,
  • Multiple authentication methods and single sign-on (via the agent-forwarding).

Some OpenSSH release just fix bugs or introduces light changes. But today, the release 5.4 comes with a new exciting feature looking very interesting to me: the “netcat mode”. Quoted from the release notes:

Added a ‘netcat mode’ to ssh(1): “ssh -W host:port …” This connects stdio on the client to a single port forward on the server. This allows, for example, using ssh as a ProxyCommand to route connections via intermediate servers.

Netcat can also be compared to a Swiss-army knife at TCP/IP level. It is a multi-purpose tool which allows to read and write data across network connections. Originally, it was a tool available on UNIX flavors but Netcat (or “nc”) is  also available for Windows [Note: the Windows version is often detected as suspicious by common anti-virus softwares]. Netcat lacks of … encryption (if your original data are in clear text) but now, with the brand new OpenSSH, we can pipe data safely!

Example #1: I’m connected via a wild WiFi network or your Internet Service Prodiver does not allow  outgoing traffic via the SMTP port (TCP/25): [Note: In this example and all others below, we assume that both server and client are running version 5.4]

$ ssh -p 443 -W's password:
220 ESMTP a10si9247793bky.86
250 at your service
221 2.0.0 closing connection a10si9247793bky.86

Example #2: Let’s open a telnet session to an old switch without SSH support (this time, I’m authenticated using a key pair):

$ ssh -p 443 -W
Connected to
Escape character is '^]'.

User Name : ^]
telnet> close

But you will ask: “What’s the difference with the “-L” option available for years?”. Indeed, for a while, OpenSSH allows port forwarding as in this xample:

$ ssh -p 443 -L 2300:

The SSH client will bind to port 2300 on the loopback and forward any incoming packet to the remote IP But they are two constraints with the classic port forwarding method:

  • Once the SSH session has been opened and the port successfully binded, you need to use a native client to connect on this port. And such command can be disabled by a local security policy or not installed at all! A common usage is to create a tunnel for POP3 traffic (TCP/110) but a POP3 client will be required and reconfigured to use the localhost/port defined at the command line level.
  • SSH must bind a port to the localhost. To bind a port below 1024, you must have root privileges! This can be a problem if the client cannot change the default port. And even if the chosen port is above 1024, traffic can be blocked by local firewall rules.

As OpenSSH connects STDIO to the remote host/port, you are free to type your commands or data, copy/paste them or pipe them to the SSH process.

Example #3: You need to transfer a binary file to a remote server which runs Netcat in listening mode but you don’t have Netcat available on the current computer:

cat binary.jpg | ssh -W netcathost:4000

This new “netcat mode” is IMHO a killer feature in this new release of OpenSSH but it should not shadow other changes such as:

  • SSH Version 1 support is now disabled by default! After 10-years!
  • A ‘read-only’ mode is available to sftp-server.

For a complete review of changes and bug fixes, have a look at the official announce.


  1. This is the way the “Agent-Forwarding” works. Quoted from the OpenSSH homepage:

    “An authentication agent, running in the user’s laptop or local workstation, can be used to hold the user’s RSA or DSA authentication keys. OpenSSH automatically forwards the connection to the authentication agent over any connections, and there is no need to store the RSA or DSA authentication keys on any machine in the network (except the user’s own local machine). The authentication protocols never reveal the keys; they can only be used to verify that the user’s agent has a certain key. Eventually the agent could rely on a smart card to perform all authentication computations.”

  2. “Multiple authentication methods and single sign-on (via the agent-forwarding)”


    how do you do SSO with agent-forwarding?



Leave a Reply

Your email address will not be published. Required fields are marked *

This site uses Akismet to reduce spam. Learn how your comment data is processed.