Cannot log in as vsedach@common-lisp.net after added SSH key to Gitlab
Hello, I ran into a strange problem: I added a new ed25519 key to authorized_keys2, which worked fine. Then I went to Gitlab web interface and tried adding the ed25519 key, which failed because Gitlab cannot handle ed25519 keys yet. I made a new RSA key and added that in the Gitlab web interface. After this I cannot log into vsedach@common-lisp.net with any of the keys that were in authorized_keys2. The error message is "Permission denied (publickey)" so something must have happened to the authorized_keys file. This seems very strange. I do not think I did anything as vsedach@common-lisp.net that would break log-ins, which leads me to believe that it was some script in Gitlab. OTOH the new RSA key does not work either, so it might be something I did through TRAMP by accident. Can you please put this SSH key into authorized_keys: ssh-ed25519 AAAAC3NzaC1lZDI1NTE5AAAAIDc+4x1XblOzyfHAzOCbM00FB/VglYg0PvOSL8FuQKQ/ vas@t43.lan. Thank you, Vladimir
On 7/1/17 23:12, Vladimir Sedach wrote:
ssh-ed25519 AAAAC3NzaC1lZDI1NTE5AAAAIDc+4x1XblOzyfHAzOCbM00FB/VglYg0PvOSL8FuQKQ/ vas@t43.lan
Added the key to <file://comon-lisp.net/home/vsedach/.ssh/authorized_keys>, and hopefully didn't munge the permissions too badly. Let us know if you need more help re-establishing control. In general, I find our SSH situation a bit wonky, presumably as we are still running an older Debian distribution that doesn't have all the latest SSH conventions well established. Erik has been working on moving us over to the latest Debian ("Stretch") which I would argue would be the sane point to try to figure out why sshd on that host behaves the way it does. -- "A screaming comes across the sky. It has happened before, but there is nothing to compare to it now."
Hi, I still cannot connect - thanks for the heads up on the Debian distribution issue. There might be two problems: 1. .ssh/authorized_keys2 is still there and still trashed 2. old OpenSSH version that does not support ED25519 keys. I think the problem was caused because I had ControlMaster on in the SSH config on the machine I was using - I trashed the authorized_keys2 file when trying to add the new SSH key (there was probably a newline missing at the end) and I did not notice until the ControlMaster connection expired. If you remove vsedach/.ssh/authorized_keys2 and put my new RSA key (attached) in .ssh/authorized_keys I should be able to get back in. Thank you! Mark Evenson <evenson@panix.com> writes:
On 7/1/17 23:12, Vladimir Sedach wrote:
ssh-ed25519 AAAAC3NzaC1lZDI1NTE5AAAAIDc+4x1XblOzyfHAzOCbM00FB/VglYg0PvOSL8FuQKQ/ vas@t43.lan
Added the key to <file://comon-lisp.net/home/vsedach/.ssh/authorized_keys>, and hopefully didn't munge the permissions too badly.
Let us know if you need more help re-establishing control.
In general, I find our SSH situation a bit wonky, presumably as we are still running an older Debian distribution that doesn't have all the latest SSH conventions well established. Erik has been working on moving us over to the latest Debian ("Stretch") which I would argue would be the sane point to try to figure out why sshd on that host behaves the way it does.
Hi Vladimir, Sorry for the long response time. The problem was that the .ssh directory as well as the authorized_keys (and authorized_keys2) file were group and world readable. OpenSSH will deny entry when they are. I've fixed that and installed the t43 RSA key in your authorized_keys file as per your request (and deleted the authorized_keys2 file). Hope it works now! Regards, Erik. On Mon, Jul 3, 2017 at 8:34 PM, Vladimir Sedach <vsedach@gmail.com> wrote:
Hi,
I still cannot connect - thanks for the heads up on the Debian distribution issue. There might be two problems: 1. .ssh/authorized_keys2 is still there and still trashed 2. old OpenSSH version that does not support ED25519 keys.
I think the problem was caused because I had ControlMaster on in the SSH config on the machine I was using - I trashed the authorized_keys2 file when trying to add the new SSH key (there was probably a newline missing at the end) and I did not notice until the ControlMaster connection expired.
If you remove vsedach/.ssh/authorized_keys2 and put my new RSA key (attached) in .ssh/authorized_keys I should be able to get back in.
Thank you!
Mark Evenson <evenson@panix.com> writes:
On 7/1/17 23:12, Vladimir Sedach wrote:
ssh-ed25519 AAAAC3NzaC1lZDI1NTE5AAAAIDc+4x1XblOzyfHAzOCbM00FB/VglYg0PvOSL8FuQKQ/ vas@t43.lan
Added the key to <file://comon-lisp.net/home/vsedach/.ssh/authorized_keys>, and hopefully didn't munge the permissions too badly.
Let us know if you need more help re-establishing control.
In general, I find our SSH situation a bit wonky, presumably as we are still running an older Debian distribution that doesn't have all the latest SSH conventions well established. Erik has been working on moving us over to the latest Debian ("Stretch") which I would argue would be the sane point to try to figure out why sshd on that host behaves the way it does.
-- Bye, Erik. http://efficito.com -- Hosted accounting and ERP. Robust and Flexible. No vendor lock-in.
participants (3)
-
Erik Huelsmann -
Mark Evenson -
Vladimir Sedach