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.
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
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 ..."
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.
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.
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.
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.
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.
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.
37 comments
[ 3.5 ms ] story [ 261 ms ] threadThe 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
intersecting sets.
https://news.ycombinator.com/item?id=37307708
https://github.com/zeek/zeek
It could be a 4-line bash alias, any SSH activity that doesn't go through your wrapper could be considered suspicious
The plebs can't be trusted to respect our wealth and superiority.
/s
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 ..."
Of course any concerns about the vulnerabilities in their closed source implementations are handwaved away.
I appreciate that SSH can be obsfucated via an SSL tunnel but the article didn't come at that angle.
The article itself even states: >with SSH everything goes dark right after the initial capabilities exchange.
So... What say about before the exchange?
So if that's your concern, perhaps address the communication, not the ssh tunnel.
Isn't this mitigated in newer TLS versions?
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.
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.
[1]: https://github.com/nnathan/monopiped
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.
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.