Comment by lmilcin | Hacker News Reader

Comment by lmilcin | Hacker News Reader

Parent Full thread

A few years back, on day 1 of my new job I was given root access to one of the development boxes.

So I ask: "Okay, how do I log in?"

The IT guy: "What do you mean, you just log in using your personal domain account and then sudo su -. You know what sudo is?" (followed by loud sigh)

Me: "You mean like production domain, same that we use for our desktop?"

IT guy: "Of course! What do you mean, what other domain would you like?"

Me: "Can I at least change my password to something else just for the dev environment? Can I log in with SSH key?"

IT guy: "No, no, no. Per our SECURITY policy, SSH keys are disabled and you have to use our domain login and password". (another sigh... of course)

Me: "Are you aware that when somebody has root access to the box they can do whatever they want including intercepting passwords of all users that log in to that box? In this case, every single developer that ever needs access to dev environment?"

IT guy: "That's not true. SSH is encrypted protocol and it is not possible to access passwords".

Me: after many tries to explain this to various people from IT, I gave up and set out to intercept all passwords of all IT employees. After I had passwords of almost everybody, I put them all in an excel and sent to IT for "verification".

There were a lot of angry people that day wanting me fired... fortunately they came to their senses.

Unfortunately, my development box access privileges were revoked.

I think even if you were fired, you'd have dodged not a bullet but a cannonball there.

Sometimes being the nice guy full of good faith doesn't pay. Literally

Nah, I worked there for a long time and I was sad when I needed to leave. I had best boss and best project ever and I learned and grew a lot.

That's good to hear! Although I would have been frustrated and made anxious by their security practice. Did they change their security practices after that 'event'? And did you manage to regain access to your development box?

I once decided to show the vulnerability of SMTP protocol by sending an email as a higher-up. (Too young, too naive, don't ask why I did that.) Created a massive firestorm. I did successfully convert them to use SPF and DKIM and showed everyone the need to never trust an email. Some even adopted PGP signatures after that.

I like to imagine you sent an email as a CEO saying “please read this ASAP” and then it links to a Rick Roll

> There you go, giving a fuck when it wasn't your turn to give a fuck.

>

> - Bunk

"The standard you walk past is the standard you accept."

>sudo su -

It's high time for this thing to die. sudo supports this natively since forever:

  $ sudo -i

Why

Curious, whats the difference and why is sudo -i better? I was unaware of sudo -i (I might as well be a noob though), so I had a quick search to find out more and found this [0]

One question, if I may, could there be any situation (that you can think of, off the top of your head) where using sudo -i would be worse then "sudo su -"

[0] - https://www.maketecheasier.com/differences-between-su-sudo-s...

'sudo su -' uses root to run 'su -' to open a root login shell.

'sudo -i' opens a root login shell.

su is old fashioned but it works fine. I don't even have sudo installed on my PC.

Huh. TIL.

I usually just do `sudo zsh` :-)

Wait, seriously? How would you do that? And why doesn't it work for ssh keys?

I was under the impression password auth worked very similarly to key auth, as in, the actual bytes of the password or private key are never sent over the wire.

No, password auth transfers the password and (usually) hands it to PAM on the server to verify - the server sees your password. Key auth happens in SSH and the private key never leaves your machine.

(If I remember correctly just putting SSHd in the highest debug level, which logs every byte received, did work to intercept passwords)

Reply on news.ycombinator.com