HOWTO: Lose your shell access.

[willsan]

So, as some of you probably know ssh supports this neat thing called public key authentication that lets you log into servers (like xepher.net) without having to type your password every time.  This provides handy four-keystroke ("!ss enter", assuming you haven't been sshing anywhere else lately) login.  It also prevents people from stealing your password with a key logger or by watching you type it.

It ALSO happens a good way to lock yourself out!  What you do is create a file called .ssh/authorized_keys (so far, so good), and open it in nano.  Then, copy your public key (from your home machine) into that file.  Obviously the fastest way to do that is copy and paste!  Open up a terminal on your Mac/*nix machine (Windows users are on your own, sorry), type "cat .ssh/id_dsa.pub", command-C, tab over to the window where you've got the authorized_keys file on xepher.net open, command-V, ctrl-X, save the file, and logout.  That's it, you're done, and you ain't getting back in until xepher fixes your account for you!  See, ssh expects expects one key in authorized_keys to be on one line, and the cut-and-paste job introduces a line break.  Ssh fails miserably trying to read your key, freaks out, and closes the connection.  As an added bonus, sftp uses ssh in the background, so if you break ssh, you can't even get in and delete the offending file via sftp!

If you've followed these instructions, congratulations, you're now in the same boat I am: unable to do anything (except write tongue-in-cheek tech support posts in the forum) until xepher logs into AIM and/or checks his mail.

   grumble 

[Xepher]

Heheheh! I LOLed! Thanks, that made my day.

For the record "scp ~/.ssh/id_dsa.pub willsan@xepher.net:/home/willsan/.ssh/authorized_keys" should do it in a single command, no need for copy/paste or any such jiggerypokery. Also, "nano -w" (no line wrapping) would've saved your bacon as well. Also, it's good practice to always leave a terminal open/connected when poking at SSH internals, and test a second connection from another terminal to make sure it can still log in.




It should be fixed now, FYI. :-)

[Databits]

Actually, if you still have the original password for the account, you can't lock yourself out using an rsa key. It will fail and request standard login, or should provided that the ssh server is set up correctly.

[willsan]

Actually, if you still have the original password for the account, you can't lock yourself out using an rsa key. It will fail and request standard login, or should provided that the ssh server is set up correctly.

Ssh *should* ask for the password, but instead it just closes the connection.  Unfortunately, that was empirically verified the other day.

Fortunately, it's fixed now.   

[Xepher]

Yeah, I thought about that later, and I THINK you have to disable the keys on the client side, so it doesn't even attempt key-auth, then the password would work. I only tested briefly and it didn't ask me for a password either (on your account) and just died. But I, of course, have my own keys which it may have been attempting to try. Hmm...

Yeah, I just tested that theory... "ssh -o PubKeyAuthentication=no koda@arclight" works with a borked authorized_keys file. Good to know, just in case I ever screw up on my own doing something similar.

[Databits]

Yeah, I have no issues with Putty either in that. The other SSH client may, but I haven't used that in years. I do a lot of logging into servers so using a common key is the easiest way to manage things for me (aside the passwords in the password manager just in case). I've ended up with bad keys a couple times now and never had this issue. It just tells me that the key is rejected and asks for the normal password instead.

[Xepher]

Yeah, it normally does that (ask for a password after a key fails) but this is a particular case where a very specifically borked authorized_keys file causes it to actually die on the server side. Basically, it's seeing a proper "ssh-rsa" keyword, then a newline. If I just fill the file with gibberish, it falls back to password, and if the file doesn't exist or can't be opened, it goes to password. It's just this rare case that causes a glitch.

[willsan]

Yeah, it normally does that (ask for a password after a key fails) but this is a particular case where a very specifically borked authorized_keys file causes it to actually die on the server side. Basically, it's seeing a proper "ssh-rsa" keyword, then a newline. If I just fill the file with gibberish, it falls back to password, and if the file doesn't exist or can't be opened, it goes to password. It's just this rare case that causes a glitch.

Ooooh, that sounds like a failure to sanitize user input in OpenBSD code (assuming you use openssh), I thought they were smarter than that.  Somebody call slashdot.

[Xepher]

Yeah, but I wouldn't be surprised if they call it a "feature." You know, disable key access at the per-user level by providing a blank authorized key. OpenBSD would never have a bug like that, ergo it must be a feature. :-)