7 ms·

If I want to push to GitHub when I am in the office, I have to VPN out of the office connection because Port 22 is blocked. And they wonder why I prefer to wor

If I want to push to GitHub when I am in the office, I have to VPN out of the office connection because Port 22 is blocked. And they wonder why I prefer to work from home?

gsu2 4y ago
For anybody running into a similar problem: most git hosting services set up a subdomain that will allow SSH traffic over port 443, e.g. ssh.github.com, altssh.bitbucket.org, altssh.gitlab.com, etc.
ValCanBuild 4y ago
Oh god this is horrible! Yeah, I can't believe how stupidly locked down some of these networks are. I once had an employer said they needed a "whitelist" of websites we wanted to visit instead of a "blacklist" of ones we shouldn't. That was an interesting day...
- davewasthere 4y ago
  I had exactly this. We run a Saas and someone wrote an email saying that our server was down, and when we'd expect it to be up. Not having had a notification, I double checked from a couple of geographic locations that our application was indeed up and responding. After a bit of investigation, it turns out that they have to whitelist every unique address with their corporate IT. And had only whitelisted our primary client-app URL (talks to a couple of different API endpoints), hence the strange error message. It's been a long time since I've worked somewhere with whitelisting.
  - chasil 4y ago
    I actually deployed several "FireWall ToolKit" firewalls in the '90s for various organizations. I still maintain one on an internal QA network. It allows whitelists. https://www.fwtk.org/ https://www.fwtk.org/ https://avolio.com/fwtk-history/ https://avolio.com/fwtk-history/ https://www.ranum.com/security/computer_security/editorials/codetools/ https://www.ranum.com/security/computer_security/editorials/...
  - richbell 4y ago
    > We run a Saas and someone wrote an email saying that our server was down, and when we'd expect it to be up. Not having had a notification, I double checked from a couple of geographic locations that our application was indeed up and responding. A tale as old as time: https://www.youtube.com/watch?v=uRGljemfwUE https://www.youtube.com/watch?v=uRGljemfwUE
- shireboy 4y ago
  I’m dealing with this now. Company got hacked and so now are over the top locking down everything to the point it’s unusable. I told them the other day that the most secure thing they could do is just turn it all off.
Kim_Bruning 4y ago
My solution was to run an sshd on port 443. I currently no longer need to do so right this minute, but sometimes people do keep asking me why I still have that. --- Not sure if this still works on modern corporate networks. These days I tether to a mobile phone with unlimited internet; which is all-around easier to work with.
- iso1631 4y ago
  My wireguard UDP endpoints are available on a high port, 443 and 53. I've often have one of them blocked, very rare to have them all blocked.
- hackernudes 4y ago
  That worked for me for awhile but then the proxy started checking that all traffic was HTTP. Eventually I used ssh over websocket.
- aaronax 4y ago
  As an example, best practice for Palo Alto firewall setup is to create a rule that allows the "application" known as "SSL" and then use "application-default" as the setting for which ports to allow it on. This would inspect the traffic to determine that it is SSL (actually TLS in most cases I guess) and then allow it if on port 443. If you don't have other relevant allow rules, your sshd traffic would just be dropped, regardless of port. If the firewall administrator does things poorly, they will create an allow rule for port 443 and your sshd traffic on port 443 would be allowed (no inspection of traffic to determine if it is SSL or SSH). BTW this is inspection, not decryption. Two very different things. The business of developing algorithms to effectively detect various applications must be very interesting. You can see all the different "applications" here: https://applipedia.paloaltonetworks.com/ https://applipedia.paloaltonetworks.com/
xani_ 4y ago
You can just push using port 443 -> ᛯ ssh -T -p 443 git@ssh.github.com Warning: Permanently added '[ssh.github.com]:443' (ED25519) to the list of known hosts. Hi XANi! You've successfully authenticated, but GitHub does not provide shell access.
_fat_santa 4y ago
I worked for a place where they did wired stuff like this. Ended up that to install dependencies for a Node app, you had to: 1. Disconnect from VPN and run `npm install` until it failed 2. Connect to VPN "Profile 1" and run the command again until it fails 3. Connect to VPN "Profile 2" and run the command again until it fails. 4. Disconnect from VPN and run the command another time to finish installing all dependencies. 5. Reconnect to VPN to actually run the app.

If I want to push to GitHub when I am in the office, I have to VPN out of the office connection because Port 22 is blocked. And they wonder why I prefer to work from home?

gsu2 4y ago

For anybody running into a similar problem: most git hosting services set up a subdomain that will allow SSH traffic over port 443, e.g. ssh.github.com, altssh.bitbucket.org, altssh.gitlab.com, etc.

ValCanBuild 4y ago

Oh god this is horrible! Yeah, I can't believe how stupidly locked down some of these networks are. I once had an employer said they needed a "whitelist" of websites we wanted to visit instead of a "blacklist" of ones we shouldn't. That was an interesting day...

davewasthere 4y ago
I had exactly this. We run a Saas and someone wrote an email saying that our server was down, and when we'd expect it to be up. Not having had a notification, I double checked from a couple of geographic locations that our application was indeed up and responding. After a bit of investigation, it turns out that they have to whitelist every unique address with their corporate IT. And had only whitelisted our primary client-app URL (talks to a couple of different API endpoints), hence the strange error message. It's been a long time since I've worked somewhere with whitelisting.
- chasil 4y ago
  I actually deployed several "FireWall ToolKit" firewalls in the '90s for various organizations. I still maintain one on an internal QA network. It allows whitelists. https://www.fwtk.org/ https://www.fwtk.org/ https://avolio.com/fwtk-history/ https://avolio.com/fwtk-history/ https://www.ranum.com/security/computer_security/editorials/codetools/ https://www.ranum.com/security/computer_security/editorials/...
- richbell 4y ago
  > We run a Saas and someone wrote an email saying that our server was down, and when we'd expect it to be up. Not having had a notification, I double checked from a couple of geographic locations that our application was indeed up and responding. A tale as old as time: https://www.youtube.com/watch?v=uRGljemfwUE https://www.youtube.com/watch?v=uRGljemfwUE
shireboy 4y ago
I’m dealing with this now. Company got hacked and so now are over the top locking down everything to the point it’s unusable. I told them the other day that the most secure thing they could do is just turn it all off.

Kim_Bruning 4y ago

My solution was to run an sshd on port 443. I currently no longer need to do so right this minute, but sometimes people do keep asking me why I still have that. --- Not sure if this still works on modern corporate networks. These days I tether to a mobile phone with unlimited internet; which is all-around easier to work with.

iso1631 4y ago
My wireguard UDP endpoints are available on a high port, 443 and 53. I've often have one of them blocked, very rare to have them all blocked.
hackernudes 4y ago
That worked for me for awhile but then the proxy started checking that all traffic was HTTP. Eventually I used ssh over websocket.
aaronax 4y ago
As an example, best practice for Palo Alto firewall setup is to create a rule that allows the "application" known as "SSL" and then use "application-default" as the setting for which ports to allow it on. This would inspect the traffic to determine that it is SSL (actually TLS in most cases I guess) and then allow it if on port 443. If you don't have other relevant allow rules, your sshd traffic would just be dropped, regardless of port. If the firewall administrator does things poorly, they will create an allow rule for port 443 and your sshd traffic on port 443 would be allowed (no inspection of traffic to determine if it is SSL or SSH). BTW this is inspection, not decryption. Two very different things. The business of developing algorithms to effectively detect various applications must be very interesting. You can see all the different "applications" here: https://applipedia.paloaltonetworks.com/ https://applipedia.paloaltonetworks.com/

xani_ 4y ago

You can just push using port 443 -> ᛯ ssh -T -p 443 git@ssh.github.com Warning: Permanently added '[ssh.github.com]:443' (ED25519) to the list of known hosts. Hi XANi! You've successfully authenticated, but GitHub does not provide shell access.

_fat_santa 4y ago

I worked for a place where they did wired stuff like this. Ended up that to install dependencies for a Node app, you had to: 1. Disconnect from VPN and run `npm install` until it failed 2. Connect to VPN "Profile 1" and run the command again until it fails 3. Connect to VPN "Profile 2" and run the command again until it fails. 4. Disconnect from VPN and run the command another time to finish installing all dependencies. 5. Reconnect to VPN to actually run the app.