2

As recently as yesterday, I was able to connect to our development instance via my local ssh client, using one of several ssh keys listed under sshKeys in the instance's custom metadata (the old-fashioned way). ("Block project-wide ssh keys" is checked). Also that afternoon, while connected, I was doing something where a second ssh session would be convenient. I tried opening a second connection through the local ssh client, and got "Permission denied (publickey)." I tried opening a second connection from the instance console page, and it wouldn't connect, either. Meanwhile, the ssh session I was using continued to work just fine.

This morning I can't get an ssh session on that instance AT ALL.

The only thing I can remember doing yesterday, that was the least bit unusual, was a chmod on my home directory, setting it to "777."

I tried yanking out the sshKeys metadata, and trying the console ssh again. No joy. Then I looked at the serial port 1 log, and noticed this, with timestamps showing GMT for approximately when I tried it:

Nov 28 21:26:49 bitnami-trac-dm-87ea google-accounts: INFO Removing user <redacted>.
Nov 28 21:26:49 bitnami-trac-dm-87ea google-accounts: INFO Removing user <redacted>.
Nov 28 21:26:49 bitnami-trac-dm-87ea google-accounts: INFO Removing user <redacted>.
Nov 28 21:26:49 bitnami-trac-dm-87ea google-accounts: INFO Removing user <redacted>.
Nov 28 21:26:49 bitnami-trac-dm-87ea google-accounts: INFO Removing user <redacted>.
Nov 28 21:26:49 bitnami-trac-dm-87ea google-accounts: INFO Removing user <redacted>.
Nov 28 21:26:49 bitnami-trac-dm-87ea google-accounts: INFO Removing user <redacted>.
Nov 28 21:26:49 bitnami-trac-dm-87ea google-accounts: INFO Removing user <redacted>.

I can get to the password prompt on the serial port, but I've never set myself up with password access, to the best of my recollection.

|improve this question
  • "The only thing I can remember doing yesterday, that was the least bit unusual, was a chmod on my home directory, setting it to '777.'" That'll have done it. If your SSH keys are writable by other users, SSH will refuse to use them. – ceejayoz Nov 28 '18 at 22:08
  • 2
    Make that an "answer," "ceejayoz," and I'll call it solved! I found that I could tell the web-to-ssh on the instance console to sign me on as another user, one to whom I'd given sudo authority, and from that user, I was able to chmod my home directory to 755, and once I did that, I could once again ssh as myself. – hbquikcomjamesl Nov 28 '18 at 23:31
2

The only thing I can remember doing yesterday, that was the least bit unusual, was a chmod on my home directory, setting it to "777."

This is probably what locked you out.

The SSH daemon is pretty paranoid (for good reason), and it'll check various permissions before it allows a connection. If your .ssh/authorized_keys file is writable by other users on the server, SSH won't allow incoming connections for the public keys listed in there.

(It'll also do the same for outbound connections if it detects your private keys are too readable/writeable.)

|improve this answer
  • Thanks for the additional information. Unfortunately, I don't have enough reputation points for my up-vote to actually show, but I did mark the answer as accepted. Sometimes, I forget that compared to OS/400, where the microcode will usually stop you from doing something stupid, *nix can be like walking on mined eggshells. I've written down the specifics of how I undid the damage, and stuck it in a secured disk image on my work Mac, with a special icon superimposing the international "no" symbol over the number 777. – hbquikcomjamesl Nov 29 '18 at 0:10

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.