Cvičení: 1, 2, 3, 4, 5, 6, 7, 8, 9, 10, 11, 12, 13, 14.
V tomto cvičení si rychle osvěžíme principy fungování sítě a asymetrickou kryptografii. Pak začneme používat SSH: způsob, jak pracovat v shellu na vzdáleném Linuxovém stroji. Také budeme trochu mluvit o přístupových právech na Linuxových strojích, protože jsou pro nás důležité při práci na sdílených počítačích.
Podíváme se i na základní síťové utility, které nám umožní číst konfiguraci sítě a ladit problémy s konektivitou.
Nezapomeňte, že Čtení před cvičením je povinné a je z něj kvíz, který musíte vyplnit před cvičením.
Tohle je čtení před sedmým cvičením.
Using SSH
Using SSH is very simple (unless you make it complex). To SSH to a remote machine, you need to know your credentials (i.e., login name and a password) and, of course, the name of the remote machine.
Then simply execute the following:
ssh YOUR_LOGIN@REMOTE_MACHINE_NAME
Note that the command ssh is often called a SSH client as it connects to
the SSH server (similar to curl or wget being web clients connecting to
a web server).
We have set up a remote machine for you on linux.ms.mff.cuni.cz. You will
be using your GitLab (SIS/CAS) login and also the same password.
ssh YOUR_SIS_LOGIN@linux.ms.mff.cuni.cz
The first login to the machine is a bit more complicated. SSH client wants from you a verification that you trust the remote server. It shows you a so-called server fingerprint:
The authenticity of host 'linux.ms.mff.cuni.cz (195.113.20.170)' can't be established.
ECDSA key fingerprint is SHA256:ltoc1TjoYhCZk6b8qSTAL6wFsRv7blw6u3h6NqCcYvI.
Are you sure you want to continue connecting (yes/no/[fingerprint])?
Based on your configuration, RSA or ED25519 key may be used instead:
RSA: SHA256:Z11Qbd6nN6mVmCSY57Y6WmxIJzqEFHFm47ZGiH4QQ9Y
ED25519: SHA256:/CVwDW388z6Z5VlhLJT0JX+o1UzakyQ+S01+34BI0BA
You should have received this fingerprint in a secure way before connecting to the server (for example, printed from your employer etc.). In this case, we hope that a potential attacker would not be able to break both into this web server and the SSH server at once. So we use the HTTPS protocol on the web as a secure way of verifying the SSH server.
The program then continues to ask your for a password and also informs you that the fingerprint was stored.
On following logins, the SSH client checks that the fingerprint has not changed. A changed fingerprint belonging to the same machine (i.e., with the same DNS name) could indicate a man-in-the-middle attack. Do not connect when the fingerprint has changed. Always contact the administrator (e.g., the teachers in this particular case) and check with him what is happening.
If you were able to log-in, you will see an (almost) empty $HOME and
otherwise a normal Linux machine, this time without any graphical
applications installed.
Note that this machine is shared for all students of this course. Use it to solve graded tasks or to experiment with commands we show in the labs. Do not use it for computationally intensive tasks or other tasks that are not related to this course. If we encounter any form of abusive use, we will block the offending account.
Using machines in Rotunda
Apart from the machine linux.ms.mff.cuni.cz, there is also a full lab of
machines available in the Rotunda computer lab on Malostranské náměstí.
All the Linux machines in the lab are also reachable via SSH. Again, use
your SIS credentials to log in. Note that all machines in Rotunda (but not
linux.ms.mff.cuni.cz!) share the same $HOME, i.e., it does not matter
which one you physically connect to. Your files will be available on all
machines.
Unfortunately, the used file system and authentication mechanism does not
allow to use public key authentication for Rotunda machines. You need to
always specify your password. (linux.ms.mff.cuni.cz does not have this
limitation and we expect you will use public key authentication there.)
Following machines are available.
- Lab SU1
u1-1.ms.mff.cuni.czu1-2.ms.mff.cuni.cz- …
u1-14.ms.mff.cuni.cz
- Lab SU2
u2-1.ms.mff.cuni.czu2-2.ms.mff.cuni.cz- …
u2-25.ms.mff.cuni.cz
- Rotunda
u-pl1.ms.mff.cuni.czu-pl2.ms.mff.cuni.cz- …
u-pl23.ms.mff.cuni.cz
Using SSH to run one command
The command ssh is actually quite powerful and configurable. One
important feature is that you can specify a command after the hostname and
run this command directly. In this case, SSH never starts an interactive
shell on the remote machine, but executes only the given command and
returns.
Following commands prints uname -r on the remote machine.
ssh user@hostname uname -r
Investigate how (and why) the following command behaves differently.
ssh user@hostname uname -r >local_file.txt
ssh user@hostname "uname -r >remote_file.txt"
To verify that you are on a different machine, run on both uname -a and
hostname -f (it provides the full DNS name of the current machine).
Can you see the differences?
You can also trying checking free -h or uptime.
SSH and passwordless authentication
To enable authentication with public key over SSH, we need to perform two steps. Generate the public-private key pair and copy the public key to the remote machine.
To generate the public key we need to run the following command (the -C is
actually a comment, providing e-mail or your login is the usual approach but
keeping it empty is possible too).
ssh-keygen -t ed25519 -C "your_email@example.com"
The program would ask us where to store the generated private and public
key. Keep the defaults. Choose if you want a passphrase or not (it is more
secure to have one, but the use is a bit more cumbersome). After
ssh-keygen finishes, check that the directory ~/.ssh contains
id_ed25519 (the private key) and id_ed25519.pub (the public key).
Feel free to inspect their content. Surprised that they are text files?
Once we have the public key ready, we need to upload it to the remote
machine. If you have multiple key pairs, read about the -i switch.
ssh-copy-id LOGIN@REMOTE_MACHINE
If you log in to the remote machine again, the SSH client should use the key
pair and log you in without asking for a password. If not, run SSH with
-vvv to debug the issue.
Note that the public key was stored into ~/.ssh/authorized_keys file on
the remote machine. You can copy it there manually but using ssh-copy-id
is easier.
Update if the copying fails with cryptic message about
warning: here-document at line 251 delimited by end-of-file (wanted EOF),
try upgrading the SSH client first.
If you use the image from us, simple sudo dnf upgrade openssh-clients
should work.
SSH configuration
The SSH client is configured via the ~/.ssh/config file. Review the
syntax of this file via man 5 ssh_config.
The file is divided into sections. Each section is related to one or more
remote hosts. The section header is in the format Host pattern, where
pattern might use wildcards.
The syntax is mostly self-explanatory, so we will only provide an example.
Host *
IdentityFile ~/.ssh/id_ed25519
Host intro
Hostname linux.ms.mff.cuni.cz
User YOUR_SIS_LOGIN
Host mff1
Hostname u-pl6.ms.mff.cuni.cz
User YOUR_SIS_LOGIN
Host mff2
Hostname u-pl17.ms.mff.cuni.cz
User YOUR_SIS_LOGIN
With this ~/.ssh/config, we can type ssh intro and the ssh will start
connection equivalent to
ssh YOUR_SIS-LOGIN@linux.ms.mff.cuni.cz
We recommend to use different u-pl* hostnames in your config to distribute
the load across multiple machines. Note that the Rotunda machines may be
unevenly loaded, so it is a good idea to bookmark several of them and
re-login if the first one is too slow.
Copying files
SCP
In order to copy files between two Linux machines, we can use scp.
Internally, it establishes a SSH connection and copies the files over it.
The syntax is very simple and follows the semantics of a plain cp:
scp local_source_file.txt user@remote_machine:remote_destination_file.txt
scp user@remote_machine:remote_source_file.txt local_destination_file.txt
Rsync
A much more powerful tool for copying of files is rsync. Similarly to
scp, it runs over a SSH connection, but it has to be installed at both
sides. It can copy whole directory trees, handle symlinks, access rights,
and other file attributes. It can also detect that some of the files are
already present at the other side (either exactly or approximately) and
transfer just the differences.
The syntax of a simple copy follows cp and scp, too:
rsync local_source_file.txt user@remote_machine:remote_destination_file.txt
rsync local_source_file.txt user@remote_machine:remote_destination_directory/
File managers
Many file managers allows you to open a SCP-style connection transparently and copy between machines with the same ease as when working with local files.
For example, in mc, select Shell connection either in left or right
panel and specify SSH connection. One of the panels will show the files on
the remote machine. Try using F5 to copy files interactively.
Git přes SSH
To actually use Git over SSH, we first need to tell GitLab about our SSH keys (recall the protocol that is used to authenticate the user).
GitLab and SSH keys
Copy your public key to GitLab. Navigate to right-top menu with your avatar, select Preferences and then SSH keys or visit this link.
Copy your public key there and name it. Typically, the name should mention your username and your machine. Note that GitLab will send you an e-mail informing you about a new key. Why? Hint. Answer.
Go to your project and clone it again. This time, use the Clone with SSH URL.
git clone git@gitlab.mff.cuni.cz:teaching/nswi177/2022/student-LOGIN.git
Have you noticed that this looks like SSH/SCP address? It actually is
exactly that. The first part identifies the machine and the user (git)
and after a colon is a local path.
You can clone this way a Git directory from any SSH server by specifying its remote path there (here, GitLab does some mangling but the principle holds).
Note that the user we clone with is git – not you.
This way, GitLab needs only one physical user account for handling Git requests
and distinguishes the users via their public keys.
How?
Answer.
By the way, what happens if you try to run the following?
ssh git@gitlab.mff.cuni.cz
Note that you should use the SSH protocol for working with Git as it is much more comfortable for use. Note that Git on other platforms also offers generation of an SSH key but often the key is usable only by one application (different applications have incompatible key formats), while on Linux a single key is a generally usable for Git, other machines, and other services.
More about access rights
Let’s return a little bit to the access rights.
Change permission of some of your scripts to be --x.
Try to execute them.
What happens?
Answer.
Remove writable bit for a file and write to it using stdout redirection. What happens?
Reading network configuration
For the following text we will assume your machine is connected to the Internet (this includes your virtualized installation of Linux).
The basic command for setting and reading network configuration is ip.
Probably the most useful one is ip addr.
1: lo: <LOOPBACK,UP,LOWER_UP> mtu 65536 qdisc noqueue state UNKNOWN group default qlen 1000
link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
inet 127.0.0.1/8 scope host lo
valid_lft forever preferred_lft forever
inet6 ::1/128 scope host
valid_lft forever preferred_lft forever
2: enp0s31f6: <NO-CARRIER,BROADCAST,MULTICAST,UP> mtu 1500 qdisc fq_codel state DOWN group default qlen 1000
link/ether 54:e1:ad:9f:db:36 brd ff:ff:ff:ff:ff:ff
3: wlp58s0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc noqueue state UP group default qlen 1000
link/ether 44:03:2c:7f:0f:76 brd ff:ff:ff:ff:ff:ff
inet 192.168.0.105/24 brd 192.168.0.255 scope global dynamic noprefixroute wlp58s0
valid_lft 6209sec preferred_lft 6209sec
inet6 fe80::9ba5:fc4b:96e1:f281/64 scope link noprefixroute
valid_lft forever preferred_lft forever
8: vboxnet0: <BROADCAST,MULTICAST> mtu 1500 qdisc noop state DOWN group default qlen 1000
link/ether 0a:00:27:00:00:00 brd ff:ff:ff:ff:ff:ff
It lists four interfaces (lo, enp0s31f6, wlp58s0 and vboxnet0) that
are available on the machine. Your list will differ as well as the naming.
The name signifies interface type.
lois the loopback device that will be always present. With loopback device, you can test network applications even without having a “real” connectivity.enp0s31f6(often alsoeth*) is a wired ethernet.wlp58s0is a wireless adapter.vboxnet0is a virtual network card used by VirtualBox when you create a virtual subnet for your virtual machines (you will probably not have this one there).
The state of the interface (up and running or not) is at the same line as the adapter name.
The link/ denotes the MAC address of the adapter. Lines with inet
specify the IP address assigned to this interface, including the network.
In this example, lo has 127.0.0.1/8 (obviously), enp0s31f6 is without
an address (state DOWN) and wlp58s0 has address 192.168.0.105/24
(i.e., 192.168.0.105 with netmask 255.255.255.0).
Your addresses will be slightly different, but typically you will see also a private address (behind a NAT), as you are probably connecting through a router to your ISP.
Basic networking utilities
We will not substitute the networking courses here, but we mention two most important and useful commands that could help you debug basic network-related problems.
ping (a.k.a. are you there?)
The ping command is the basic tool to determine whether a machine with a
given IP address is up (and responding to a network traffic).
The usage is extremely simple: you tell it the DNS name (or IP address) of the machine you wish to connect to and it starts sending packets. Typically, the session looks like this:
ping d3s.mff.cuni.cz
PING d3s.mff.cuni.cz (195.113.20.60) 56(84) bytes of data.
64 bytes from d3s.mff.cuni.cz (195.113.20.60): icmp_seq=1 ttl=50 time=16.8 ms
64 bytes from d3s.mff.cuni.cz (195.113.20.60): icmp_seq=2 ttl=50 time=14.9 ms
64 bytes from d3s.mff.cuni.cz (195.113.20.60): icmp_seq=3 ttl=50 time=15.0 ms
64 bytes from d3s.mff.cuni.cz (195.113.20.60): icmp_seq=4 ttl=50 time=36.1 ms
64 bytes from d3s.mff.cuni.cz (195.113.20.60): icmp_seq=5 ttl=50 time=14.3 ms
64 bytes from d3s.mff.cuni.cz (195.113.20.60): icmp_seq=6 ttl=50 time=15.0 ms
^C
--- d3s.mff.cuni.cz ping statistics ---
6 packets transmitted, 6 received, 0% packet loss, time 5271ms
rtt min/avg/max/mdev = 14.328/18.688/36.068/7.809 ms
By default, ping will send the ICMP packet forever, you can terminate it
with Ctrl-C.
If the machine is not reachable (that might mean a problem anywhere on the route or on the destination machine itself), you will get behavior like in the following examples.
ping: connect: Network is unreachable
PING 195.113.20.60 (195.113.20.60) 56(84) bytes of data.
From 192.168.88.1 icmp_seq=1 Destination Net Prohibited
From 192.168.88.1 icmp_seq=2 Destination Net Prohibited
From 192.168.88.1 icmp_seq=3 Destination Net Prohibited
From 192.168.88.1 icmp_seq=4 Destination Net Prohibited
^C
--- 195.113.20.60 ping statistics ---
5 packets transmitted, 0 received, +4 errors, 100% packet loss, time 4042ms
pipe 3
ping is the basic tool if you suddenly lose a connection to some server.
Ping the destination server and also some other well-known server. If the
packets are going through, you know that the problem is on a different
layer. If only packets to the well-known server gets through, the problem
is probably with the server in question. If both fail, your network is
probably down.
traceroute (a.k.a. the path is the goal)
Sometimes, it can be handy to know the precise path, which the packets
travel. For this kind of task, we can use traceroute.
Similarly to ping, we need to just specify the destination.
traceroute 1.1.1.1
traceroute to 1.1.1.1 (1.1.1.1), 30 hops max, 60 byte packets
1 _gateway (10.16.2.1) 2.043 ms 1.975 ms 1.948 ms
2 10.17.0.1 (10.17.0.1) 1.956 ms 1.971 ms 1.961 ms
3 gw.sh.cvut.cz (147.32.30.1) 1.947 ms 1.973 ms 1.977 ms
4 r1sh-sush.net.cvut.cz (147.32.252.238) 2.087 ms 2.262 ms 2.527 ms
5 r1kn-konv.net.cvut.cz (147.32.252.65) 1.856 ms 1.849 ms 1.847 ms
6 kn-de.net.cvut.cz (147.32.252.57) 1.840 ms 1.029 ms 0.983 ms
7 195.113.144.172 (195.113.144.172) 1.894 ms 1.900 ms 1.885 ms
8 195.113.235.99 (195.113.235.99) 4.793 ms 4.748 ms 4.723 ms
9 nix4.cloudflare.com (91.210.16.171) 2.264 ms 2.807 ms 2.814 ms
10 one.one.one.one (1.1.1.1) 1.883 ms 1.800 ms 1.834 ms
The first column corresponds to the hop count. The second column represents
the address of that hop and after that, you see three space-separated times
in milliseconds. traceroute command sends three packets to the hop and
each of the time refers to the time taken by the packet to reach the hop. So
from the foregoing output we can see that the packages visited 10 hops on
its way between the local computer and the destination.
This tool is especial useful, when you have network troubles and you are not sure where the issue is.
traceroute to 1.1.1.1 (1.1.1.1), 30 hops max, 60 byte packets
1 10.21.20.2 (10.21.20.2) 0.798 ms 0.588 ms 0.699 ms
2 10.21.5.1 (10.21.5.1) 0.593 ms 0.506 ms 0.611 ms
3 192.168.88.1 (192.168.88.1) 0.742 ms 0.637 ms 0.534 ms
4 10.180.2.113 (10.180.2.113) 1.696 ms 4.106 ms 1.483 ms
5 46.29.224.17 (46.29.224.17) 14.343 ms 13.749 ms 13.806 ms
6 * * *
7 * * *
8 * * *
9 * * *
10 * * *
11 * * *
12 * * *
13 * * *
14 * * *
15 * * *
16 * * *
17 * * *
18 * * *
19 * * *
20 * * *
21 * * *
22 * * *
23 * * *
24 * * *
25 * * *
26 * * *
27 * * *
28 * * *
29 * * *
30 * * *
From this log we can see that the last visited hop was 46.29.224.17, so we
can focus our attention to this network element.
Hodnocené úlohy (deadline: 10. dubna)
Vzdálený soubor ~/LAB07 (25 bodů)
Vytvořte běžný soubor LAB07 ve svém domovském adresáři na
linux.ms.mff.cuni.cz. Jako jeho jediný obsah použijte své UKČO (číslo ze
svého ISICu).
Nevytvářejte tento soubor v GitLabu, budeme jej ověřovat jen na
linux.ms.mff.cuni.cz.
Nahrání našeho klíče (25 bodů)
Přidejte následující veřejný klíč mezi autorizované klíče u svého účtu na
linux.ms.mff.cuni.cz. Splnění úlohy ověříme tak, že se připojíme přes SSH
na linux.ms.mff.cuni.cz pod vaším uživatelským jménem a tímto klíčem.
ssh-ed25519 AAAAC3NzaC1lZDI1NTE5AAAAIPuoJJldIS6zOxunFxIFGk6tQlw0qpYSOxHYs57117o/ teachers-nswi177@d3s.mff.cuni.cz
Nevytvářejte tento soubor v GitLabu, budeme jej ověřovat jen na
linux.ms.mff.cuni.cz.
07/key.pub (25 bodů)
Uložte svůj veřejný klíč do tohoto souboru.
Neztraťte přístup k jeho soukromé části – budete ji potřebovat pro některé pozdější úlohy.
07/file.txt (25 bodů)
Spusťte příkaz nswi177-lab07 na linux.ms.mff.cuni.cz.
Vložte jeho výstup do tohoto souboru.
Učební výstupy
Znalosti konceptů
Znalost konceptů znamená, že rozumíte významu a kontextu daného tématu a jste schopni témata zasadit do většího rámce. Takže, jste schopni …
-
vysvětlit základní principy síťové komunikace (bez ohledu na OS/zařízení)
-
vysvětlit principy asymetrické kryptografie
-
vysvětlit, jak se dá použít asymetrická kryptografie pro autentizaci uživatele
-
vysvětlit výhody použití Gitu přes SSH (namísto HTTPS)
-
vysvětlit, jaká jsou základní přístupová práva na Unixu a co znamená rwx pro běžné soubory a pro adresáře
-
vysvětlit sticky bit
-
vysvětlit rozdíl mezi vlastnictvím souboru (skriptu) a běžícího programu
-
vysvětlit, co je POSIX ACL, jen základní přehled (volitelné)
Praktické dovednosti
Praktické dovednosti se obvykle týkají použití daných programů pro vyřešení různých úloh. Takže, dokážete …
-
použít SSH na přihlášení se ke vzdálenému stroji
-
spouštět příkazy na vzdáleném stroji
-
používat příkazy
unameahostname -
nastavit SSH zkratky (volitelné)
-
použít SCP na kopírování souborů mezi místním a vzdáleným počítačem
-
nastavit přihlašování bez hesla na vzdáleném Linuxovém stroji
-
nastavit autentizaci veřejným klíčem na GitLabu
-
používat Git přes SSH
-
zobrazovat a měnit unixová oprávnění
-
používat
ipna dotazování aktuální síťové konfigurace (jejího stavu) -
používat utility
pingatraceroute -
používat
tmux(volitelné) -
používat
rsync(volitelné)