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.