# 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

 *Chris W wrote:*   

> 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

 *Chris W wrote:*   

> 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.
> ...

 

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.

----------

