Regarding Console Environment
Setting the various Environment variables, like the other answers suggest, is the way to go. I would also define upper case counterparts of all variables since some applications only recognize one or the other. Moreover, I would define NO_PROXY for hosts you don't want to proxy, eg.:
export no_proxy="localhost,127.0.0.1,localaddress,.corporate.com"
Proxying SSH
This requires a bit more tweaking. There's a third party tool called 'connect' available here. Its homepage is here. It will allow you to proxy SSH connections over HTTPS and SOCKS proxies. However, it only supports basic authentication methods.
For this to work, you'll have to modify your ~/.ssh/config file to use 'connect' command as proxy command. Assuming your corporate SOCKS server is running at socks.corporate.com on port 1080, you can add ProxyCommand option in ~/.ssh/config, like this:
Host remote.outside.net
ProxyCommand connect -S socks.corporate.com %h %p
The variables %h and %p will be replaced on invoking proxy command with target hostname and port specified to SSH command.
If you don't want to add a seperate HOST entry for every single target host, you can also use wildcards:
## Outside of the firewall, use connect command with SOCKS conenction.
Host *
ProxyCommand connect -S socks.corporate.com %h %p
## Inside of the firewall, use connect command with direct connection.
Host *.socks.coporate.com
ProxyCommand connect %h %p
Similarly, if you want to use https proxy, use -H option instead of -S option in example above, like this:
## Outside of the firewall, with HTTP proxy
Host *
ProxyCommand connect -H proxy.corporate.com:8080 %h %p
## Inside of the firewall, direct
Host *.corporate.com
ProxyCommand connect %h %p
Since you're in a corporate network it maybe a good idea to make sure your IT department if fine with you proxying SSH. Maybe they even have a better solution than mine. Otherwise you might end up on the blacklist and no connectivity at all :)