4 ms·
I must admit I didn't know the big domains disabled ssh. Naive/beginner's question: how do programmers work remotely at these companies (if it's allowed at all)
by ez77 16y ago
I must admit I didn't know the big domains disabled ssh. Naive/beginner's question: how do programmers work remotely at these companies (if it's allowed at all)? Do they ssh into other (safe) servers, from which a safe transfer is eventually made into the production servers?
- whakojacko 16y agoYou could set it up by allowing sshing to a server on a subdomain something like ssh.xyz.com or vpn.xyz.com and from there can ssh to production servers, which are set up to only allow ssh internally.
- Firehed 16y agoIt's a matter of setting up VPNs and IP-restricting where you can SSH in from. You can also set up port knocking and other SSH-related security measures. It depends how much convenience you're willing to trade for security.
- nwmcsween 16y agoPracticality trumps everything, after 10+ years of using ssh and trying port knocking and everything else none of it works when you're 4000km away in another country with only a handheld to access the servers.
- poet 16y agoI think it should probably company policy at a financial institution not to allow someone in a different control on a handheld device to access the servers.
- nwmcsween 16y agoI use layered security (in the sense of servers) with a password lifetime of 10 days. I deal with servers daily and the issue of compromise has been twice in on firewall containers/servers which was fine as the systems in place found it, found the issue with the net facing software and I fixed it. Practicality doesn't mean no security.
- count 16y agoIf you're using SSH, you should be using keys, and not passwords.
- modoc 16y agoGenerally you VPN in (using two-factor auth for PCI compliance) to a private network and can SSH in from there. Public facing SSH is generally a bad idea. Also it didn't seem like they had any firewall rules preventing brute forcing.