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.
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.
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.
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.
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
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.
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.
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
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.
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?
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.
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.
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
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.
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.
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
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.
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`
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!
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).
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).
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?
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)
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.
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.
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.
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.
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.