Skip to main content

Using SSH, Redirection, and Permissions in Linux

Hands-On Lab

 

Photo of Rob Marti

Rob Marti

Linux Training Architect I in Content

Length

00:30:00

Difficulty

Intermediate

In this lab we’re going to go over I/O redirection, file permissions, and using the ssh tool. These are skills that will serve you well in your career as a Linux sysadmin. Once complete you’ll have a solid understanding of how to use these tools.

What are Hands-On Labs?

Hands-On Labs are scenario-based learning environments where learners can practice without consequences. Don't compromise a system or waste money on expensive downloads. Practice real-world skills without the real-world risk, no assembly required.

Using SSH, Redirection, and Permissions in Linux

The Scenario

We need to set up a new server for a developer to use. He needs to be able to connect with ssh from server1 to server2 as the dev user, without having to enter a password.

Once that's set up there are some tar files on server1 that need to be copied over and extracted. To enable the developer to verify that it was done correctly, we should have all the output from the extraction go to /home/dev/tar-output.log.

We need to make sure that new files have the correct permissions (readable and writable by only the user) by setting the umask correctly.

Once complete we should verify permissions on the very important /home/dev/deploy.sh script and run it.

The password for the user dev is the same as for cloud_user.

Get logged in

Use the credentials and server IP in the hands-on lab overview page to log into our lab server. Once we're in, we can get moving.

Enable SSH to Connect Without a Password from the dev User on server1 to the dev User on server2

We need to use SSH keys to satisfy this requirement, so generate them with this:

[user@server1]$ ssh-keygen

Then run:

[user@server1]$ ssh-copy-id <server2 IP>

Now if we try to log into server2 without a password, it should work. Try it:

[user@server1]$ ssh <server2 IP>

And then get back out again:

[user@server2]$ exit

Copy All tar Files Rrom /home/dev/ on server1 to /home/dev/ on server2

We need to use a method of copying files over a network. scp is the best tool. Use i like this:

[user@server1]$ scp *.gz <server2 IP>:~/

Then connect to server2 again:

[user@server1]$ ssh <server2 IP>

Make sure they're here with this:

[user@server2]$ ll

It should show the two files.

Extract the Files, Making Sure the Output is Redirected

Then we can extract the files:

[user@server2]$ tar -xvf deploy_content.tar.gz >> tar-output.log
[user@server2]$ tar -xvf deploy_script.tar.gz >> tar-output.log

Make sure to use >>, so that the log output is appended rather than overwritten.

Set the Umask So That New Files Are Only Readable and Writeable by the Owner

If we look at what's in the directory now (with ll) we'll see the new files and their permissions. The task is asking to make new files with 0600 (-rw-------) permissions.

We can do some subtraction to figure out what our umask should be:

0666 <-- Default

0600 <-- Desired

----

0066 <-- What we need to set

So we run:

[user@server2]$ umask 0066

Verify the /home/dev/deploy.sh Script Is Executable and Run It

First we check permissions on deploy.sh:

[user@server2]$ ls -l deploy.sh
-rw-r--r--. 1 dev dev 151 Mar 27 15:11 deploy.sh

There's no execute bit. Let's add one:

[user@server2]$ chmod +x deploy.sh

And then run it:

[user@server2]$ ./deploy.sh

Conclusion

Well, we set up a new server for the developer, rigged things up so that he doesn't have to use a password with SSH, and we also set a umask so that files will have -rw------- permissions; only the files owner will be able to read or write.

We're done. Congratulations!