Securing ssh

I administer a system where the only way to login between trusted hosts is via ssh. This is fine apart from it is possible to set up id key files in the user's .ssh directory that get used on a challenge response basis so that if the machines at both ends have the same key files, the user can log in without typing in a password.

Is there anyway to stop this from a system's point of view? I have had a look in /etc/ssh/sshd_config but there doesn't seem to be anything that relates to this precise scenario.

The reason why I want to do this is so that I can share out home directories to a few `semi-trusted' hosts without a user on that system assuming t he identity of another user, getting a hold of their id files and then obtaining access to the other systems as that user. Telnet and rsh/rlogin et al have all been disabled.


Who is Participating?
I wear a lot of hats...

"The solutions and answers provided on Experts Exchange have been extremely helpful to me over the last few years. I wear a lot of hats - Developer, Database Administrator, Help Desk, etc., so I know a lot of things but not a lot about one thing. Experts Exchange gives me answers from people who do know a lot about one thing, in a easy to use platform." -Todd S.

Hi aecooper,
There are a few lines in the file you mentioned related to this authentication type:-

Have a look in the manual page to find out which one you wish to disable.
RSAAuthentication is for SSH V1 only
PubkeyAuthentication is for SSH V2 only

Therefore I would tyr setting both to no.
and to complete grblades suggestion, disable also:

What were the top attacks of Q1 2018?

The Threat Lab team analyzes data from WatchGuard’s Firebox Feed, internal and partner threat intelligence, and a research honeynet, to provide insightful analysis about the top threats on the Internet. Check out our Q1 2018 report for smart, practical security advice today!


   In sshd_config, you can simply rename
AuthorizedKeysFile     .ssh/authorized_keys  ===> .ssh/xxx

   Then the user can not login without passwd and it safe since sshd_config has permission 600.

Actually, the keys that you are mentioning are a public/private key pair.  They are not the same key.  Every user should have their own, private ".ssh/authorized_keys" file.  I think that the permissions are 600 so other users would not be able to modify it and add their public key.  Since the users' private keys are not your server their should be no problem.  
If you share out home directories like this, I believe that .ssh  directories is just one of many
possible problems... what about .login and .profile files?

Executed when a user logs in..
Programs setuid as the user etc...

I think there are many possible ways this setup would allow one user to execute code as a
different user.

Without major reworking of the shell, login process, and configuration of user programs, the
ability to write to a user's home directory is basically equivalent to the ability to pose as them.

You've managed to make challenge based auth seem a problem, but in general, it's much better than password authentication for remote access purposes
. (Passwords can be guessed, a lot more easily than huge secret keys can be)


Experts Exchange Solution brought to you by

Your issues matter to us.

Facing a tech roadblock? Get the help and guidance you need from experienced professionals who care. Ask your question anytime, anywhere, with no hassle.

Start your 7-day free trial
The person never chose an answer, I guess this is yet another abandoned post by someone who wanted help, but would not help in return by granting points.
aecooperAuthor Commented:
No, this is not the case. The first three comments refer to undocumented features not mentioned in the ssh documentation on our system. The last comment was sort of admitting defeat in as much as there is no way of doing what I want and so the only safe thing to do is to disable write access to home directories.

I gave high points to this questions because I wanted a quick solution. But on not finding one I had to do more research into the problem and reluctantly came to the same conclusion.
The options are part of OpenSSH's  sshd_config

PubkeyAuthentication and RSAAuthentication  options
turn on or off those authentication methods.

And   HostbasedAuthentication   controls  .rhosts style authentication

Anyway,   the authorized_keys file could be rendered useless by using
the   'AuthorizedKeysFile'  option in sshd_config on every system, to use
the same file for all users on the machine   (not found in their home directory),
so the SSH problem should be surmountable.

The major problem with a shared directory is user login scripts and preferences
files..  one user might edit another's mail client  config file and include a
command to be run as them, next time they read their mail

In this respect, it would probably be more sound to just create a shared
subdirectory for each user, and place a line in the .login   or .profile to
set HOME to that subdirectory and CD into it.

aecooperAuthor Commented:
Many thanks for the update... :-) I'll have a look into it. Many thanks once again.
It's more than this solution.Get answers and train to solve all your tech problems - anytime, anywhere.Try it for free Edge Out The Competitionfor your dream job with proven skills and certifications.Get started today Stand Outas the employee with proven skills.Start learning today for free Move Your Career Forwardwith certification training in the latest technologies.Start your trial today
Linux Security

From novice to tech pro — start learning today.

Question has a verified solution.

Are you are experiencing a similar issue? Get a personalized answer when you ask a related question.

Have a better answer? Share it in a comment.