4 ms·

I wish the openssh folks would implement a UDP based "whole auth key or no talk at all" protocol. ie Single Packet Authorization Wrapping your ssh with wiregu

I wish the openssh folks would implement a UDP based "whole auth key or no talk at all" protocol. ie Single Packet Authorization Wrapping your ssh with wireguard (because wireguard doesn't respond without a full key) doesn't feel too good.

rwmj 2y ago
I've not used it, but this ssh wrapper was mentioned here a few days ago: https://github.com/mrash/fwknop https://github.com/mrash/fwknop
tptacek 2y ago
Why? What does that get you?
cedws 2y ago
I’ve been thinking that we need a new ‘WireGuard of SSH’ for a while. SSH is such a complex behemoth now. Before WireGuard came along VPNs were horrible to work with, the cryptography was bad and they were too configurable. Just do one thing and do it well - provide a way to establish an encrypted remote shell. Let others build on top of that if they need more. Vulnerabilities lurk in overly complex software with a thousand bells and whistles. By reducing the code paths you’re making software that is much easier to audit and fuzz.
- tptacek 2y ago
  I agree directionally, but the frankly stunning security track record of OpenSSH makes that a hard argument to really prosecute.
  - mmooss 2y ago
    I'm curious about what works and what doesn't: Many experts don't trust OpenBSD's security implementation (I don't want to raise the issue, just stating fact - many don't). Yet many do trust OpenSSH's security implementation, and OpenSSH is of course an OpenBSD project. What works in OpenSSH that doesn't work in OpenBSD? Maybe it's as simple as, though under the same umbrella OpenSSH uses a different team, methodology, etc.
    - tptacek 2y ago
      I don't think OpenSSH's affiliation with OpenBSD really means anything; it's an accident of history that the people most likely to want to build something like OpenBSD happened to have been involved with OpenBSD at the time. Just my take.
    - yourapostasy 2y ago
      > Many experts don't trust OpenBSD's security implementation... Does this distrust go to the extent where confronted with a public Internet-facing, stock OpenBSD with a TLS-secured SSH connection, and a GSA hardened RHEL 8 [1] with a similar SSH configuration, they’ll pick the RHEL instance? [1] https://github.com/GSA/ansible-os-rhel8 https://github.com/GSA/ansible-os-rhel8
      - lmm 2y ago
        Many experts will pick RHEL over OpenBSD yes. It's impossible to isolate a single reason; generally you want a server to do something. (I guess if you're talking about SSH only then maybe you want it as a bastion host? In my experience people will generally use the same OS as their other servers though; the risk of misconfiguring an unfamiliar operating system outweighs any security improvement from picking one or the other)
      - ruthmarx 2y ago
        RHEL has put a lot of work into their SELinux policy. Without a doubt it's more secure than OpenBSD. If both OSes had a remote root hole, on OpenBSD you would have carte blanche to do whatever, on the RHEL system you would be able to do very little.
    - maayank 2y ago
      I’m genuinely interested to hear criticism re: security in openBSD if any one has an interesting link or take
      - cedws 2y ago
        I have written poorly worded criticisms of the OpenBSD project on HN before. They boil down to this: from my observation, it looks like the approach to security in the OpenBSD project is adding more code to solve security issues when it should be the opposite. Code is a liability. You should write as little of it as possible to solve the problem at hand and not spare a single line that isn't needed. In this case the problem is getting a shell on a remote host. Why do you need so many configuration options to solve this single problem? The OP is a prime example of the opposite happening - it's adding code to prevent repeated authentication failures. Why would this be needed in the first place? If you have configured OpenSSH correctly (that is, using public key authentication instead of password auth, which should not even be an option), then repeated authentication failures should not be a problem. At worst, they take up some CPU time. Much of the code in OpenBSD and the wider OpenBSD projects also address memory safety issues which would not be issues in the first place if they just used a memory safe language. Yet they push ahead using C in the full knowledge that there are better options available. Java, Go, Python, Rust, I literally don't care, anything would be better than C. Developers should not need to spend hours carefully poring over each others patches to find critical mistakes when it comes to memory. They should not need to spend hours reading C development guidelines or rely on mailing list oracles. By eliminating memory errors as a class, mental capacity is freed up to identify logic errors.
- formerly_proven 2y ago
  SSH (v2) has always been a complex behemoth of a protocol.
- candiddevmike 2y ago
  I built a HTTP-based shell system on top of a configuration management tool. It uses public key cryptography via JWTs, and generates noise to obfuscate keystroke timing. Since it's all over HTTP, you don't really get any port knocking, and you can expose access using proxies and middleware. https://etcha.dev/docs/guides/shell-access https://etcha.dev/docs/guides/shell-access
gosub100 2y ago
Then it would be vulnerable to MITM.
- DaSHacka 2y ago
  How so?
  - gosub100 2y ago
    You fool a valid sender into thinking you're the recipient, he passes you his one and done key, which you use to login and takeover.
    - DaSHacka 2y ago
      You're only passing public keys with WireGuard, its asymmetric not symmetric encryption. It doesn't matter if an attacker gets your (or the server's) public key.
- deleted 2y ago
  [deleted]
10000truths 2y ago
Telnet over WireGuard?
- Vecr 2y ago
  You'd really have to think about that, I'd personally reject it just on defense in depth grounds. SSH over WireGuard is probably the correct solution.
blueflow 2y ago
That's not easy, if you do a ssh -vvv you will see that its a long forth and back of negotiations and information exchanges.
deleted 2y ago
[deleted]

rwmj 2y ago

I've not used it, but this ssh wrapper was mentioned here a few days ago: https://github.com/mrash/fwknop https://github.com/mrash/fwknop

tptacek 2y ago

Why? What does that get you?

cedws 2y ago

I’ve been thinking that we need a new ‘WireGuard of SSH’ for a while. SSH is such a complex behemoth now. Before WireGuard came along VPNs were horrible to work with, the cryptography was bad and they were too configurable. Just do one thing and do it well - provide a way to establish an encrypted remote shell. Let others build on top of that if they need more. Vulnerabilities lurk in overly complex software with a thousand bells and whistles. By reducing the code paths you’re making software that is much easier to audit and fuzz.

tptacek 2y ago
I agree directionally, but the frankly stunning security track record of OpenSSH makes that a hard argument to really prosecute.
- mmooss 2y ago
  I'm curious about what works and what doesn't: Many experts don't trust OpenBSD's security implementation (I don't want to raise the issue, just stating fact - many don't). Yet many do trust OpenSSH's security implementation, and OpenSSH is of course an OpenBSD project. What works in OpenSSH that doesn't work in OpenBSD? Maybe it's as simple as, though under the same umbrella OpenSSH uses a different team, methodology, etc.
  - tptacek 2y ago
    I don't think OpenSSH's affiliation with OpenBSD really means anything; it's an accident of history that the people most likely to want to build something like OpenBSD happened to have been involved with OpenBSD at the time. Just my take.
  - yourapostasy 2y ago
    > Many experts don't trust OpenBSD's security implementation... Does this distrust go to the extent where confronted with a public Internet-facing, stock OpenBSD with a TLS-secured SSH connection, and a GSA hardened RHEL 8 [1] with a similar SSH configuration, they’ll pick the RHEL instance? [1] https://github.com/GSA/ansible-os-rhel8 https://github.com/GSA/ansible-os-rhel8
    - lmm 2y ago
      Many experts will pick RHEL over OpenBSD yes. It's impossible to isolate a single reason; generally you want a server to do something. (I guess if you're talking about SSH only then maybe you want it as a bastion host? In my experience people will generally use the same OS as their other servers though; the risk of misconfiguring an unfamiliar operating system outweighs any security improvement from picking one or the other)
    - ruthmarx 2y ago
      RHEL has put a lot of work into their SELinux policy. Without a doubt it's more secure than OpenBSD. If both OSes had a remote root hole, on OpenBSD you would have carte blanche to do whatever, on the RHEL system you would be able to do very little.
  - maayank 2y ago
    I’m genuinely interested to hear criticism re: security in openBSD if any one has an interesting link or take
    - cedws 2y ago
      I have written poorly worded criticisms of the OpenBSD project on HN before. They boil down to this: from my observation, it looks like the approach to security in the OpenBSD project is adding more code to solve security issues when it should be the opposite. Code is a liability. You should write as little of it as possible to solve the problem at hand and not spare a single line that isn't needed. In this case the problem is getting a shell on a remote host. Why do you need so many configuration options to solve this single problem? The OP is a prime example of the opposite happening - it's adding code to prevent repeated authentication failures. Why would this be needed in the first place? If you have configured OpenSSH correctly (that is, using public key authentication instead of password auth, which should not even be an option), then repeated authentication failures should not be a problem. At worst, they take up some CPU time. Much of the code in OpenBSD and the wider OpenBSD projects also address memory safety issues which would not be issues in the first place if they just used a memory safe language. Yet they push ahead using C in the full knowledge that there are better options available. Java, Go, Python, Rust, I literally don't care, anything would be better than C. Developers should not need to spend hours carefully poring over each others patches to find critical mistakes when it comes to memory. They should not need to spend hours reading C development guidelines or rely on mailing list oracles. By eliminating memory errors as a class, mental capacity is freed up to identify logic errors.
formerly_proven 2y ago
SSH (v2) has always been a complex behemoth of a protocol.
candiddevmike 2y ago
I built a HTTP-based shell system on top of a configuration management tool. It uses public key cryptography via JWTs, and generates noise to obfuscate keystroke timing. Since it's all over HTTP, you don't really get any port knocking, and you can expose access using proxies and middleware. https://etcha.dev/docs/guides/shell-access https://etcha.dev/docs/guides/shell-access

gosub100 2y ago

Then it would be vulnerable to MITM.

DaSHacka 2y ago
How so?
- gosub100 2y ago
  You fool a valid sender into thinking you're the recipient, he passes you his one and done key, which you use to login and takeover.
  - DaSHacka 2y ago
    You're only passing public keys with WireGuard, its asymmetric not symmetric encryption. It doesn't matter if an attacker gets your (or the server's) public key.
deleted 2y ago
[deleted]

10000truths 2y ago

Telnet over WireGuard?

Vecr 2y ago
You'd really have to think about that, I'd personally reject it just on defense in depth grounds. SSH over WireGuard is probably the correct solution.

blueflow 2y ago

That's not easy, if you do a ssh -vvv you will see that its a long forth and back of negotiations and information exchanges.

deleted 2y ago

[deleted]