0

Adding SSH keys

I have a server running CentOS 7. I have a multitude of clients varying from Fedora, Ubuntu, CentOS and Windows 10 if that matters. The only way to log into the server is via ssh on the terminal with a ssh key. No password is enable

What I want to do is to be able as super user to allow for one time login via password in the purpose of adding ssh keys from different machines as it would make things easier.

When a client has logged in it should not be possible to use password login again until it is allowed.

This is the content of my /etc/ssh/sshd_config file with the relevant information

UsePAM yes
PasswordAuthentication no
PubkeyAuthentication yes
ChallengeResponseAuthentication no

Is there any way to do this?

Thanks in advance

Improve this question
3
  • Are you trying to facilitate the client's ability to use ssh-copy-id with password?
    – Aaron Copley
    Jun 10, 2019 at 17:16
  • Yes exactly, however only one time when it is allowed by the super user
    – ComplexXD
    Jun 10, 2019 at 17:30
  • I am sorry that I cannot answer your question, but please consider implementing key management if you have the resources in your organization. The problem with allowing users to add their own key is that when they leave your organization they don't get cleaned up. Also, you can't enforce expiration or rotation policies, etc. This whole document has a great deal of good guidance, but in particular, please look at 5.1.2 SSH Identity and Authorized Keys, Authorized Key Access Controls. nvlpubs.nist.gov/nistpubs/ir/2015/NIST.IR.7966.pdf
    – Aaron Copley
    Jun 10, 2019 at 22:02

3 Answers 3

Reset to default
3

The only time you should need to log on using a password in your given scenario is when bootstrapping key-based logon ability to the first user account on a new host.

Since the server only uses the user's public key to authenticate them, it should be safe for you in your role as a systems administrator to simply ask them for that key and add it to their ~/.ssh/authorized_keys when creating their account. In that case it doesn't matter whether you do so manually, with a shell script, or with an orchestration tool like Ansible.
Naturally, their private key should never leave their computer.

Improve this answer
1

I want to start off by saying that I am answering this question academically. I cannot stand behind it as being a good idea.

Start off by adding a user group to the system; ex. keys-only.

Then, in your sshd_config set PasswordAuthentication no only for members of this group.

Match Group keys-only
    PasswordAuthentication no

Yes, all other users would be able to use passwords. Because...

When a user SSH in for the first time, they should be added to the keys-only group such that subsequent logins they would be subject to the match rule above. You could accomplish this with a script in /etc/profile.d and an appropriate sudo policy.

# Add users to the keys-only group if they are not already members.
if ! lid -gn keys-only >/dev/null | grep -q $USER; then
  sudo usermod -aG keys-only $USER
fi

This is really only a rough pass to get you thinking and not intended to be complete. You'll need to think through scenarios like when the user isn't successfully added to keys-only group. (Subsequent password logins are still permitted.)

Improve this answer
-1

This is probably not a very secure idea. However, I think you should be able to do it via SSHLog:

https://github.com/sshlog/agent/

It's an open source daemon that watches SSH for login attempts. When a user logs in, it could be configured to execute a script. For example:

https://github.com/sshlog/agent/tree/master/daemon/config_samples

In this way your script could check some flag (e.g., a file in their home directory or group membership) and scramble their password or add them to the group approach from @aaron-copely 's answer

You could also trigger Slack alerts or something similar so that you are notified whenever this activity (i.e., a password login) happens.

Improve this answer

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .