[written-beyond]

The number of times I've been stuck wondering if my keystrokes are registering properly for a sudo prompt over a high latency ssh connection.

These servers I had an account setup too were, from what I observed, partially linked with the authentication mechanism used by the VPN and IAM services. Like they'd have this mandatory password reset process and sometimes sudo was set to that new password, other times it was whatever was the old one. Couple that with the high latency connection and password authentication was horrible. You would never know if you mistyped something, or the password itself was incorrect or the password you pasted went through or got double pasted.

I think this is a great addition, but only if it leads to redhat adopting it which is what they were running on their VMs.

[ornornor]

Around 2004 someone gave me Linux CDs (I think it was mandrake?) that I tried to install. And I got stuck at the password input part of the setup, I thought it didn’t work and went back to windows. I didn’t start using Linux until 13 years later… I think I’d have switched much earlier if not for that weird UI decision.

[tankenmate]

This decision long predates Linux. It's been a staple back to the earliest days of Unix; and it isn't a weird decision if you take into consideration of multi user systems in office environments that have non trivial security considerations (for example telecoms companies), which is exactly where Unix came from.

[wartywhoa23]

Well, if leaking the length of the password is such a big deal, why not just use a reasonably long password?

Moreover, if someone can see the number of asterisks on the screen, what prevents them from seeing the actual keys that are being pressed?

[tankenmate]

Again looking back at the history of Unix, it used a 56 bit variant of DES encryption that used the user's password as the key. So only the first 8 characters of the password were used and the rest was silently unused, for example "password" and "password123" would have been the same password on early Unix. And although most BSDs and Linuxes moved in the mid 90s to PAM (and hence md5, etc) most SVR4s didn't move until late in the 90s. And at the other end, DES crypt() made its way into Unix in some v6s (~1977) and became widely available in the release of v7 Unix. So 8 character passwords were a thing for about 20 years.

[LtWorf]

My lab at university was like this, well into the 2000s. I remember a guy just smashing keys on his keyboard and then the login worked and I was amazed at how complex his password was and how he could manage to type it that fast

[drooopy]

I liked how the IBM Lotus suite hid password input behind a randomly-generated number of asterisks per key press.

[LorenDB]

Or listening to the number of keystrokes (although you can add random characters and then backspace to help mitigate this).

[oldestofsports]

Video cameras are a thing too

[sandworm101]

It was also a time when not every employee had their own computer. It was very normal for pairs or groups of people to all huddle around a machine while working through a problem. It was also common to have someone behind you waiting for their "turn" to use the machine for their project.

[indrora]

It was directly a result of some of the choices made by Bell and plausibly Teletype.

Early switching computer systems that had user accounts at Bell also didn't echo back for passwords as some terminals were mixed-duplex, from what I've gleaned in the very odd corners of ESS systems. I suspect the idea is that the model they were working from were touchtone telephones and rotary phones, so numeric passcodes were the standard, and you heard & saw those already? Less noise on paper tapes? The possible list of options goes on and on.

Bell Labs was... Different than your average office or telco environment, I should add.

But that's a swag at best today, without knowing the people that worked on it.

[mbesto]

The number of times i realized half way that I probably posted the wrong password and so I vigorously type the 'delete' key to reset the input is too damn high

[larsbrinkhoff]

Just type Control-U once.

[eptcyka]

The Just in that sentence is wholly unjustified. There are plenty of cli/tui/console/shell shortcuts that are incredibly useful, yet they are wholly undiscoverable and do not work cross-platform, e.g. shell motions between macOS and reasonable OSes.

[QuantumNomad_]

> shell motions between macOS and reasonable OSes

All the movement commands I know work the same in the terminal on a default install of macOS as it does in the terminal on various Linux distros I use.

Ctrl+A to go to beginning of line

Ctrl+E to go to end of line

Esc, B to jump cursor one word backwards

Esc, F to jump cursor one word forward

Ctrl+W to delete backwards until beginning of word

And so on

Both in current versions of macOS where zsh is the default shell, and in older versions of macOS where bash was the default shell.

Am I misunderstanding what you are referring to by shell motions?

[eptcyka]

Yea, but ctrl + arrows to move cursor between ‘words’ don’t work, especially sad when SSH’ing in from linux. It works fine when using terminal on macOS - you just use command + arrows.

[mathfailure]

Works fine for me. Configure your shell.

[jorvi]

These are emacs bindings of yore. On macOS and some Linux DEs they also work in UI text fields :)

[malfist]

What happens when you press home or end?

[int_19h]

In iTerm at least it goes to the beginning or end of current line.

[macintux]

The number of times I’ve attempted to use Ctrl-U in a Python shell only to discover it doesn’t work…

[fulafel]

Haven't seen this - shouldn't this always work on unixy platforms? If using readline/editline it works, and if built without it also works.

[macintux]

It’s an internal, custom, vaguely UNIX-like shell in Windows. Typically I’m running Python from bash; Ctrl-U works under bash, but not Python.

[fer]

> e.g. shell motions between macOS and reasonable OSes.

I forgot about this since I started NixOS/home-manager everywhere.

[tspng]

That's great. I've been using terminals for 20+ years, and never new about CTRL-U. Thanks! TIL.

[larsbrinkhoff]

It's built into the Unix terminal driver. Control-U is the default, but it can be changed with e.g. "stty kill". Libraries like readline also support it.

[queenkjuul]

I only know this because of xkcd

[amarant]

The number of times I've posted my sudo password in a random slack channel instead of my terminal is not very high, but too damn high nonetheless

[asimovDev]

I have had a similar issue where I thought my computer went to sleep so I start typing my password while the monitor wakes up only to realize that it was only the screen that turned off and the computer was already unlocked so when I hit enter the password was sent into a slack thread or dm instead

[antod]

Start your password with a forward slash :)

[lxgr]

The trick is to use a plausible Slack message as your sudo password :)

[Matheus28]

“I quit!” Even includes a special character

[doubled112]

"I, uhh, need your thoughts." should have fewer consequences AND be more secure.

[rkomorn]

Did you just type in your password on HN?

[dotancohen]

hunter2

[hilliardfarmer]

Get out of my head, lol :)

But yeh, never thought this was a problem anyone else delt with. My passwords are all a variant of my on "master password" and sometimes forget which session I'm in so trying to save keystrokes, count backward to where I think the cursor should be.

[pseudohadamard]

I wonder if it'll stick though? Some years ago FreeBSD changed their setup so the initial password you set on install was echoed back to you so you could verify that the thing that'll completely lock you out of the system if you get it wrong is correctly set up. The response was total hysteria. Apparently people were setting up their 1U rack-mount servers while riding the No.8 bus and were worried other passengers were looking over their shoulders while they typed in the password. So they backed out of the change after being buried in a mountain of complaints.

One thing people are really, really good at is detecting others near them, because it was essential for not getting eaten back in the day. So the chances of (a) someone wanting to shoulder-surf (b) being close enough to do so and (c) getting away with it are essentially zero. It was a security measure that made sense in 1973 when you were on a model 33 leaving a printed record in a machine room with a dozen other people, but has been completely nonsensical for several decades.

Which is probably why it invokes so much irrational religious fervor.

[crazysim]

Did that echo the password back on the screen or just asterisks?

[pseudohadamard]

The password, otherwise you have no way to check you've got it right.

[crazysim]

Oh yeah, I can see why some might freak out about that.

[pseudohadamard]

Me too, in the sense that I can see why people freak out about spiders, but it's difficult to come up with any realistic scenario where you need to be worried about a random attacker standing behind you looking over your shoulder to write down your password as you install a server.

[augusto-moura]

Had problems with faulty keyboards in the past too, never to be sure which keys were I pressed I had to type the password in a text file (much more insecure) and then paste it on the prompt. Of course this was never done in front of anyone, shoulder surfing was never an issue to begin with.

[ghighi7878]

I agree that this move is good.

But you should not type sudo passwords on remote machine. Instead setup your machinr to have nopassword for special sdmin account and enable pubkey only authentication.

[written-beyond]

Yeah but am I going to really open another ssh connection just to run an admin specific command. They also didn't provide an admin user, it setup with all of the extra security configurations. You couldn't even `su`

[ghighi7878]

I mean nopasswd option of sudo

[Wowfunhappy]

Why is it better to have a nopassword admin account when using a machine remotely? The point of SSH is to resist mitm attacks, right? If someone could watch my keystrokes, I think I'd have bigger problems!

[tsimionescu]

This resists scenarios where the machine you are running SSH from is compromised, and has a keylogger or something similar installed. SSH can't protect you from a local attacker (in fact, the SSH client binary itself could be the compromised part).

[__david__]

Yes, but if the server you’re logging into only accepts keys then leaking its password isn’t nearly as bad. Though I guess if your local ssh client is compromised then your local private keys are also compromised so you’d be screwed anyway (unless you are using a yubikey type of thing—I should get me one of those).

[Wowfunhappy]

If I own both machines this doesn't seem entirely reasonable. (Of course a machine I own could be compromised but again, then I have other problems.)

[wolvoleo]

With sudo you can also give people specific access to commands.

I personally use the pam ssh agent module for this, that way you can use agent forwarding with sudo.

[ghighi7878]

I did mean nopasswd option of sudo.

[trvz]

Real men rawdog with root.

[Ferret7446]

If you have high latency wouldn't extra echoing use more bandwidth and worsen the situation?

In any case, I don't understand the issue. TCP is "reliable" so it's not like you'll get dropped keystrokes. Just type the password and hit enter, and the entire string will go through when it goes through

[johnisgood]

You can tell if you input something or not, based on the blinking cursor, in which case it is not "frozen".

[semanticc]

Unless you disable cursor blinking because you find it annoying (like I do).

[setopt]

Yeah, disabling cursor blinking is the first configuration I do in any terminal.

[written-beyond]

I mean a trivial solution to all of these work around a could have been each keystroke registers a single asterisk that goes away after a delay. You wouldn't reveal the length and you'd had a standard way of informing the user that their keystroke was registered.

[layer8]

It doesn’t tell you if backspace works, however.

[notatoad]

>a sudo prompt over a high latency ssh connection

i feel this in my bones.

does anybody know what level this change happens on? is this change going to affect ubuntu desktop users on any system they ssh into, or will it affect all users of a ubuntu server who have ssh'd in?

[queenkjuul]

It's the sudo binary installed on the host -- if you're SSH'd to a 26.04 host, you'll see stars; if you're running 26.04 and SSH to a different OS, you won't (unless the remote system is also 26.04 or otherwise using rs-sudo)

[znpy]

You could have avoided the worry completely. Ssh goes over tcp that does transport control (literally the “tc” in “tcp”) and this includes retransmission in case of packet loss.

If you are on a high latency ssh connection and your password does not register, you most likely mistyped it.

[written-beyond]

I am aware of that but you forgot the other conditions. Keys sometimes don't register, I'm not sure why but I do experience missing keystrokes.

The passwords get updated irregularly with the org IAM so you aren't sure what the password even is. Pasting doesn't work reliably sometimes, if you're on windows you need to right click to paste in terminals, sometimes a shortcut works. Neither gives me any feedback as to what event was ever registered though.

[vman81]

Yea, add a VNC jump host and a flaky spice based terminal and there are a bunch of things that can make your input not register properly.

[anthk]

I mostly use Mosh for that.