Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

SSH certificates: the better SSH experience

jpmens.net

Post reply on HN
Print view View original

121–130 of 137 posts

Re: SSH certificates: the better SSH experience

#121

Post by gnufx »

tptacek wrote: post #93
gnufx wrote: post #92

Earlier quoted context omitted.

I don't want to have to get a special purpose credential when I have a TGT which can work generally, and is at least required for secure remote filesystem access. You have to manage extra infrastructure for certificates and, as a user, have the friction of firing up a JavaScript-enabled web browser via an additional tool, assuming "real IdP" means using OIDC. Unfortunately that flow is actually needed for remote syst…

Every serious shop of any real size is already managing an OIDC IdP (you need one for whatever SAAS apps your team is using along with any internal web applications you're using). Why not just link it to something that can issue short-lived SSH certificates? That's also the cleanest way to get strong multifactor auth for SSH (certificates issued only through an OIDC progress minted with MFA requirements). Setting up…

I'm happy for anyone who doesn't have MS Windows/Active Directory -- so Kerberos -- in their organization, but I'd need (Free)IPA or similar for user/access management anyway. Certificates are an extra layer of SSH-specific complexity, which concerns me for security even if it doesn't involve some third party. MFA is needed once a day, say, for SSO to all Kerberized services. [As I understand it, "managing an OIDC IdP" includes shipping the contents of Active Directory to Entra, heaven help us.]

> Setting up Kerberos in 2026 feels somewhat close to malpractice to me.

Microsoft (if that means anything, but they've done good work) and Red Hat obviously disagree, along with decades' experience. It is malpractice not to secure NFS mounts (and other network filesystems with sensitive data), and that means Kerberos.

Re: SSH certificates: the better SSH experience

#122

Post by anyfoo »

TZubiri wrote: post #51
anyfoo wrote: post #22

Earlier quoted context omitted.

A big problem I have with ssh carts is that they are not universally supported. For me, there is always some device or daemon (for example tinyssh in the initramfs of my gaming pc so that I can unlock it remotely) that only works with “plain old ssh keys”. And if I have to distribute and sync my keys onto a few hosts anyway, it takes away the benefits.

Might actually be a positive instead of a negative. Gaming use-cases should have not any effect on security policies, these should be as separate as possible, different auth mechanisms for your gaming stuff and your professional stuff ensures nothing gets mixed.

Hah? It being my gaming machine has nothing to do with the problem. It’s also my FPGA development machine, though it gets used less for that. It only happens to be the only Linux workstation in my home (the others are Macs or OpenBSD).

Re: SSH certificates: the better SSH experience

#123

Post by TZubiri »

anyfoo wrote: post #122
TZubiri wrote: post #51

Earlier quoted context omitted.

Might actually be a positive instead of a negative. Gaming use-cases should have not any effect on security policies, these should be as separate as possible, different auth mechanisms for your gaming stuff and your professional stuff ensures nothing gets mixed.

Hah? It being my gaming machine has nothing to do with the problem. It’s also my FPGA development machine, though it gets used less for that. It only happens to be the only Linux workstation in my home (the others are Macs or OpenBSD).

If you care about security, I recommend investing into a separate computer for developing hardware and software and another for downloading games on.

You can setup your security any way you like, but nothing beats an air gap in terms of security and simplicity.

Re: SSH certificates: the better SSH experience

#124

Post by soupbowl »

akerl_ wrote: post #120
Terr_ wrote: post #103

Earlier quoted context omitted.

> secure channel, e.g. either by using a USB memory Aside: We need a "safely dumb" storage plug standard. Right now the flexibility of USB is a double-edged sword, any USB device could potentially be malicious, waiting for the right moment to send keystrokes as a keyboard etc. Or use the same plug for everything, but support a "passive storage only" that can be enforced by a special adapter or cable.

Assuming you’re not just soliciting random thumb drives from strangers… this doesn’t feel like an actual risk. When you’re getting things from strangers, use any of the myriad ways to send files over a network, where HTTP / your browser are the safe dumb plug.

The place you buy the thumb drive is also a stranger that can't be trusted.

Re: SSH certificates: the better SSH experience

#125

Post by akerl_ »

soupbowl wrote: post #124
akerl_ wrote: post #120

Earlier quoted context omitted.

Assuming you’re not just soliciting random thumb drives from strangers… this doesn’t feel like an actual risk. When you’re getting things from strangers, use any of the myriad ways to send files over a network, where HTTP / your browser are the safe dumb plug.

The place you buy the thumb drive is also a stranger that can't be trusted.

This kind of paranoia isn't productive.

Re: SSH certificates: the better SSH experience

#126

Post by dizhn »

gnufx wrote: post #67
dizhn wrote: post #39

Earlier quoted context omitted.

I am keeping an eye on the new (and alpha) Authentik agent which will allow idp based ssh logins. There's also SSSD already supported but it requires glibc (due to needing NSS) meaning it's not available on Alpine.

If you mean using OIDC, in that space there's at least https://github.com/EOSC-synergy/ssh-oidc , https://dianagudu.github.io/mccli/ and OpenPubkey-ssh discussed in https://news.ycombinator.com/item?id=43470906 (which might mention more). How does SSSD support help with SSH authN? I know you can now get Kerberos tickets from FreeIPA using OIDC(?), but I forget if SSSD is involved.

I haven't used SSSD due it not being available for Alpine but doesn't it provide authentication via pam_sss ?

Re: SSH certificates: the better SSH experience

#127

Post by Terr_ »

akerl_ wrote: post #125
soupbowl wrote: post #124

Earlier quoted context omitted.

The place you buy the thumb drive is also a stranger that can't be trusted.

This kind of paranoia isn't productive.

It was productive enough for the NSA and FBI when they were intercepting equipment deliveries and installing backdoors in them.

A USB stick that can secretly remember any file that looks like a key file or certificate would be very easy.

Re: SSH certificates: the better SSH experience

#128

Post by ordinary »

bombcar wrote: post #84
tacostakohashi wrote: post #65

One constant source of amazement for me is people not using ssh keys / using passwords with ssh. Especially at a BigCo, where there are different environments, with different passwords, and password expiry/rotation/complexity rules. Like, when asking for help, or working together... you say to them "ok, lets ssh to devfoo1234", and they do it, and then type in their password, and maybe get it wrong, then need to rese…

Keys is great for individual use, or for company use if you have centralized key control (and issue one or more keys per user). Often you either end up with one "dev ssh key" for all machines (which is bad) or you end up with people sharing around keys and unidentified keys on machines. Passwords at least are "simple" for people to work with.

> Often you either end up with one "dev ssh key" for all machines (which is bad)

Or, conversely: with one "dev password" for all machines.

Re: SSH certificates: the better SSH experience

#129

Post by otabdeveloper4 »

cyberax wrote: post #74
namibj wrote: post #72

Earlier quoted context omitted.

And what about the CA?

It's no different compared to regular SSH private keys. You need to protect it from compromise. However, it provides you an additional layer of protection, because it does not need to be on the critical path for every SSH connection. My CA is a Nitrokey HSM, for example. I issue myself temporary certs that are valid only for 6 hours for ephemeral private keys.

Yes it is different. SSH CA keys are harder to secure and attackers have a much bigger incentive to steal them.

Re: SSH certificates: the better SSH experience

#130

Post by NicolaiS »

fc417fc802 wrote: post #41
jcalvinowens wrote: post #14

You can also address TOFU to some extent using SSHFP DNS records. Openssh supports checking the DNSSEC signature in the client, in theory, but it's a configure option and I'm not sure if distros build with it.

Any idea if there's a standardized location, something like /.well-known/ssh?

This exists, but not very well supported: https://github.com/C2SP/C2SP/blob/main/well-known-ssh-hosts....

But DNSSEC + SSHFP is a better supported solution at the moment

Post reply on HN