Deprecated option RhostsAuthentication

[WeirDave]

Starting sshd I receive:

/etc/ssh/ssh_config line 99: Deprecated option RhostsAuthentication Extra argument restart.

What is this and how do I fix it?

TIA,

[WeirDave]

Anyone ever seen this?

[Chris W]

You probably fix it by not using the deprecated option RhostsAuthentication.

You could use RhostsRSAAuthentication or set up ssh-agent to remove the passphrase burden on users and effectively make password-less ssh.

[WeirDave]

You probably fix it by not using the deprecated option RhostsAuthentication.

You could use RhostsRSAAuthentication or set up ssh-agent to remove the passphrase burden on users and effectively make password-less ssh.

Okay so I am a lamer.. I have no idea what you are talking about. Can you explain in more detail?

[Chris W]

Rhost files were used in the bad-old-days to allow users on Machine A to log in to Machine B without requiring a password using utilities like rsh, rexec, and rcp. This scheme used file like /etc/rhosts, hosts.equiv, and ~/.rhosts. The system was prone to abuse, eavesdropping, and was easily spoofed.

With SSH there are two different ways to achieve a similar result:

• RhostsRSAAuthentication: passwordless login is allowed if the two machines can recognise each other using a public key cryptographic exchange and the rhosts files allow it. This removes a large number of spoofing attacks that plagued rsh et al. because the cryptographic checks aren't easily fooled, and cryptographically covers all data transmitted.
• Each user has a key pair and login is allowed if the client can prove it has the private half of a key pair; the server has the public half. The user stores the private key in a local file and decrypts it as needed using a passphrase or run ssh-agent to decrypt the keys once and provide them as needed.

So, it depends on exactly what you want to achieve. Completely passwordless login with slightly lower security, or one-time passphrase entry followed by password less logins for the session.

[WeirDave]

Rhost files were used in the bad-old-days to allow users on Machine A to log in to Machine B without requiring a password using utilities like rsh, rexec, and rcp. This scheme used file like /etc/rhosts, hosts.equiv, and ~/.rhosts. The system was prone to abuse, eavesdropping, and was easily spoofed.

With SSH there are two different ways to achieve a similar result:

• RhostsRSAAuthentication: passwordless login is allowed if the two machines can recognise each other using a public key cryptographic exchange and the rhosts files allow it. This removes a large number of spoofing attacks that plagued rsh et al. because the cryptographic checks aren't easily fooled, and cryptographically covers all data transmitted.
• Each user has a key pair and login is allowed if the client can prove it has the private half of a key pair; the server has the public half. The user stores the private key in a local file and decrypts it as needed using a passphrase or run ssh-agent to decrypt the keys once and provide them as needed.

So, it depends on exactly what you want to achieve. Completely passwordless login with slightly lower security, or one-time passphrase entry followed by password less logins for the session.

Thank you for this great information. I would like to have password/user name authentication. How can I achieve this?

[Chris W]

You need to run ssh-keygen as the user on the client machine. This will generate two files in ~/.ssh, id_rsa and id_rsa.pub. The id_rsa.pub file contains the public half of the key pair. This file should be transmitted to the SSH server by whatever means available and appended to the file ~remote_user/.ssh/authorized_keys where remote_user is the name of the user account on the remote machine. The private key (id_rsa) is encrypted using a passphrase as the key and should be kept secret. That's the guts of it.

When you ssh -l remote_user server the SSH server software looks into remote_user's home directory for the information needed to perform the cryptographic handshake. The client machine will prompt for a passphrase to decrypt the private key during this exchange. If the client can prove it has the private half of one of the public keys in authorized_keys then the connection is permitted.

To avoid having to enter the passphrase every time a connection is established you can use the ssh-agent program or a wrapper around it e.g. emerge keychain.