If you cannot securely copy a file to a remote server or log into a machine that is not in the same room as you, you cannot do the job of a Linux administrator. Hiring managers and exam writers for XK0-006 know this, which is why they test your ability to use remote access tools like SSH and file transfer tools like SCP and rsync. This chapter will teach you how to connect to a machine on the other side of the world, move files to it, and do it all safely – the exact skills you need to pass the exam and work in IT.
Jump to a section
A simple way to picture File Transfer and Remote Access
You work in a 37-storey office building. Your desk and your computer are on the 10th floor. To get in the building at all, you need to swipe your keycard at the main entrance. That is authentication – proving you are who you say you are. Without that card, you are stuck on the pavement outside.
Once you are inside the lobby, you cannot just walk into any office. You swipe your card again at the turnstile to access the stairwells and lifts. That swipe is authorisation – it tells the building which floors you are allowed to visit. Your card only opens floors 8 through 12, because that is where your team works. You cannot even press the button for floor 22.
Now suppose you need a legal document from a colleague on the 21st floor. You do not leave your desk. Instead, you slide the document into a pneumatic tube, seal it, and press ‘send’. The tube system carries the document up 11 floors and delivers it to your colleague’s mail slot. She can open the tube, read the document, sign it, and send it back down. That is remote access and file transfer – you accessed a resource on a different floor without walking there, and you moved a file between two locations over a secure path. The tube system is your SSH or SCP connection. The keycard is your username and password (or SSH key pair). And the building’s security rules are your network firewall and user permissions.
If you tried to use the stairs without a card, security would stop you at the door. If you put a confidential letter in an open tray, anyone could read it. The building’s rules – swiping, using the tube system, limiting floor access – are the exact same logic that IT professionals use every day to transfer files and log into remote servers safely.
File transfer and remote access are two of the most fundamental skills for any Linux system administrator. They allow you to log into computers that are not physically near you (remote access) and to copy files between those computers (file transfer). Before the internet and modern networks, an administrator had to sit at a physical terminal connected directly to the machine. Today, you can manage hundreds of servers from a single laptop in a coffee shop, provided you use the right tools and understand the security implications.
Let us start with remote access. The standard tool for remote access on Linux is SSH, which stands for Secure Shell. SSH is a protocol – a set of rules that two computers agree to use when communicating. When you run ‘ssh user@server-ip-address’, your computer (the client) asks the remote computer (the server) to let you log in. The server checks your identity. The most common way to prove your identity is with a password. However, passwords can be guessed or stolen, so SSH also supports a much stronger method: public-key authentication.
In public-key authentication, you generate two mathematically linked files: a private key (which you keep secret, like the key to your front door) and a public key (which you copy to any server you want to access, like giving the locksmith a copy of the key shape so they can make a lock that only your key fits). When you try to log in, the server sends a challenge that only someone holding your private key can answer. If you answer correctly, you are allowed in – without typing a password. This is far more secure and is the method used by professional infrastructure teams.
Once you are logged in remotely, you have a shell – a command-line interface – on the remote machine. You can run commands, edit files, start processes, and do almost anything you could do sitting at that computer’s keyboard. The traffic between your client and the server is encrypted, meaning anyone who intercepts it cannot read your commands or your data.
Now for file transfer. While you are logged in remotely, you might need to copy a file from your local machine to the server (upload) or from the server to your local machine (download). You could use SSH itself for this, but it is not efficient for large files. Instead, we use tools built on top of SSH that specialise in file transfer.
The simplest is SCP, which stands for Secure Copy. Its syntax is: ‘scp source-file user@server:/destination/path’. For example, ‘scp report.txt bob@192.168.1.10:/home/bob/documents/’ copies the file ‘report.txt’ from your current directory to the remote server’s directory. The data travels inside the same encrypted tunnel that SSH uses, so it is secure. SCP is quick and easy, but it has a limitation: if you try to copy a file that already exists at the destination, it overwrites it without checking. It also does not handle interrupted transfers – if the connection drops halfway through, you have to start from scratch.
A more powerful tool is rsync. Rsync stands for remote synchronisation. It was designed to copy only the differences between files, not the whole file every time. Imagine you have a 1-gigabyte video file on the remote server, and you changed just the filename on your local copy. With SCP, you would have to transfer the entire 1 GB again. With rsync, the tool compares the local and remote files block by block and transfers only the parts that changed – maybe just a few kilobytes. This makes rsync much faster and more efficient, especially for large files or frequent backups. The basic syntax is: ‘rsync -avz local-file user@server:/destination/path/’. The ‘-a’ flag (archive) preserves permissions, timestamps, and ownership. The ‘-v’ flag (verbose) shows progress. The ‘-z’ flag (compress) compresses data during transfer to save bandwidth.
A third tool, which you will also see on the exam, is FTP, or File Transfer Protocol. FTP is older than SSH and does not encrypt its traffic by default. That means anyone on the network can see your username, password, and the files you are transferring. Because of this, modern IT environments almost never use plain FTP. Instead, they use SFTP (SSH File Transfer Protocol) – sometimes called ‘Secure FTP’ – which is essentially FTP that runs inside an SSH connection. SFTP is different from FTPS (FTP over SSL), but for the exam, you just need to know that SFTP is the secure version that uses SSH.
All of these tools rely on the remote machine running a service (a background program) that listens for incoming connections. For SSH, that service is called ‘sshd’ (SSH daemon). The server must have sshd running and configured to accept connections. On many Linux systems, it is installed by default, but you can check with ‘systemctl status sshd’. The configuration file is usually at ‘/etc/ssh/sshd_config’. You can edit this file to change settings like which users are allowed to log in, whether password authentication is permitted, and which port the service listens on (default is port 22). Changing the port is a small security measure, but the exam expects you to know the default port.
In summary, secure remote access and file transfer are achieved through SSH and its related tools (SCP, rsync, SFTP). These tools provide encryption, authentication, and efficient data transfer. Without them, any file you copied over a network would be readable by anyone, and you would have to physically visit each machine to manage it. For the XK0-006 exam, you must be comfortable with the commands, the flags, and the security concepts behind them.
Generate an SSH Key Pair
Run ‘ssh-keygen -t rsa -b 4096’ on your local machine. This creates two files: ~/.ssh/id_rsa (the private key, keep it secret) and ~/.ssh/id_rsa.pub (the public key, which you will copy to servers). You can add a passphrase for extra protection.
Copy the Public Key to the Remote Server
Use the ‘ssh-copy-id’ command: ‘ssh-copy-id user@remote-server’. This appends your public key to the remote server’s ~/.ssh/authorized_keys file. Now you can log in without typing a password, using ‘ssh user@remote-server’.
Log into the Remote Server via SSH
Type ‘ssh -i ~/.ssh/id_rsa user@remote-server’. The -i flag specifies which private key to use (useful if you have multiple keys). You will get a shell prompt. Run commands as if you were physically at the machine.
Transfer a File Using SCP
From your local machine, run ‘scp localfile.txt user@remote-server:/path/’. The file is encrypted during transit. SCP is ideal for a one-off transfer but does not resume if the connection drops.
Synchronise a Directory Using Rsync
Run ‘rsync -avz /local/dir/ user@remote-server:/remote/dir/’. The trailing slash on the source means ‘copy the contents of the directory’. The -a flag preserves metadata, -v shows progress, -z compresses data. Rsync only transfers changed blocks, making it fast for ongoing backups.
Use SFTP for Interactive File Management
Type ‘sftp user@remote-server’ to start an SFTP session. Use commands like ‘get remotefile’ to download, ‘put localfile’ to upload, ‘ls’ to list files, and ‘exit’ to close. SFTP runs over SSH, so it is encrypted and does not require a separate FTP service.
Secure the SSH Server Configuration
Edit /etc/ssh/sshd_config on the server. Set ‘PermitRootLogin no’ to prevent direct root logins, set ‘PasswordAuthentication no’ to force key-based authentication, and consider changing ‘Port 22’ to a non-standard port like 2222. Restart the SSH service with ‘systemctl restart sshd’ to apply changes.
Imagine you are the sole Linux administrator for a small e-commerce company called ‘ShopFast’. The company has one web server that runs the main website, one database server that holds customer orders, and one backup server that stores nightly copies of everything. All three servers are in a data centre 200 miles away from your office. You never walk into that data centre. Instead, you manage everything from your laptop.
At 9:00 AM, you get an alert: the web server is running out of disk space. You need to log in and investigate. You open your terminal and type:
ssh -i ~/.ssh/shopfast-key.pem admin@webserver.shopfast.com
Here, ‘-i’ tells SSH which private key file to use. Your laptop has a private key; the server has a copy of the corresponding public key. Because you set up key-based authentication, you are logged in within two seconds without typing a password. You run ‘df -h’ to check disk usage and find that a log file called ‘access.log’ has grown to 50 GB. That is far too large. You decide to compress it, move it to the backup server, and then start a fresh log file.
First, you compress the file on the web server:
gzip /var/log/access.log
This creates a file called ‘access.log.gz’ that is now only 2 GB. Next, you need to copy it to the backup server. You use rsync because it will resume if the connection drops and it only transfers differences:
rsync -avz /var/log/access.log.gz admin@backup.shopfast.com:/backups/webserver/
The file transfers in about 30 seconds. You then clean up the original and restart the logging service. Without SSH and rsync, you would have had to drive 200 miles, plug a USB drive into the server, copy the file, and drive back. That would have taken four hours and cost the company hundreds of pounds in lost time.
Later that day, the marketing team asks you to update the product catalogue on the web server. They have prepared a CSV file with 10,000 new products. You need to upload it from your laptop to the web server. You use SCP because it is fast and simple for a one-time upload:
scp new-products.csv admin@webserver.shopfast.com:/var/www/html/products/
The file arrives in under a minute. Then you run a script on the server to import the CSV into the database. Finally, you use SFTP to download the latest database backup to your laptop so you can test a query locally:
sftp admin@dbserver.shopfast.com
Once the SFTP session starts, you can use commands like ‘get latest-db-dump.sql.gz’ to download the file, or ‘put my-test-file.txt’ to upload one. You close the session with ‘exit’.
At the end of the day, you review the backup server logs. Rsync ran automatically at 2 AM (via a cron job – a scheduled task) and copied all changed files from the web server and database server to the backup server. You check that the rsync succeeded by looking at the exit code. A non-zero exit code would mean it failed, and you would investigate. Everything is green.
This entire workflow – SSH for remote login, SCP for one-off file copies, rsync for repeated synchronisation, and SFTP for interactive file management – is exactly what a real Linux administrator does daily. In the exam, you will be asked to choose the right tool for a given scenario.
The XK0-006 exam will test your knowledge of file transfer and remote access in multiple-choice questions and performance-based scenarios (where you actually type commands). The exam writers want to ensure you can distinguish between similar tools, remember the correct syntax, and understand security implications. Here is exactly what you need to know.
First, you must memorise the default port numbers. SSH uses port 22. If a question asks which port to open in a firewall to allow remote access via SSH, the answer is 22. Do not confuse this with HTTP (80), HTTPS (443), or FTP (21). A common trap question gives you a scenario where an administrator changes the SSH port to 2222 in the configuration file; the correct answer would be that clients must now connect using ‘ssh -p 2222’.
Second, you must know the command syntax for SSH, SCP, and rsync cold. For SSH, the pattern is ‘ssh [options] [user@]host’. For SCP, the pattern is ‘scp [options] source destination’. For rsync, the pattern is ‘rsync [options] source destination’. If the source or destination is on a remote machine, you prefix it with ‘user@host:path’. Pay attention to the presence or absence of a trailing slash on directories – in rsync, a trailing slash on the source means ‘copy the contents of the directory’, while no trailing slash means ‘copy the directory itself’. This is a common exam nuance.
Third, the exam tests your understanding of SSH key-based authentication. You should know how to generate a key pair with ‘ssh-keygen -t rsa -b 4096’ (the type and bit length are not always tested, but know the command). You must know that the public key goes into ‘~/.ssh/authorized_keys’ on the server, and the private key stays on the client, never shared. A trap question might suggest putting the private key on the server to ‘simplify’ the setup – that is a security violation and the wrong answer.
Fourth, you must recognise the difference between SCP, rsync, SFTP, and FTP. The exam will present a scenario and ask which tool to use. For example, if the question says ‘an administrator needs to copy a large log file every hour and only wants to transfer the changed portions’, the correct answer is rsync. If it says ‘the administrator needs to securely transfer a single configuration file once’, SCP is the best choice. If it says ‘the administrator needs a shared file system accessible over SSH’, SFTP is correct. Plain FTP is almost always the wrong answer because it lacks encryption.
Fifth, the exam may test your knowledge of the SSH configuration file locations. The system-wide configuration is at ‘/etc/ssh/sshd_config’ (for the server) and ‘/etc/ssh/ssh_config’ (for the client). User-specific client configuration goes in ‘~/.ssh/config’. A question might ask where to set options like ‘PermitRootLogin no’ – that goes in the server’s sshd_config file. Traps: do not confuse sshd_config (server) with ssh_config (client).
Sixth, be aware of SSH connection multiplexing. While not heavily tested, you might see a scenario where an administrator wants to reuse an existing SSH connection to avoid repeated authentication. The relevant option is ‘ControlMaster’ in the client config. If it appears, the correct answer will involve setting up a control socket file.
Seventh, the exam loves to test the purpose of specific flags. For rsync, know ‘-a’ (archive), ‘-v’ (verbose), ‘-z’ (compress), ‘-n’ (dry run – simulates without actually transferring), and ‘--delete’ (deletes files at the destination that no longer exist at the source). For SCP, know ‘-P’ (note: capital P for SCP to specify port, whereas SSH uses lowercase -p). For SSH, know ‘-i’ (identity file), ‘-p’ (port), ‘-L’ (local port forwarding), and ‘-N’ (do not execute remote commands, used for port forwarding).
Eighth, performance-based questions may ask you to establish an SSH session and then transfer a file. In the exam environment, you will have to type the exact command. Practise typing ‘ssh username@hostname’, ‘scp file username@hostname:/path’, and ‘rsync -avz source username@hostname:/path’ until the syntax is automatic.
Finally, the exam will check your knowledge of securing SSH. This includes disabling root login (PermitRootLogin no), disabling password authentication (PasswordAuthentication no) to force key-based login, and changing the default port. Questions may ask which configuration directive achieves a specific goal – you must match the directive to its effect.
SSH uses port 22 by default; you must know that for the exam and firewall configuration.
SCP copies entire files every time and cannot resume interrupted transfers; use rsync for large or repeated transfers.
Rsync’s -a flag (archive) preserves permissions, timestamps, and ownership; combine it with -z to compress and -n to do a dry run before real transfers.
SSH key-based authentication requires the public key in ~/.ssh/authorized_keys on the server and the private key kept secret on the client.
SFTP (Secure FTP) runs over SSH and encrypts all traffic; plain FTP is unencrypted and should never be used in production.
Always disable root login via SSH (PermitRootLogin no) and consider disabling password authentication (PasswordAuthentication no) to force key-based logins for better security.
These come up on the exam all the time. Here's how to tell them apart.
SCP
Transfers entire file every time, even if only a few bytes changed
Cannot resume an interrupted transfer; restarts from scratch
Simpler syntax for one-time copies: scp source dest
Rsync
Transfers only changed blocks of files, saving bandwidth and time
Resumes from where it left off if the connection drops
More complex but powerful flags: -avz for archive, verbose, compress
FTP
Transmits usernames, passwords, and data in plain text
Uses separate ports 20 and 21 by default
Requires a separate FTP server (e.g., vsftpd) to be installed
SFTP
Runs entirely inside an encrypted SSH session
Uses only port 22 (same as SSH)
Built into the OpenSSH package; no extra server needed if SSH is running
SSH Password Authentication
Requires typing a password each time you connect
Password can be guessed or stolen via phishing
Easier for beginners to set up initially
SSH Key Authentication
No password needed after keys are configured; ideal for automation
Vastly more secure because the private key is never sent over the network
Requires initial key generation and public key distribution to each server
ssh (Remote Login)
Opens an interactive shell on the remote machine
Used to run commands, edit files, start processes
Can also be used for port forwarding with -L or -D flags
scp (Remote File Copy)
Does not open a shell; it only copies files
Used to transfer files without user interaction
Cannot be used to run remote commands
scp -P 2222
scp uses capital -P to specify a non-default port
If you forget the capital P, the command may fail or use default port 22
Syntax: scp -P 2222 file user@host:/path
ssh -p 2222
ssh uses lowercase -p to specify a non-default port
If you forget the lowercase p, the connection will attempt port 22 and likely fail
Syntax: ssh -p 2222 user@host
rsync --delete
Removes files at the destination that no longer exist at the source
Useful for exact mirroring of directories
Dangerous if used incorrectly; can delete important files
rsync without --delete
Keeps extra files at the destination that are not in the source
Ideal for incremental backups where you want to keep history
Safer for beginners because files are never removed automatically
Mistake
SCP and rsync are interchangeable; I can use whichever I remember.
Correct
SCP is best for one-time, simple copies. Rsync is designed for repeated transfers and only sends changed blocks, making it more efficient for backups and large files. They are not interchangeable in scenarios where speed or resumability matters.
Beginners often use the first tool they learn (usually SCP) for everything because the syntax seems easier. They do not realise that rsync saves time and bandwidth for regular transfers.
Mistake
FTP is secure enough for internal company use because the network is trusted.
Correct
FTP sends usernames, passwords, and data in plain text. Anyone on the same network (including a compromised device or a malicious insider) can read the traffic. Use SFTP (which runs over SSH) instead.
The word ‘internal’ gives a false sense of security. Many beginners believe that if the network is private, encryption is unnecessary. However, internal networks are often the source of breaches.
Mistake
When I generate SSH keys, I should put the private key in the authorized_keys file on the server.
Correct
The public key goes into the server’s ~/.ssh/authorized_keys file. The private key stays on the client machine and must never be shared. If the private key is on the server, anyone who compromises the server can impersonate the client.
The names ‘public’ and ‘private’ can be confusing. A beginner might think ‘the server needs my key, so I put both there’. This misconception is dangerous because it breaks the security model entirely.
Mistake
You cannot use SSH without a password.
Correct
SSH supports key-based authentication, which does not require a password. You generate a key pair (public and private), install the public key on the server, and authenticate using the private key. This is often more secure than passwords and can be used without any user interaction.
Many users first encounter SSH as ‘ssh user@host’ and are prompted for a password. They assume that is the only method. The idea of ‘passwordless’ login seems impossible to them, so they never explore key configuration.
Mistake
Rsync always transfers the entire file, just like SCP.
Correct
Rsync computes a checksum of blocks on both the source and destination and transfers only the blocks that are different. For a file that already exists on the destination with minor changes, rsync transfers only a fraction of the data, making it much faster than SCP.
The name ‘rsync’ contains ‘sync’, which beginners misinterpret as ‘make them identical by copying everything’. They do not understand the block-level diffing algorithm that makes rsync powerful.
Reveal each answer, then mark whether you got it right. Score 60%+ to unlock the next chapter.
SSH (Secure Shell) is used for logging into a remote machine and running commands. SCP (Secure Copy) is built on SSH but is used only for transferring files between machines. You cannot run commands with SCP; you can only copy files.
Use rsync instead of SCP. Rsync compares the source and destination and only transfers the parts that are missing or changed. If the connection drops, running the same rsync command again will continue from where it left off, not start over.
Use ‘scp user@remote-server:/path/to/file /local/path/’. For example: ‘scp bob@192.168.1.10:/home/bob/report.txt ./’ downloads report.txt to your current directory. Rsync works the same way: ‘rsync -avz bob@192.168.1.10:/home/bob/report.txt ./’.
No. FTP (File Transfer Protocol) sends data and credentials in plain text. SFTP (SSH File Transfer Protocol) is a completely different protocol that runs inside an SSH connection, encrypting everything. SFTP is secure; FTP is not.
Run ‘ssh-keygen -t rsa -b 4096’ in your terminal. You can press Enter to accept the default file location (~/.ssh/id_rsa). Optionally, add a passphrase for extra security. The corresponding public key will be in ~/.ssh/id_rsa.pub.
The first time you run rsync, there is no existing copy on the destination, so it must transfer the entire file. On subsequent runs, rsync compares checksums of small blocks and only transfers blocks that changed, which is usually a tiny fraction of the total file size.
Yes, use SCP or rsync, which use the SSH protocol for the data transfer but do not give you an interactive shell. This is useful for scripting automated backups or deployments.
You've finished File Transfer and Remote Access. Continue through the XK0-006 study guide to build a complete picture of the exam.
Done with this chapter?