Tag Info

New answers tagged

4

The general answer is that you likely will want to put the same personal public key on all servers/accounts you want to login in on. For all practical purposes it's more or less impossible to derive the private key from the corresponding public half. Then there are a bunch of potential exceptions. While it's normally a good rule to keep the private key ...


1

Modifying Samba and/or NFS is not the proper solution here. Instead further restrict ssh access in /etc/ssh/sshd_config to those users which should have access by using AllowGroups/AllowUsers. You may also be interesting in using Match blocks, depending on your situation.


2

The key is per user, so if you want to use the same private key to log in as your "second user" you will have to add the public key to the "second user"'s authorized_keys-file like you seem to have done for the root user.


0

You will want to configure veto files in the settings. https://www.samba.org/samba/docs/man/manpages-3/smb.conf.5.html#VETOFILES On top of that you should make sure that the settings for these directories are 600 or lower. So no other users can execute. But if its only the one user that is accessing their own home directory the risk should be minimal. It ...


0

I believe the following solution should work in your case. I've been using it for a similar scenario with a central backup server and multiple backup clients. I have a role (let's say "db_replication_master") associated to the server receiving the connections: - role: db_replication_master db_slaves: ['someserver', 'someotherserver'] ...


0

Make sure .ssh and authorized_keys are both owned by monitor and belong to group monitor run this successively: Owner: chown monitor /home/monitor/.ssh Group: chown :monitor /home/monitor/.ssh/authorized_keys Owner: chown monitor /home/monitor/.ssh Group: chown :monitor /home/monitor/.ssh/authorized_keys ALSO: Share with us output of ls -al ...



Top 50 recent answers are included