chmod to give a remote server read priveleges to a client home directory

[scorp123]

My specific question is: once a person A knows the home directory name and IP address of another persons (B) computer, what's to stop person A from hacking person B using, for example, the code listed above?

Simple: There'd be a password prompt. Without knowing the exact username and the password on the remote system, that command will take you nowhere. And password-authentication is something that can be turned off so that only key-based authentication is possible. And if the systems are supposed to communicate over the Internet then it is good practice to do exactly that. Meaning: You are either in posession of the SSH key and can login, or you do not have the needed SSH key file and can't get in, even if by some dark black magic you were to know the correct password for the remote user account. "You shall not pass!" as Gandalf put it. And key-based authentication can be even escalated further: You could set a passphrase on that key. Meaning: Even if by some dark black magic you were to obtain a copy of the SSH key file you still would not be able to get in if you didn't also know the passphrase for the key. And even this can be escalated even further: you could implement a 2-Factor Authentication mechanism e.g. with Google Authenticator if you wanted to. Meaning: Even if by some dark black magic an intruder were to have a copy of the needed SSH keys and even if they were to know the needed passphrase for those keys, with 2-Factor Authentication they'd still be hitting a wall. Because now they'd also need to be in posession of your mobile phone where Google Authenticator is running.

SSH and by extension running "rsync" over SSH is as safe as you could possibly be, and the security can be tightened to really paranoid levels if you wanted to.

And then there are programs such as "fail2ban". Which can be set to listen for failed SSH login attempts and then automatically ban any wannabe intruder and completely block their IP address from ever reaching your system again. It's also good practice to use that.

[Old Jimma]

Hi ActionParsnip:

Just realized that at least a part of the permission issues on the client machine will be setting up ufw so that it blocks all other ip addresses except the server's ip.

Also, maybe another part of it includes specifying in ufw to accespt ssd (or is it ss "something else"). I am 105 years old and I forget things now and then.

The purpose of my post was to find out if there was anything other than those 2 things to cover the security issues. I vaguey recalled reading that the chmod may be needed... but I really didn't see any way to be very specific about allowing a specific person/ip address using chmod.

In my ancient clumsiness I amy have suggested that username and user ip could be... because of how that can be used with chown.

Alot of people don't know that when you turn 105, you begin to realize that there are more "ch" things to confuse than you had ever thought about.

Hope you have a great day.

Old

[scorp123]

I am 105 years old ...

Impressive.

[TheFu]

chmod works on the local machine or over NFS mounts. There is no remote version of the command.
If you ssh into the remote system, the chmod commands are "local" to that remote system.

Whenever in doubt, check what the manpage says.

Now, you can limit ssh/scp/rsync/sftp access to specific users@specific client hostnames/IPs, but that isn't chmod. That is ssh. The sshd_config file has settings to limit which users from which remote systems can connect. Match is the keyword in that config file. For example, I don't allow any ssh-based access to my systems, except from one of my internal, trusted, subnets.

At the bottom of the sshd_config file, is

PasswordAuthentication no
Match Address 172.22.22.0/24,172.21.22.0/24,172.22.21.0/24
      PasswordAuthentication yes

This says no passwords can be used, unless the client is from one of 3 subnets, then password-based authentication can be used. So, any other subnets (including the internet) must use either ssh-keys or ssh-certs for authentication.

In the OP, you wrote:

chmod -R servername#serveripaddress o=r /home/username

a) servername#serveripaddress isn't valid for any chmod command. Not ever.
b) o=r will set ------r-- permissions, so the user or any members of the group cannot access the file. "Other" means anyone who isn't the owner or in the group. It is highly unlikely you really want this. I suspect you want u=rwx,g=rwx,o=r ... or in octal, 774 (-rwxrwxr--). Much shorter that way. 664 would be -rw-rw-r-- and is also good for data. 644 would be fine too, -rw-r--r--

Seems a refresher on basic Unix permissions is needed. "Ubuntu permissions" web search will find a tutorial, but any Unix permissions tutorial is 100% fine and the same skills. There's no difference between all Unix-based permissions and what Ubuntu does.

[CharlesA]

Simple: There'd be a password prompt. Without knowing the exact username and the password on the remote system, that command will take you nowhere. And password-authentication is something that can be turned off so that only key-based authentication is possible. And if the systems are supposed to communicate over the Internet then it is good practice to do exactly that. Meaning: You are either in posession of the SSH key and can login, or you do not have the needed SSH key file and can't get in, even if by some dark black magic you were to know the correct password for the remote user account. "You shall not pass!" as Gandalf put it. And key-based authentication can be even escalated further: You could set a passphrase on that key. Meaning: Even if by some dark black magic you were to obtain a copy of the SSH key file you still would not be able to get in if you didn't also know the passphrase for the key. And even this can be escalated even further: you could implement a 2-Factor Authentication mechanism e.g. with Google Authenticator if you wanted to. Meaning: Even if by some dark black magic an intruder were to have a copy of the needed SSH keys and even if they were to know the needed passphrase for those keys, with 2-Factor Authentication they'd still be hitting a wall. Because now they'd also need to be in posession of your mobile phone where Google Authenticator is running.

SSH and by extension running "rsync" over SSH is as safe as you could possibly be, and the security can be tightened to really paranoid levels if you wanted to.

And then there are programs such as "fail2ban". Which can be set to listen for failed SSH login attempts and then automatically ban any wannabe intruder and completely block their IP address from ever reaching your system again. It's also good practice to use that.

All valid points.

Not to mention, that in the case of running SSH on two servers that are local to you, ensuring the port SSH is running on isn't open to the internet is also a good idea.

It shouldn't be exposed by default unless you are:
A) Running IPv6 with no Firewall (cuz everyone get a public IP)
B) Port Forwarding the SSH port on your router over IPv4 (cuz you are more likely than not behind NAT)
C) Connecting the machine directly to the internet with no firewall enabled.

If you use a strong password and not expose SSH to the internet at large, you are fine for 99% of things. If you want to be more secure, you can set up key-based authentication and then disable password authentication, so the connection cannot be brute forced via guessing passwords.

More info here:
https://www.digitalocean.com/communi...n-ubuntu-18-04

File permissions took a while for me to wrap my head around when I first started out - it's even worse if you take assumptions from the Windows world since Linux file permissions work in a completely different way from Windows permissions.
This guide should be pretty helpful:
https://www.linux.com/training-tutor...e-permissions/

[TheFu]

ssh key-based authentication is not just more secure. It is more convenient. I don't understand why everyone doesn't just use keys instead of passwords. Makes no sense to me. Being prompted once per login to unlock ssh keys, but having full access to all your systems over ssh, scp, sftp, rsync from that point until logout is crazy convenient.

[Old Jimma]

Thanks, Scorp123.

I'm giving this a try. Looks very promising.

Old