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 4 hours ago | parent | next [-]

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 3 hours ago | parent [-]

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 2 hours ago | parent [-]

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 32 minutes ago \| parent [-]
		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.

▲

mbesto 4 hours ago | parent | prev | next [-]

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

▲

hilliardfarmer 4 hours ago | parent | next [-]

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.

▲

larsbrinkhoff 4 hours ago | parent | prev | next [-]

Just type Control-U once.

▲

eptcyka 3 hours ago | parent [-]

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_ 3 hours ago | parent | next [-]

> 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 2 hours ago \| parent [-]
		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.

▲

fer an hour ago | parent | prev [-]

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

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

▲

amarant 2 hours ago | parent | prev [-]

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

	▲	lxgr an hour ago \| parent \| next [-]
		The trick is to use a plausible Slack message as your sudo password :)
	▲	antod an hour ago \| parent \| prev [-]
		Start your password with a forward slash :)

▲

augusto-moura 12 hours ago | parent | prev | next [-]

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.

▲

johnisgood 4 hours ago | parent | prev | next [-]

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

▲

semanticc 4 hours ago | parent | next [-]

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

	▲	setopt 2 hours ago \| parent [-]
		Yeah, disabling cursor blinking is the first configuration I do in any terminal.

▲

written-beyond 32 minutes ago | parent | prev [-]

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.

▲

ghighi7878 11 hours ago | parent | prev | next [-]

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 11 hours ago | parent | next [-]

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 2 hours ago \| parent [-]
		I mean nopasswd option of sudo

▲

Wowfunhappy 3 hours ago | parent | prev | next [-]

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!

▲

wolvoleo 4 hours ago | parent | prev [-]

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 2 hours ago \| parent [-]
		I did mean nopasswd option of sudo.

▲

znpy 10 hours ago | parent | prev [-]

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 9 hours ago | parent [-]

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 8 hours ago \| parent [-]
		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.