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.

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.

i attempt to use this and some programs recognize this and many just don't

Don't these apps just use PAM? Since the initial complaint was about sudo, I'd figure pam / polkit would handle this, and apps would call those to obtain privilege elevation.

Forwarding the ssh agent (-A) is considered insecure. Instead man ssh recommends using a jump host (-J)

I was talking about the GPG agent, so that the key on the smart card can be used to for sudo elevation on the remote host. This usually requires user interaction with the key, so just having access to the agent wouldn't do much. I don't think the ssh agent would help with this.

To your point, I wonder whether that consideration holds when the private key is held on an external device, like is the case with a YubiKey. I use that setup, and I can't add the key to the ssh agent.

    $ ssh-add .ssh/id_yubikey_gpg.pub                                                                                                                                                                                                                                                                                                                     
    Error loading key ".ssh/id_yubikey_gpg.pub": error in libcrypto

SSH connections work fine with that key.

That's not what the parent is talking about.

They're specifically refering to password authentication to make the ssh connection.

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.

The local agent can ask the user to approve/deny signing requests.

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.

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?

You can commonly deploy the device/server with the client's public key.

That's assuming the device runs GNU/Linux with / mounted rw. But not everything is a laptop or a desktop.

[delayed]

I don't know. I come across old AP/routers where I've forgotten the login credentials and find myself hard resetting them with some regularly, one that's above "approximately never" anyway.

I'm presuming the hard reset is to a factory-assigned password.

Is that uniform across all devices, or device-specific?

Practice I've seen for some years now is to have a label on the device with admin/root password, which is presumably neither uniform across devices nor trivially-determinable from device characteristics (e.g., MAC address, sequential serial numbers, etc.).

I'd still consider that practice reasonably tolerable, though you should be keeping better tabs on assets and credentials.

It could be totally fine if you disable WiFi and connect physically. At least the first time for setup.

No, it's assuming a device running a ssh daemon with something mounted rw or user-modifiable[0] that can hold an authorized_keys file. A NetBSD embedded board that configures sshd with `AuthorizedKeysFile /sdcard/config/authorized_keys` would be fine, for instance.

[0] For example, you could let the user write their key to an SD card and then mount it ro on the device.

So what do you do when the device has no long-term storage like an SD card?

Such a device is then simply not suitable for situations where the issues with SSH password authentication become relevant.

What kind of device runs sshd but has no persistent storage?

What if it's mass produced and sold in a store?

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.

what other situation would you be in?

Any device where you don't control the initial firmware, and the firmware doesn't support ssh keys. AP/Routers (consumer and commercial and industrial grade), Shared hosting with ssh but limited features (eg GoDaddy)...

For physical devices, you can usually connect them via a dedicated Ethernet cable right to your laptop, and set the initial password. They likely don't have the right network settings anyway to drop them right into the bigger LAN.

Otherwise I think you just prepare a certificate ahead of time, and scp it during the first connection, then immediately disable password-based access, or at least change the password. Any passive eavesdropping still needs to defeat the encryption somehow (no feasible ways are known now), even having seen the initial exchange.

If you have an active MITM attack, all bets are off, because the attacker could even grab the image with the pre-baked key you're sending, and copy or change the key. If this is not possible, then the pre-baked key would help. If your security is really important, don't use ther cheap GoDaddy's offerings with limited SSH.

Let's say you bought a router and now you want to log into it.

Then you connect physically and do whatever is necessary to prepare that router for your intended use.

Connect to what? It only has an ethetnet jack.

Your laptop, for instance.

Are you being intentionally difficult or have you just never bought and set up a router?

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.

The password needs to be generated somehow, right? Assuming you don't you use a pre-baked password that repeats across machines, you could replace the password generation and retrieval with deploying a public key instead.

The remote system must generate its own SSH private key; you could use that opportunity to deploy the authorized keys before sealing the system as read-only.

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.