LinuxQuestions.org - Linux to Linux key authentication problem

- Linux - Security (https://www.linuxquestions.org/questions/linux-security-4/)

- - Linux to Linux key authentication problem (https://www.linuxquestions.org/questions/linux-security-4/linux-to-linux-key-authentication-problem-4175590581/)

Linux to Linux key authentication problem

Using puttygen I created a private and a public key.
I copied the public key in in ~/ssh/authorized_keys on a Debian machine (lets call it debian1)
I configured Putty to use private.ppk and now I can access debian1 from windows, using key authentication
I also disabled password authentication in etc/ssh/sshd_config on debian1

Everything is working perfectly and as expected.

Now I need to configure another Debian machine (lets call it debian2) to access debian1, using key authentication.
I followed the instructions here

Code:

1. Open PuttyGen

2. Click Load

3. Load your private key

4. Go to Conversions->Export OpenSSH and export your private key

5. Copy your private key to ~/.ssh/id_dsa (or id_rsa).

6. Create the RFC 4716 version of the public key using ssh-keygen

ssh-keygen -e -f ~/.ssh/id_dsa > ~/.ssh/id_dsa_com.pub

7. Convert the RFC 4716 version of the public key to the OpenSSH format:

ssh-keygen -i -f ~/.ssh/id_dsa_com.pub > ~/.ssh/id_dsa.pub

But when connecting from debian2 to debian1, I still get a password prompt.
Any idea on what could I be doing wrong?

Thanks

In the documentation on OpenSSH (and the man pages) are lists of requirements and things SSH will check. Among them are the permission and ownership of the home folder, the .ssh folder, and the files within the .ssh folder. As a first cut, I would check and compare those permissions. If a file or folder is group or world writable, it is not considered secure and ssh will not trust it without some special (and not recommended) settings or work-arounds.

In addition to the permission settings mentioned already, you might make sure that you are NOT using DSA. Not only is it no longer considered secure, the new versions of OpenSSH server ignore it. You can use 2048-bit RSA, if and only if you need backwards compatibility with specific old things, otherwise use ed25519 if you can. Ed25519 is currently considered the strong option.

Then there is the key format. PuTTY uses a weird one. So if you generate the key pair on Debian with the regular "ssh-keygen" and without PuTTY it should be fine.

On Debian2:

Code:

ssh-keygen -f ~/.ssh/debian1_ed25519 -t ed25519 -C "your note or comment"

ssh-copy-id -i ~/.ssh/debian1_ed25519 debian1

Code:

ssh-keygen -f ~/.ssh/debian1_rsa -t rsa -b 2048 -C "your note or comment"

ssh-copy-id -i ~/.ssh/debian1_rsa debian1

Thanks, I'll give it a go.

Best to view the logs on the server as well.

Code:

tail -f /var/log/auth.log

That will follow the log and print new entries as you try to log in. Any errors (including permissions errors) will be recorded there. See also http://stackoverflow.com/questions/6...-automatically

You probably want to configure sshd so that, if you do not have a key, it will not prompt you for a password. So that, if you do not have a key, you have no opportunity to get in otherwise.

I agree with sundialsvcs. See PasswordAuthentication and ChallengeResponseAuthentication settings in "man sshd_config". You could even use a match block to only do it sometimes and not others. For instance, on my raspberry pi, I allow local LAN to use a password but if SSH sources are from the Internet then the only method allowed is public key. Here's how I accomplish that in my /etc/ssh/sshd_config.

Code:

Match Address 192.168.10.0/24

    PasswordAuthentication yes



Match All

    PasswordAuthentication no

    ChallengeResponseAuthentication no

192.168.10.0/24 is my LAN and All other sources include the Internet. See "man sshd_config" to learn more. It's wonderfully powerful. Also, I don't recommend exposing your SSH port to the Internet (I'm an experienced sysadmin who is capable of securing and monitoring my home services). Additionally, I implement further layers of security around my SSH service such as port knocking and fail2ban.