5 ms·

Why not? Your password manager or passkeys do the same thing. Heck, just true the public key as the authentication header. Or use authentication certificates.

Why not? Your password manager or passkeys do the same thing. Heck, just true the public key as the authentication header. Or use authentication certificates. If ssh is such a big problem, use something else

rwteueru 2y ago
[flagged]
- arccy 2y ago
  credential helpers: like the github cli: https://cli.github.com/manual/gh_auth_setup-git https://cli.github.com/manual/gh_auth_setup-git or git-credential-manager: https://github.com/git-ecosystem/git-credential-manager https://github.com/git-ecosystem/git-credential-manager
  - declan_roberts 2y ago
    Sweet a new thing vulnerable to supply chain attacks to fix things vulnerable to supply chain attacks.
Joel_Mckay 2y ago
The key difference is https certificates often require signing authority integrity, and leak-free SSL libraries. Traditionally both facets of the 3rd party trust model have had CVE over the years. SSL protocol misconfiguration is also very common, and connections can be downgraded by adversaries into a vulnerable version of the protocol. It could be argued ssh is a weaker Trust on first use model, but in most cases the keys will rarely change for the short service life of the server instance... and the server may be setup from a local physical terminal, and keys communicated out-of-band to remote users. At some point one has to admit if someone really wants in they will physically pull the drive in the data center. However, people using web vulnerability scanners on your systems are less of a nuisance. Best regards =3
- fc417fc802 2y ago
  > It could be argued ssh is a weaker Trust on first use model That is but an optional aspect of the configuration (albeit by far the most common).
- crote 2y ago
  > The key difference is https certificates often require signing authority integrity Couldn't you use your "traditional" SSH keys to generate an ephemeral self-signed client certificate which shares the same keypair as your SSH key? That would at least solve the CA issue for the client-to-server authentication.
  - Joel_Mckay 2y ago
    It is a complex issue, and while public key encrypted exchanges could bootstrap a remote secure session (gpg/pgp etc.) to re-key the ssh server... there still is no guarantee someone isn't keeping a copy of that ssh session with the key-pair before you logged in as root. One should not completely trust TOFU over remote sessions, but it is the most practical solution. This is the inconvenient secret of cloud technology, and why the hosting company web panels often include abstracted firewall/vpn settings or proprietary key management (or the same authoritative problem manifests.) Good luck, =3
TacticalCoder 2y ago
> If ssh is such a big problem, use something else It's not a problem. You can use SSH today (and since years already now) with Yubikey and the likes. I'm using Git over SSH with Yubikeys and it works. Use Git over SSH, use a Yubikey (or whatever suits you), set the login shell to git-shell.
- johnisgood 2y ago
  Yubikey does look interesting, I thought of getting one. Sorry for this stupid question, but since if you use it with SSH, does that mean that somehow I may use my existing id_ed25519 file with Yubikey or does it need to generate a new one?
  - microtonal 2y ago
    You need to generate a new one on key (it’s not actually generated and already on the key, but that’s a technical detail). The idea is that the private key cannot be leaked since it never leaves the key.
    - johnisgood 2y ago
      Is there no way to use my existing one with either version / model? :(
      - nine_k 2y ago
        No. The whole point of hardware keys is that the private key bytes are securely locked inside the key, with no way out (cannot steal) and no way in (cannot forge / tamper with). Reuse of an existing key for any reason after enrollment is not a good idea. A reluctance to just enroll another key may mean trouble with key rotation and revocation, and thus problematic security procedures. Key rotation should be fast, painless, and regular.
        johnisgood 2y ago
        I have two more questions. 1. Does it ever expire? 2. What would you do exactly if you were to lose the hardware key? Same thing as if you lost your id_ed25519 file? > Key rotation should be fast, painless, and regular. I agree. Right now I keep changing the expiry date of my GPG keys (once in a good while).

rwteueru 2y ago

[flagged]

arccy 2y ago
credential helpers: like the github cli: https://cli.github.com/manual/gh_auth_setup-git https://cli.github.com/manual/gh_auth_setup-git or git-credential-manager: https://github.com/git-ecosystem/git-credential-manager https://github.com/git-ecosystem/git-credential-manager
- declan_roberts 2y ago
  Sweet a new thing vulnerable to supply chain attacks to fix things vulnerable to supply chain attacks.

Joel_Mckay 2y ago

The key difference is https certificates often require signing authority integrity, and leak-free SSL libraries. Traditionally both facets of the 3rd party trust model have had CVE over the years. SSL protocol misconfiguration is also very common, and connections can be downgraded by adversaries into a vulnerable version of the protocol. It could be argued ssh is a weaker Trust on first use model, but in most cases the keys will rarely change for the short service life of the server instance... and the server may be setup from a local physical terminal, and keys communicated out-of-band to remote users. At some point one has to admit if someone really wants in they will physically pull the drive in the data center. However, people using web vulnerability scanners on your systems are less of a nuisance. Best regards =3

fc417fc802 2y ago
> It could be argued ssh is a weaker Trust on first use model That is but an optional aspect of the configuration (albeit by far the most common).
crote 2y ago
> The key difference is https certificates often require signing authority integrity Couldn't you use your "traditional" SSH keys to generate an ephemeral self-signed client certificate which shares the same keypair as your SSH key? That would at least solve the CA issue for the client-to-server authentication.
- Joel_Mckay 2y ago
  It is a complex issue, and while public key encrypted exchanges could bootstrap a remote secure session (gpg/pgp etc.) to re-key the ssh server... there still is no guarantee someone isn't keeping a copy of that ssh session with the key-pair before you logged in as root. One should not completely trust TOFU over remote sessions, but it is the most practical solution. This is the inconvenient secret of cloud technology, and why the hosting company web panels often include abstracted firewall/vpn settings or proprietary key management (or the same authoritative problem manifests.) Good luck, =3

TacticalCoder 2y ago

> If ssh is such a big problem, use something else It's not a problem. You can use SSH today (and since years already now) with Yubikey and the likes. I'm using Git over SSH with Yubikeys and it works. Use Git over SSH, use a Yubikey (or whatever suits you), set the login shell to git-shell.

johnisgood 2y ago
Yubikey does look interesting, I thought of getting one. Sorry for this stupid question, but since if you use it with SSH, does that mean that somehow I may use my existing id_ed25519 file with Yubikey or does it need to generate a new one?
- microtonal 2y ago
  You need to generate a new one on key (it’s not actually generated and already on the key, but that’s a technical detail). The idea is that the private key cannot be leaked since it never leaves the key.
  - johnisgood 2y ago
    Is there no way to use my existing one with either version / model? :(
    - nine_k 2y ago
      No. The whole point of hardware keys is that the private key bytes are securely locked inside the key, with no way out (cannot steal) and no way in (cannot forge / tamper with). Reuse of an existing key for any reason after enrollment is not a good idea. A reluctance to just enroll another key may mean trouble with key rotation and revocation, and thus problematic security procedures. Key rotation should be fast, painless, and regular.
      - johnisgood 2y ago
        I have two more questions. 1. Does it ever expire? 2. What would you do exactly if you were to lose the hardware key? Same thing as if you lost your id_ed25519 file? > Key rotation should be fast, painless, and regular. I agree. Right now I keep changing the expiry date of my GPG keys (once in a good while).