I'm a programmer, and I have worked for a few clients whose networks block outgoing connections on port 22. Considering that programmers often need to use port 22 for ssh, this seems like a counterproductive procedure. At best, it forces the programmers to bill the company for 3G Internet. At worst, it means they can't do their jobs effectively.

Given the difficulties this creates, could an experienced sysadmin please explain the desired benefit to what seems like a lose-lose action?

  • 1
    Blocking ports is only half the battle. To complete the cycle, you have to make sure the services you're trying to protect aren't running on non-standard ports.
    – aharden
    Jun 14, 2009 at 20:16
  • 1
    The question should really be "Why block port 22 outbound?" as there are a million good reasons as to why you'd want to run your ssh service on a non-standard port. Outbound... not so much. I put a +1 on Robert Moir's answer as he did a pretty good job explaining it.
    – KPWINC
    Jun 14, 2009 at 21:11
  • 1
    @KPWINC, added the clarification to the title. Thanks!
    – runako
    Jun 14, 2009 at 22:00
  • 4
    Think of port 22 as a pandora's box of sort. Network admins cannot see what is in the traffic and worst yet, ssh can be used bypass network security compromising the integrity of the network.
    – biosFF
    Jun 15, 2009 at 8:07
  • 1
    @biosFF: Port 443.
    – Hello71
    Aug 23, 2011 at 17:39

16 Answers 16


I don't see that anyone has spelled out the specific risk with SSH port forwarding in detail.

If you are inside a firewall and have outbound SSH access to a machine on the public internet, you can SSH to that public system and in the process create a tunnel so that people on the public internet can ssh to a system inside your network, completely bypassing the firewall.

If fred is your desktop and barney is an important server at your company and wilma is public, running (on fred):

ssh -R*:9000:barney:22 wilma

and logging in will let an attacker ssh to port 9000 on wilma and talk to barney's SSH daemon.

Your firewall never sees it as an incoming connection because the data is being passed through a connection that was originally established in the outgoing direction.

It's annoying, but a completely legitimate network security policy.

  • 8
    +1 for giving a good technical reason. (However, this could only be done by a malevolent intern, who could also use other ports than TCP 22 on the remote host. With which we are back to some block all policy)
    – DerMike
    Jan 5, 2011 at 12:52
  • 11
    With a custom tailored protocol and some clever proxy programming, this could be done through HTTPS--albeit slower. As long as you allow outbound encrypted traffic, you're vulnerable to this sort of "attack". Jul 7, 2011 at 18:52
  • 3
    This is a good response JamesF, but not a security issue worth thinking about because it assumes an extremely rare scenario and requires exploitation of SSH servers/clients. The malicious user would have to first exploit the SSH server (on your desktop) and figure out a way to then exploit your SSH client (on your business host). Since you can't use port 22 to access or talk to the business-firewalled host (which only has outgoing port 22). If your security standard is that high, your business-host shouldn't even be on the internet in any situation. May 15, 2013 at 15:56
  • 2
    You can tunnel traffic over DNS (e.g. with iodine) if HTTPS and SSH are unavailable. But it's very slow. Oct 11, 2016 at 15:35
  • 2
    One could still work around this. If port TCP 443 (HTTPS) and UDP 53 (DNS) are allowed, you can have SSH on port 443 on some external server (can't be blocked) and, say, OpenVPN on port 53 on said server. Oct 30, 2019 at 15:41

If they're blocking a mishmash of ports, letting some stuff through and blocking some other stuff at random (I love Paul Tomblin's sad tale of the people who block SSH and allowed Telnet) then they either have a very strange edge case for how they go about securing their network perimeter, or their security polices are, from the outside at least, apparently poorly thought out. You can't make sense of situations like that so just charge them the going rate for people who are a pain and carry on with your day.

If they're blocking ALL ports unless there's a specific business case for allowing traffic through that port, at which point its carefully managed then they're doing it because they're competent at their jobs.

When you're trying to write a secure application do you make it easy for other processes to read and write information to it as they please or do you have a few carefully documented APIs that you expect people to call and which you sanitise carefully?

Risk management - if you feel that traffic to or from your network going onto the Internet is a risk, then you look to minimise the amount of ways traffic can reach the Internet, both in terms of number of routes and number of methods. You can then monitor and filter these chosen "blessed" gateways and ports to try and ensure that the traffic traveling over them is what you expect.

This is a "default deny" firewall policy and is usually regarded as a good idea, with a couple of caveats which I'll come to. What it means is that everything is blocked unless there is a specific reason to unblock it, and the benefits of the reason outweigh the risks.

Edit: I should clarify, I'm not just talking about the risks of one protocol being allowed and another blocked, I'm talking about the potential risks to the business of information being allowed to flow into or out of the network in an uncontrolled way.

Now for the caveats, and possibly a plan to free things up:

It can be annoying when you're blocked out of something, which is the position you find yourself in with some of your clients. All too often, the people in charge of the firewall think its their job to say "No", instead of "Here are the risks, now what are the benefits, lets see what we can do".

If you speak to whoever manages network security for your clients they may be amenable to setting up something for you. If you can identify a few specific systems at their end you need access to, and/or guarantee you'll only connect from a specific IP address they may be a lot happier to create a firewall exception for SSH connections for those specific conditions than they would be to just open up connections to the whole internet. Or they may have a VPN facility you can use to tunnel through the firewall.

  • 3
    +1 for If they're blocking ALL ports unless there's a specific business case for allowing traffic through that port, at which point its carefully managed then they're doing it because they're competent at their jobs.
    – cop1152
    Jun 15, 2009 at 3:42
  • -1 because ssh can't be monitored by the security people but Telnet can be. My point is that while there are foolish network security policies, characterizing the policy as "random" and "whackjob" without an understanding of the actual business needs is also short sited.
    – pcapademic
    Jun 15, 2009 at 5:34
  • 2
    Well you're entitled to your opinion of course Eric, and I'll happily change those words if you feel they are pejorative, but I'm fairly confident that such a policy would be either poorly thought out or a very unusual edge case.
    – Rob Moir
    Jun 15, 2009 at 12:52

A certain large company in Rochester NY that used to make a lot of film blocked outgoing ssh when I worked there, but allowed telnet! When I asked about it, they said that ssh was a security hole.

In other words, companies sometimes make stupid decisions, and then make up baloney excuses about security rather than admit their mistakes.

  • 6
    TELNET is the security hole. It should be banned (this is just for people to make better stupid decisions in future).
    – nik
    Jun 14, 2009 at 17:42
  • 3
    Let me elaborate here, what is a security hole is subjective to the surface being secured. If you are a web site owner, trying to connect to your server, TELNET is a hole. If you are a financial company employee trying to connect outside to your home server (over lines being monitored by your employer), SSH is the security hole for your employers!
    – nik
    Jun 14, 2009 at 17:46
  • 2
    Considering how easy it is to spoof telnet in both directions, I'd say telnet is a security hole even for the company that allows it out-going. But a company that allows it but doesn't allow ssh is not going to be making intelligent security decisions in any case. Jun 14, 2009 at 17:51
  • 3
    Telnet is the gift that just keeps giving. It was ok 20 years ago but now I really wish it would stop.
    – Rob Moir
    Jun 14, 2009 at 18:06
  • 2
    It all depends on your POV. They probably had people who needed to access some legacy process via Telnet, whose us is easily auditable. OTOH, you have no idea what is going on with SSH, people could establish tunnels to foreign networks and do all sorts of dumb things. Telnet shouldn't be used these days, but anyone allowing outgoing SSH needs to seek a new career. Jun 15, 2009 at 0:16

I can understand blocking inbound SSH communication if the company is disallowing external logins. But, this is the first time I hear of an outbound SSH block.

What is important to note is that such firewalling will probably limit only the casual SSH user. If someone really wants to SSH outside (which will typically be to a server/machine they have significant access to, outside the enterprise network) they can easily run the SSH server on a port other than 22 (say, port 80). The block will be bypassed easily.

There are also several public domain tools that will let you exit the enterprise over HTTP (port 80 or HTTPS port 443) and provide proxies to let you connect to port 22 outside.

Edit: Ok, wait a second, i have an idea why this could be a policy.

Sometimes, people use SSH tunnels to bypass basic outbound firewalls for protocols like IM and Bittorrent (for example). This //might// have triggered such a policy. However, I still feel that most of these tunnel tools would be able to work on ports other than 22.

The only way such outbound tunnels can be blocked is by detecting SSH communication on the fly and (dynamically) blocking these TCP connections.

  • 3
    Port 443 is better, because it is already assumed to be encrypted, so proxies won't get upset on strange data. You can easily set up an ssh server listening on port 443, and from there you can go anywhere.
    – bandi
    Jun 14, 2009 at 18:08
  • 1
    One place I worked, one of my co-workers used a program that tunneled all network traffic over an ssh tunnel through our web proxy to port 80 on his home computer, and from there out to the internet. He could use any protocol he wanted, but it looked like it was coming from his house instead of the company. Fortunately he knew how clueless the network administrators were so he wasn't risking getting caught. Jun 14, 2009 at 18:44
  • 1
    Of course, if you do get caught having gone through one of these elaborate dances to circumnavigate the firewall, you can't really plead innocence and ignorance. Bit hard to do all of that and say "sorry boss, it 'just worked' so I didn't realise I was doing anything wrong."
    – Rob Moir
    Jun 14, 2009 at 19:22

It's probably a regulatory/compliance issue. Your employer wants to be able to read/archive all communication. This is very often a requirement in industries such as banking.

  • Doesn't that imply that they have to block HTTPS too?
    – runako
    Jun 15, 2009 at 1:29
  • 3
    No, they enable SSL inspection. This process decrypts HTTPS, then reencrypts in/outbound packets by injecting a trusted cert in all workstations by group policy. This way, they can filter/scan the same as with HTTP. The banking industry is one of the most draconian environments for locking down networks.
    – spoulson
    Jun 15, 2009 at 13:04

Because SSH can be used as a VPN. It's encrypted so network admins have literally no idea what's leaving their network (dump of the customer database, etc.). I just covered this stuff in my monthly column "Secret Tunnels". The cost of some 3G internet is a heck of a lot less than having to worry about encrypted protocols channeling your data out of the network. Plus if you default block outgoing port 22 and traffic inspect you can easily find SSH on non-standard ports and thus find people violating security policy.

  • Thanks for the insight. It sounds like you wouldn't consider 3G a secret tunnel. Could you shed some light onto why it makes more sense to have people totally off-network when communicating to the Internet? It seems like you'd prefer rogue devices even less than an open 22 for outbound.
    – runako
    Jun 15, 2009 at 1:36
  • 1
    "...you can easily find SSH on non-standard ports..." Really? Like looking for SSL/TLS negotiation on ports other than 443? Very curious.
    – Dscoduc
    Jun 23, 2009 at 17:45
  • Yup you can detect ssh traffic, Google: snort/ssh/detection/content/rules, dunno about other IDS's but if Snort can do it they'd have to be pretty busted to not do it as well.
    – Kurt
    Jun 25, 2009 at 6:10

There are two primary reasons to block outbound port 22, in my opinion.

First, as people have mentioned, SSH port forwarding can be used as a proxy or bypass around other ports and services to avoid IT policy stating such traffic isn't allowed.

Second, a lot of malware/botnets will use port 22 because it is often seen as "secure" and therefore allowed. They can then launch processes out that port, and infected computers might also launch SSH brute force attacks.


More often than not it is more a case of blocking all outgoing connections unless needed, and until you tried no one had requested port 22 to be available for outgoing connections (just 80, 433, and so on). If this is the case then the solution may be as simple as contacting IS/IT and telling them why you need an exception adding so your station can make outgoing SSH connections to specific hosts or in general.

Sometimes it is the concern that people might use the facility to use SSH as a way to setup proxies (via port forwarding over the link) to circumvent other controls. This can be a very important factor in some regulated industries (i.e. banks) where all communication needs to be monitored/logged for legal reasons (discouraging insider trading, detecting/blocking transfer of corporate or personal data, and so forth) or companies where there is a great fear of internal leaks giving away, accidentally or otherwise, trade secrets. In these cases using your 3G link (or other techniques such as trying to tunnel SSH through HTTP) to circumvent the restrictions may be a breach of your contract and therefore a sacking offence (or, probably worse, a legal offence) so be careful to get your action agreed before you attempt it.

Another reason could be to reduce the outgoing footprint (to internal services accessible to hosts within the company firewalls and to the world in general) should something untoward manage to get itself installed on a company ran machine. If no SSH connections are possible on port 22 many simpler hacks that try use brute-force SSH logins as one of their propagation routes will be blocked. In this case you may again just be able to ask for an exception to be added so that your machine can make SSH connections, if these connections can be justified to the people in control of the firewall(s).

  • Yes, it is quite likely that all outbound services not required to be used yet may have been blocked (by default).
    – nik
    Jun 14, 2009 at 17:51
  • But, blocking tcp/22 is not going to prevent secure outbound communications (which can be made on any port as long as the user has a listener outside, which is not a difficult thing these days).
    – nik
    Jun 14, 2009 at 17:51
  • If the internal network has use for SSH communication, blocking it will not work and if there is no SSH communication required, typically there will be no vulnerable SSH listening machines inside the network either. And, typical worm propagation does not try to brute force SSH (if you are worried about that look at en.wikipedia.org/wiki/SSHBlock) it is more likely going to try tcp/445 with your windows machines.
    – nik
    Jun 14, 2009 at 17:55

Your clients are probably in possession of non-trivial data that they would like to retain. Outbound SSH is a really bad thing to have open for an entire network. It's pretty trivial to bypass proxys, leak sensitive data, and be generally obnoxious.

IMO, anything passing through the network/internet perimeter should be understood and controllable. If a group of devs need access to servers at a hosting provider via ssh, that's fine -- but it also needs to be documented. In general at the places that I have worked, we establish dedicated site-to-site VPN connections to locations outside of our network, (essentially extending our internal network) and avoid client protocols like SSH over the internet.

  • Thanks for the answer. How do you handle dedicated VPNs to sites outside your control (e.g. EC2, Web hosts, etc.)? Are these vendors typically willing to just do this custom setup for you, or do you usually have to make some large minimum commitment in terms of business to get them to do so?
    – runako
    Jun 15, 2009 at 1:33
  • 2
    Also, do you worry that you force people to use off-network 3G cards to get their work done? In my experience, locked-down networks inevitably lead to lots of 3G cards and other hidden circumvention, because folks can't get their jobs done in the alloted time if they have to wait for IT to approve their usage, if anyone even knows who to call to get an exception. (One egregious case included a mailserver that wouldn't accept incoming attachments from the Internet. Yikes!) I'd be curious how you manage this balance.
    – runako
    Jun 15, 2009 at 1:40
  • 1
    Add in the comment about port forwarding over ssh, and I think this is the correct answer to the question. ssh may be a good protocol to allow via a proxy server. The admins can monitor what is going on, can block port forwarding, and people can use it for remote shell and remote copy services.
    – pcapademic
    Jun 15, 2009 at 5:39
  • We're large enough that probably 90% of our services require no outbound administration to run. Typically when we do, we make a dedicated VPN tunnel a requirement in an RFP, which tends to eliminate vendors that won't or can't provide it. Because of that, I believe that we have a minimal number of people using 3G and similar workarounds. Jun 15, 2009 at 12:33
  • Also, you can't let the security people dictate access. You let the application support and networking people work out an acceptable solution, subject to security review. Work out that solution early in the process, not the morning you need to go into production. That keeps you away from the DMV-style delays in getting requests though. Jun 15, 2009 at 12:35

I know a couple of people who abuse the capabilities of SSH to install a SOCKS proxy thru SSH, thereby circumventing some site restrictions.

Or even some simple port forwarding (ssh -L ....), if the port is indeed blocked because of site restrictions I'd go to:

  • the local admin and
  • your project manager

get them to a table and let them elaborate on the reason why this is blocked. Of course you need to have good reasons why you need access to an external SSH port for developing an internal product (internal being: Why do you need access to boxA.example.com when you work for a company snakeoil.invalid)

But I have yet to see a company blocking outgoing SSH :)

  • I've seen one company that blocks outgoing SSH. They also blocked nearly everything else and for example virus checked all HTTP transfers using a proxy. The company was a central securities depository. Jun 14, 2009 at 18:09
  • I work for a company like this. Luckily, SSH can be tunneled over https. Of course, they only allow https to port 443... sslh to the rescue!
    – Mikeage
    Jun 14, 2009 at 18:55
  • proxytunnel FTW :) Jun 14, 2009 at 21:24

The obvious answers have all been stated. It's an encrypted protocol that can be used to circumvent policy through the creation of tunnels (this is a great way to get past the corporate web filters) as well as the threat posed by unauthorized communications channels (reverse proxy).

It's true, telnet should be destroyed in any modern network. But, I can see allowing telnet out of the network while banning ssh. Telnet is less capable than ssh and I can always monitor the stream, in real-time, through my sniffers. If I don't have any telnet devices in my core network, and some user wants to telnet out, what do I care. I can see it, and verify that it's not a threat.

Of course, all of this depends on the idea that the default policy is to block all egress and only allow specific protocols. Bonus points if you're proxying them before the hit the edge.


It's not a case of specifically blocking port 22 because admins have a thing against SSH, more a case of only opening the ports that they know they need open. If your admin hasn't been told that SSH is needed open, your admin will block it, by the same principle that applies to disabling unused services on a server.


Clearly, an outbound TCP/22 block is easy to circumvent unless the network administrators have taken serious, serious efforts to block SSH traffic in specific. What's more, the asset administrators need to be on the ball enough to run asset inventorying sufficient to catch 3G modems, and suspicious IP addresses on 2nd NICs. We have ClearWire service in our area, so we even have WiMax as an end-run option around our network security.

We're not an institution that's majorly concerned with information leakage. But if we were, we'd need to combine a draconian network security policy with a draconian asset policy, with auditing. To the best of my knowledge, I don't think an off-the-shelf security package exists that'll turn off the network jack of an asset that inventories with an external network connection of some kind. That may be comming.

In the absence of such a package, the asset-inventory process is one of the best ways to catch an end-run network connection like 3G or WiMax.

And finally, blind blocking of TCP/22 will only block the least wiley of end-users intent on violating the AUP for their work network.

  • You can customize reports with something like SCCM to get that information. Where I work, using a personal laptop or WAN card to bypass network security is subject to disciplinary action. Jun 15, 2009 at 23:42

I've seen 22 blocked when they discovered that folks were directing http traffic through 22. It was a show stopper for those of us who needed it but the org stood their ground.


Most larger organizations will be blocking everything and only allowing HTTP/HTTPS access via a proxy server.

I'd be very surprised to hear of any corporations allowing direct external connections from desktops or servers unless there was a specific need.


Nothing stops you from running your remote sshd on port 80. Both ssh and sshd have a -p option to set the port.

Of course, if your admins are smart they should watch for ssh traffic, not just port 22 traffic. So, it sounds like you have a policy problem, not a tech problem.

As others pointed out though, encrypted protocols can cause heartburn in the folks who have to worry about assorted compliance issues.

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .