Hacker News Reader

Comment by pipo234 | Hacker News Reader

Makes you wonder: why do people still use password authentication with SSH?

Passwords are sent all at once from the client to the server. This feature is for obfuscating your keystroke timing within the encrypted connection.

Even if you don't use password authentication you may still type sensitive information in a SSH session. For example, password when using sudo.

Or any form of authentication for that matter, e.g. AWS.

When I ssh to a device it asks me for a user name and password. Thats probably why.

They are saying, "why don't you use public key cryptograph to create an identity on the remote machine?".

I dont see that option when I ssh to a machine. If you want better defaults then offer them. I was being deliberately obtuse but barely.

I recommend you do set up key authentication. You'll get more convenient logins and better security. This page should document how to do it: https://www.ssh.com/academy/ssh/copy-id

I suppose what the parent is saying is that's not the default. Fresh install of anything is still password and GitHub key import isn't a panacea.

I don't see how ssh-copy-id has anything to do with Github.

Which is commonly deployed via password authentication

For 40% of global use cases there’s probably probably little to no risk.

The rest is probably a mix of good, bad, ‘just enough’.

A central aim of of SSH is confidentiality. There's a lot besides passwords that you can deduce with traffic analysis, especially if you can correlate with other observed events.

How else would I upload my public key?

A service may provision an account with a provided ssh public key, so that you never log in with a password, even once.

It's sort of a chicken-egg problem though, presumably you do have a password somewhere along the line, such as in a portal where you created your account and uploaded your public key.

I'd say there are more valuable things you can do to improve security than solving the problem of "having to ssh in with a password one time to upload a key"

Maybe. Not having a password on the server eliminates all the risks associated with weak or leaked passwords. And then you can configure SSH to reject password logins altogether. It's not an insignificant benefit.

I'd say there are more valuable things you can do to improve security than solving the problem of "having to ssh in with a password one time to upload a key, then updating the config to reject password logins".

If you can't securely ship a public key to a fresh machine, then how can you trust the software running on that machine?

SSH password login is secure. Keys are preferred since you can't have asdf1234 as a key, but if you as the initial person to set up the server are the only one allowed password login and use a decent password, you're fine

The correct answer is using client certificates, but they're a great deal of pain to set up compared to "ssh-copy-id" (or using username/password!)

...Key-distribution is to encryption systems as cache-invalidation is to computer science. Both of which are subforms of the ur-problem of signal-propagation which itself is stemmed from the physical principle of causality.

Only way through it is to shut up and do it, sadly.

The implementation details of doing it are often either A) have physical possesion of computer, and do initial insecure setup within a "secure realm" you control, or B) redefine your "secure realm" to include the hardware being in someone else's possession, and do what they tell you and pray they are trustworthy.

This is irrelevant for SSH password authentication. The obfuscation is for the session _after_ authentication.

For real; you can even make sudo work with SSH_AGENT. Add hardware key and it's pretty nice setup.

Convenience. Keys are more work.

how are keys more work vs password?

something-you-know auth is generally less work than something-you-have auth, since you need to ensure you always have the key handy whenever you would want to log on.

Reply on news.ycombinator.com