mmm, in a larger organization not really, proper subsets of marcomm, marketing communications. advertising people are called "creatives" where PR people are much more devious.
It's already pretty easy to use SSH over TLS using stunnel or any other thing that can do TLS to TCP proxies (socat, haproxy).
On some external system you just setup stunnel/socat/haproxy to listen on port 443 with TLS and proxy to TCP port 22, then just use openssh with openssl s_client as the proxy command.
Although not the same as what you desire (which I fully agree with) - I implemented a encrypted TCP program tunneling app which tunnels over HTTP(S) websockets [1]. This should frustrate middleboxes, but would rather it be as native as HTTP(S) itself.
If you can communicate from inside to the outside in any way, then it is possible to build a tunnel. Even if the communication goes through written letters.
So if that's your concern, perhaps address the communication, not the ssh tunnel.
Forgive me, my grok ability is low right now. I read the section about detecting TTY traffic, and in my mind, TTY traffic would be an example of a legit normal connection. Engineer accessing the system, etc.
Why not just outright ban the use of normal SSH and enforce all legitimate SSH activity to go through a wrapper program that reports to a monitoring service?
It could be a 4-line bash alias, any SSH activity that doesn't go through your wrapper could be considered suspicious
That's basically the end goal of most SSL and security enterprise product pushers: a crappier, less usable un-automatable replacement of SSH. (Example: teleport).
Of course any concerns about the vulnerabilities in their closed source implementations are handwaved away.
You're aware that (Open)SSH can have its behavior, including port forwards, modified at runtime after launch?
See e.g. https://linux.die.net/man/1/ssh section "Escape Characters" and "~C' Open command line. Currently this allows the addition of port forwardings ..."
Oh boy. The things the security people do to justify their existence.
The future may be your actual traffic through ssh tunneled through https with esni to a server behind Cloudflare. Unless you want pseudo security tools to mess with your traffic.
And the password is limited to eight characters maximum and it must have uppercase, lowercase and punctuation in order to limit the amount of rainbow you have to calculate.
The password update app will news SSL protocols and cryptography that are vastly out of date.
There will be no synchronization of passwords across various systems used in the company so you will have to memorize multiple passwords which means writing them down.
It's a separate addition. Chrome has already started their gradual rollout of ECH (previously known as ESNI). Though I haven't seen nice server-side implementations/automation.
The Great Firewall certainly can detect and block SSH too, but there are ways around that as discussed at https://news.ycombinator.com/item?id=36531485