That is not the only time you use passwords over ssh, e.g. I don't use a password to remote into my desktop from my laptop, but I do use one when using sudo on the desktop.
Actually this is something that is relevant to my interests.
I prefer to have sudo ask for a password when I'm physically in front of the machine, but not if it's a remote session (e.g. SSH from my laptop to my desktop).
Maybe the SSH agent on the client can re-authenticate to the server when requested?
Note that this is a bad idea from the security standpoint, as it requires SSH agent forwarding. Which means that, if the remote server is compromised, the attacker can use your SSH agent to log into other servers as you.
FWIW, you can probably configure sudo to use something other than passwords. On a Mac you can use the fingerprint reader for example, it's just disabled by default.
And your terminal may come with a password manager too, which would be unlocked with whatever means.
Again, on a Mac with iTerm you can do this with a fingerprint.
Same way you'd get the password? It's either a physical or virtual server you more or less control, in which case the siblings' answers apply. Otherwise, it's probably some kind of image or something someone else controls, in which case bake in or send them your public key or certificate (if you've got colleagues in the same situation as yourself).
That is not the only time you use passwords over ssh, e.g. I don't use a password to remote into my desktop from my laptop, but I do use one when using sudo on the desktop.
Actually this is something that is relevant to my interests.
I prefer to have sudo ask for a password when I'm physically in front of the machine, but not if it's a remote session (e.g. SSH from my laptop to my desktop).
Maybe the SSH agent on the client can re-authenticate to the server when requested?
> Maybe the SSH agent on the client can re-authenticate to the server when requested?
There is a PAM module that does this: https://github.com/jbeverly/pam_ssh_agent_auth
Note that this is a bad idea from the security standpoint, as it requires SSH agent forwarding. Which means that, if the remote server is compromised, the attacker can use your SSH agent to log into other servers as you.
1 reply →
Is there no way to forward fido tokens? Or the GPG agent with a Yubikey.
Under Windows, you can forward your smartcard over remote desktop. It's one of the few things Windows has I miss on Linux.
Forwarding the ssh agent (-A) is considered insecure. Instead man ssh recommends using a jump host (-J)
1 reply →
i attempt to use this and some programs recognize this and many just don't
1 reply →
FWIW, you can probably configure sudo to use something other than passwords. On a Mac you can use the fingerprint reader for example, it's just disabled by default.
And your terminal may come with a password manager too, which would be unlocked with whatever means.
Again, on a Mac with iTerm you can do this with a fingerprint.
That's not what the parent is talking about.
They're specifically refering to password authentication to make the ssh connection.
we're not necessarily talking about ssh authentication. Wouldn't that send the entire password as a single packet, anyway?
correct - this is for the post-auth session and not the authentication phase
How would you log in for the first time into a headless device?
Same way you'd get the password? It's either a physical or virtual server you more or less control, in which case the siblings' answers apply. Otherwise, it's probably some kind of image or something someone else controls, in which case bake in or send them your public key or certificate (if you've got colleagues in the same situation as yourself).
Getting a password does not require modifying the system. Injecting a public key does.
2 replies →
You can commonly deploy the device/server with the client's public key.
What if it's mass produced and sold in a store?
That's assuming the device runs GNU/Linux with / mounted rw. But not everything is a laptop or a desktop.
8 replies →
I'd use a base image with a baked-in SSH certificate allowed.
Fairly trivial to make, at least with NixOS.
This hinges on this being either a VM or some hardware you've set up yourself.
8 replies →
[dead]
This is naive in the extreme. There are many scenarios where passwords are needed, for bootstrapping, a disgruntled admin leaving, etc.
There is a role for a common secret in a secure ecosystem (password, passkey)
That common secret is usually an ssh key which is held somewhere secure hopefully with auditable access.
For bootstrapping you can bake a bootstrapping key into your installer which is removed after the system is configured.
This is completely irrelevant to password based SSH authentication. The timing obfuscation is for the session _after_ authentication.