Chapter 4: Bashrc, SSH and Remote Workflows¶

Source slides: V02.1_Linux_SSH_bashrc_2025.pdf (full lecture). This chapter also closes the basic-Linux topics: pipes vs redirection, job control, environment variables, aliases, functions, prompt customisation, encryption, SSH, scp, rsync, sftp, sshfs, port-forwarding.

1. Chapter Overview¶

Once you can use Linux locally, the next step in HPC is using Linux remotely — that is what every cluster login is. This chapter contains three closely related families:

Shell environment customization — .bashrc, environment variables (PATH, EDITOR), aliases, functions, prompt (PS1).
Job control — &, Ctrl-Z, bg, fg, jobs, nohup, tmux, screen.
Remote workflows — symmetric / asymmetric encryption, SSH (ssh, ssh-keygen, ssh-copy-id, ~/.ssh/config), file transfer (scp, rsync, sftp, sshfs), and port forwarding.

Why it matters in HPC/CFD: every minute you spend on a cluster goes through SSH. Knowing key-based auth, rsync with -avz, and tmux is the difference between productive HPC work and frustration.

What the examiner asks (very high frequency in the written exam):

"Difference between symmetric and asymmetric encryption."
"Explain the SSH passwordless authentication procedure."
"Compare scp, rsync, sftp, sshfs."
"What does ssh -L 8080:localhost:80 user@host do?"
"Write a ~/.bashrc snippet for an alias and a function."
"Difference between >, |, 2>, 2>&1."
"What is nohup? When do we need it?"

What you must master for top grade:

A flow chart of SSH login + key exchange + symmetric session.
The standard one-liner: ssh-keygen -t ed25519 -b 4096 -f ~/.ssh/cluster.
rsync -avz vs scp -r.
~/.ssh/config block.
Port forwarding direction (-L local, -R remote, -D dynamic).
.bashrc vs .bash_profile vs .profile.
The nohup ./run.sh > out.log 2>&1 & idiom.

2. Basics from Zero¶

Imagine you have a powerful cluster sitting in a data centre and a small laptop in front of you. You never sit at the cluster: you connect to it through the network. The simplest, safest way to do that is SSH ("Secure Shell"). Once connected, your terminal becomes the cluster's terminal — but only after the connection is encrypted.

The encryption itself is built from two ideas:

Symmetric encryption — one key locks and unlocks. Fast, but how do you give the key to the other side without an attacker reading it?
Asymmetric encryption — two keys, public + private. The public key locks, only the private key unlocks. Slow, but solves the key-exchange problem.

SSH does both: asymmetric just at the start to agree on a shared secret, then symmetric for the rest of the session. That's why SSH is "fast and secure".

বাংলায়: Symmetric encryption-এ একটাই key — দ্রুত কাজ করে, কিন্তু সমস্যা হলো সেই key-টা অন্য পক্ষের কাছে নিরাপদে পৌঁছাবে কীভাবে? Asymmetric encryption-এ public আর private দুটো key থাকায় key পাঠানোর সমস্যাটাই উধাও হয়ে যায়, কিন্তু এটা অনেক ধীর। SSH চালাকি করে দুটোই ব্যবহার করে: শুরুতে asymmetric দিয়ে একটা shared secret ঠিক হয়, তারপর পুরো session চলে দ্রুত symmetric AES দিয়ে। পরীক্ষায় "SSH fast and secure কেন" এলে এই দুই-ধাপের গল্পটাই লিখবে।

Once you log in, all your work happens in bash — but bash gets boring fast unless you customize it. That's the role of .bashrc, the file bash reads at the start of every interactive session. There you put aliases (alias ll='ls -la'), functions (mkcd() { mkdir -p "$1" && cd "$1"; }), environment variables (export PATH=$PATH:~/bin), and the prompt string (PS1=...).

বাংলায়: .bashrc হলো সেই ফাইল যেটা bash প্রতিটা interactive shell শুরুর সময় নিজে নিজে পড়ে — মানে এখানে যা লিখবে (alias, function, PATH, prompt) তা প্রতিবার নতুন টার্মিনালে অটোমেটিক চালু হয়ে যাবে। ফাইলটা এডিট করার পর সাথে সাথে কাজে লাগাতে চাইলে source করতে হয়, নাহলে নতুন shell খোলার আগ পর্যন্ত পরিবর্তন দেখা যাবে না। পরীক্ষায় ".bashrc snippet লেখো" খুব common প্রশ্ন।

When jobs take long you use job control: & runs in the background, Ctrl-Z suspends, fg resumes, nohup lets it survive after logout, tmux keeps the entire shell alive between disconnects.

বাংলায়: Cluster থেকে logout করলে shell-এর child process-গুলো SIGHUP signal পেয়ে মারা যায় — তাই ১০ ঘণ্টার simulation শুধু & দিয়ে চালিয়ে ল্যাপটপ বন্ধ করলে সকালে দেখবে job মরে গেছে। nohup দিলে process-টা SIGHUP উপেক্ষা করে, আর tmux ব্যবহার করলে পুরো shell session-টাই সার্ভারে বেঁচে থাকে — পরদিন attach করলেই যেখানে ছিলে ঠিক সেখানে ফিরবে। পরীক্ষায় "job survives logout" প্রশ্নে দুটো উপায়ই লিখবে।

To move data, you use scp (basic copy), rsync (smart, incremental copy), sftp (interactive), or sshfs (mount remote dir as if local).

Real-life analogy.

Symmetric crypto = one shared key for a padlock. Fast but need to hand the key over safely.
Asymmetric crypto = a slot for letters in a door + a key inside. Anyone can drop a letter in (public), only the owner reads (private).
SSH = embassy with an armoured pipe plus a personal vault.
.bashrc = your "office shortcuts" you stick on the wall every morning.
tmux = remote computer "freeze frame" — disconnect, reconnect, work continues.

What if you misunderstand?

Wrong permissions on ~/.ssh/id_* (e.g. 644 instead of 600) → SSH refuses the key.
Forget nohup ... & → close laptop lid, the simulation dies.
rsync src dst (forgot trailing slash) → you copy the directory itself instead of its contents and end up with dst/src/... instead of dst/....

3. Hard English Made Easy¶

Hard Term	Simple English	বাংলা	Example
Environment variable	Named value visible to processes	প্রসেসের কাছে দৃশ্যমান নামযুক্ত মান	`export PATH=...`
Alias	Shortcut for a longer command	দীর্ঘ কমান্ডের সংক্ষিপ্ত নাম	`alias ll='ls -la'`
Shell function	Reusable named block of shell code	পুনঃব্যবহারযোগ্য শেল ফাংশন	`mkcd(){...}`
Prompt (PS1)	What the shell shows before each command	শেলের ইনপুট চিহ্ন	`\u@\h:\w$`
Source / dot-script	Run script in current shell, not subshell	বর্তমান শেলে স্ক্রিপ্ট চালানো	`source ~/.bashrc`
Background job	Process running while shell continues	পেছনে চলমান প্রসেস	`./run.sh &`
Nohup	"No Hang-Up" — survives logout	লগআউটের পরেও চলে	`nohup ./run.sh &`
Terminal multiplexer	Lets one terminal hold many sessions	একাধিক শেল সেশন	`tmux`, `screen`
Symmetric encryption	Same key encrypts and decrypts	একই কী এনক্রিপ্ট-ডিক্রিপ্ট করে	AES
Asymmetric encryption	Public+private key pair	পাবলিক+প্রাইভেট কী জোড়া	RSA, Ed25519
Public key	Shareable lock	শেয়ারযোগ্য তালা	`id_ed25519.pub`
Private key	Secret unlock	গোপন কী	`id_ed25519`
Key exchange	Both sides agree a shared secret	দুইপক্ষ গোপন কী তৈরি করে	Diffie–Hellman
Authentication	Proving who you are	পরিচয় প্রমাণ	SSH key
Cipher	The actual algorithm	এনক্রিপশন আলগরিদম	AES-256
SSH	Secure Shell — encrypted remote login	নিরাপদ রিমোট শেল	`ssh user@host`
Tunnel	Encrypted forwarded port	এনক্রিপ্টেড পোর্ট ফরওয়ার্ডিং	`ssh -L 9000:localhost:80`
`scp`	Secure file copy over SSH	এসএসএইচ-এর মাধ্যমে কপি	`scp a host:/b`
`rsync`	Sync that copies only differences	শুধু পরিবর্তিত অংশ কপি	`rsync -avz`
`sftp`	FTP-like interactive file transfer over SSH	সিকিউর FTP	`sftp host`
`sshfs`	Mount remote dir as local FS	রিমোট ফোল্ডার লোকাল মাউন্ট	`sshfs h:dir mnt`
Port	Network endpoint number	নেটওয়ার্ক পোর্ট	TCP/22
Loopback	The host itself	নিজের কাছে ফিরে	127.0.0.1
Host	A computer on a network	নেটওয়ার্ক কম্পিউটার	`host01`

4. Deep Theory Explanation¶

4.1 Pipes vs Redirection (recap from Ch. 3 and slide 14)¶

A pipe cmd1 | cmd2 connects stdout of cmd1 directly to stdin of cmd2 in memory. A redirection cmd > file sends stdout to a file on disk. They look similar but solve different problems.

ls . | grep file               # use pipe
ls -l > listing.txt            # use redirect
ls -l | wc -l                  # pipeline → counts dir entries
yourApp > log 2>&1             # capture stdout + stderr

Three streams: 0 stdin, 1 stdout, 2 stderr. 2>&1 ties stderr (FD 2) to wherever stdout (FD 1) currently points.

বাংলায়: Pipe (|) এক প্রোগ্রামের output সরাসরি আরেক প্রোগ্রামের input-এ পাঠায় — কোনো ফাইল তৈরি হয় না, সব মেমরিতে ঘটে; আর redirection (>) output-কে ডিস্কের ফাইলে লেখে। 2>&1 মানে হলো "stderr-কে সেখানে পাঠাও যেখানে stdout এখন যাচ্ছে" — ক্রমটা গুরুত্বপূর্ণ, তাই আগে > log তারপর 2>&1 লিখতে হয়; উল্টো লিখলে stderr টার্মিনালেই থেকে যায়। পরীক্ষায় এই order-এর trap প্রায়ই আসে।

4.2 Job control¶

Foreground: a program owns the terminal. Background (&): runs in parallel.

Action	Command
Run in background	`cmd &`
Suspend foreground	`Ctrl-Z`
Resume in background	`bg`
Resume in foreground	`fg`
Show jobs	`jobs`
Kill by job id	`kill %1`
List processes	`ps -ef`, `ps aux`, `top`, `htop`
Kill by PID	`kill 1234`, `kill -9 1234`
Survive logout	`nohup cmd > out.log 2>&1 &`
Persistent session	`tmux new -s sim`, detach `Ctrl-b d`, reattach `tmux a -t sim`
Persistent session (legacy)	`screen -S sim`, detach `Ctrl-a d`, reattach `screen -r sim`

Why nohup matters in HPC: without it, hanging up your terminal sends SIGHUP to children and they die.

4.3 Environment variables¶

A variable visible to every program your shell starts.

Variable	Use
`PATH`	Colon-separated dirs to search for commands
`HOME`	Your home dir (`~`)
`USER` / `LOGNAME`	Your username
`SHELL`	Login shell
`EDITOR`	Default editor (vim)
`LANG`	Language/locale
`TERM`	Terminal type
`PS1`	Prompt string
`LD_LIBRARY_PATH`	Where dynamic linker searches `.so` libs
`OMP_NUM_THREADS`	OpenMP thread count

TEST=hello              # local to this shell
echo "$TEST"            # hello
export TEST             # promote to environment (visible to children)
unset TEST              # remove
printenv | head         # show all env

4.4 Aliases and functions¶

alias ll='ls -la --color=auto'
alias openfoam='source /usr/lib/openfoam/etc/bashrc'

mkcd() {
  mkdir -p "$1" && cd "$1"
}

Alias = textual replacement, no parameters.
Function = real shell function with $1 $2 ….
&& chains "if previous succeeded, run next".

4.5 Sourcing vs running¶

./script.sh        # runs in subshell — env changes lost
source script.sh   # runs in current shell — env changes kept
. script.sh        # same as source

Why this matters: if script.sh does export VAR=..., only source makes VAR visible afterwards.

বাংলায়: ./script.sh চালালে একটা আলাদা subshell তৈরি হয় — script-এর ভেতরে export করা সব variable subshell শেষ হওয়ার সাথে সাথে হারিয়ে যায়। কিন্তু source (বা শুধু একটা dot) দিলে লাইনগুলো বর্তমান shell-এর ভেতরেই চলে, তাই environment-এর পরিবর্তন টিকে থাকে। এই কারণেই .bashrc এডিট করার পর source ~/.bashrc চালাতে হয় — পরীক্ষায় "কেন source, কেন execute নয়" প্রশ্নের উত্তর এটাই।

4.6 `.bashrc`, `.bash_profile`, `.profile`¶

File	Read by	Use for
`/etc/bash.bashrc` (or `/etc/bashrc`)	every bash	system-wide
`~/.bash_profile` (or `~/.profile`)	login shells (incl. SSH login)	login-time setup
`~/.bashrc`	interactive non-login shells (and usually sourced by `.bash_profile`)	aliases, functions, prompt
`~/.bash_logout`	when login shell exits	cleanup

Standard pattern: put real settings in .bashrc; in .bash_profile write [ -f ~/.bashrc ] && . ~/.bashrc.

Load-order flowchart (login vs non-login shell):

                        bash starts
                             │
             ┌───────────────┴────────────────┐
             ▼                                ▼
       LOGIN shell                      NON-LOGIN shell
  (ssh user@host, console         (new terminal window, tmux
   login, bash --login)            pane, typing "bash")
             │                                │
             ▼                                ▼
       /etc/profile                     interactive?
             │                       ┌──────┴───────┐
             ▼                       ▼ yes          ▼ no (script)
   first existing of:            ~/.bashrc      nothing read
   ~/.bash_profile                   │          (env inherited
   ~/.bash_login                     ▼           from parent)
   ~/.profile                  aliases, PS1,
             │                 functions active
             ▼
   good practice: ~/.bash_profile contains
   [ -f ~/.bashrc ] && . ~/.bashrc
             │
             ▼
   ──► so BOTH shell types end up loading ~/.bashrc

বাংলায়: SSH দিয়ে cluster-এ ঢুকলে যেটা খোলে সেটা login shell — bash তখন .bash_profile পড়ে, সরাসরি .bashrc নয়। আর ডেস্কটপে নতুন টার্মিনাল খুললে সেটা interactive non-login shell — তখন bash পড়ে .bashrc। তাই নিয়ম: আসল setting সব .bashrc-তে রাখো, আর .bash_profile-এ এক লাইন দিয়ে .bashrc-কে source করিয়ে দাও — তাহলে দুই ধরনের shell-এই সব কাজ করবে। এই load-order-টা পরীক্ষায় প্রায় প্রতি বছর জিজ্ঞেস করা হয়।

4.7 Prompt customisation¶

PS1='\u@\h:\w\$ '

Common escapes:

Escape	Meaning
`\u`	Username
`\h` / `\H`	Hostname (short / full)
`\w` / `\W`	Working dir / basename
`\d`	Date
`\t` / `\T` / `\@` / `\A`	Time variants
`\$`	`#` if root, else `$`
`\n`	Newline
`\#`	Command number
`\[\e[31m\]` … `\[\e[0m\]`	Colour start / reset

Example: PS1='\[\e[32m\]\u@\h\[\e[0m\]:\w\$ ' → green user@host.

4.8 Networking primer¶

A port is a number 0–65535 attached to an IP address. Server programs listen on a port; clients connect to a port.
0–1023 reserved (well-known): 22 SSH, 80 HTTP, 443 HTTPS, 25 SMTP, 21 FTP-cmd, 20 FTP-data, 110 POP3.
1024–49151 registered.
49152–65535 dynamic / ephemeral.
IP itself does not encrypt → packets can be sniffed → SSH/HTTPS add cryptography.

4.9 Cryptography in one slide¶

Symmetric (e.g. AES-256): one key, fast, robust, but the key-distribution problem.

Asymmetric (e.g. RSA, Ed25519): key pair — public freely shared, private kept safe. Slow but solves key distribution.

Three uses of asymmetric crypto:

Encryption — Bob encrypts with Alice's public key; only Alice's private key decrypts.
Authentication — Alice signs with her private key; Bob verifies with her public key.
Key exchange (Diffie–Hellman, Ed25519-DH) — both parties combine their own private with the other's public to derive a shared secret without ever transmitting it.

SSH uses (3) at handshake to agree a session key, then (1) symmetric AES for the data.

The mathematics of key-pair authentication (do this properly). A key pair $(k_{\mathrm{pub}}, k_{\mathrm{priv}})$ is generated together such that a signature created with $k_{\mathrm{priv}}$ can be checked with $k_{\mathrm{pub}}$, but computing $k_{\mathrm{priv}}$ from $k_{\mathrm{pub}}$ is computationally infeasible. The server stores only $k_{\mathrm{pub}}$ (one line in ~/.ssh/authorized_keys). Authentication is a challenge–response:

\[s = \mathrm{Sign}(k_{\mathrm{priv}}, c), \qquad \mathrm{Verify}(k_{\mathrm{pub}}, c, s) \in \{\text{true}, \text{false}\}\]

The server picks a fresh random challenge $c$ (in real SSH it is bound to the current session, so a recorded answer cannot be replayed).
The client computes the signature $s = \mathrm{Sign}(k_{\mathrm{priv}}, c)$ locally.
The server runs $\mathrm{Verify}(k_{\mathrm{pub}}, c, s)$ with the stored public key. True → logged in.

Only $c$ and $s$ ever cross the network; the private key never leaves your machine, and the server could not leak it even if fully compromised — it never had it. Contrast: password authentication must transmit the secret itself (inside the encrypted tunnel, but the server still receives and processes it).

Worked toy example (RSA with tiny numbers). Take $n = 55 = 5 \cdot 11$, public exponent $e = 3$, private exponent $d = 27$ (because $3 \cdot 27 = 81 \equiv 1 \pmod{40}$). Server sends challenge $c = 7$. Client signs:

\[s = c^{\,d} \bmod n = 7^{27} \bmod 55 = 28\]

(square-and-multiply: $7^2 = 49$, $7^4 = 36$, $7^8 = 31$, $7^{16} = 26$; $27 = 16 + 8 + 2 + 1$, so $s = 26 \cdot 31 \cdot 49 \cdot 7 \bmod 55 = 28$). Server verifies: $s^{\,e} \bmod n = 28^3 \bmod 55 = 21952 \bmod 55 = 7 = c$. Match → authenticated, and $d$ was never transmitted.

Security levels — why ed25519 keys are so short. "$n$-bit security" means the best known attack costs about $2^n$ operations. Elliptic-curve keys (Ed25519) reach the same security as much longer RSA keys:

Algorithm	Key size	Effective security	Note
RSA	1024 bits	~80 bits	broken-ish, never use
RSA	2048 bits	~112 bits	minimum acceptable today
RSA	3072 bits	~128 bits	needed to match Ed25519
Ed25519	256 bits	~128 bits	small, fast, modern default
AES (symmetric)	256 bits	256 bits	the session cipher

Scale check: $2^{128} \approx 3.4 \times 10^{38}$; even at $10^{18}$ guesses per second, brute force needs about $10^{13}$ years. (Note: for ssh-keygen -t ed25519 the -b option is ignored — the key size is fixed at 256 bits; -b only matters for RSA.)

বাংলায়: মূল কথা: server-এর কাছে শুধু তোমার public key থাকে (authorized_keys ফাইলে), private key কোনোদিনই তোমার মেশিন ছেড়ে যায় না। Login-এর সময় server একটা random challenge পাঠায়, client সেটা private key দিয়ে sign করে ফেরত দেয়, server public key দিয়ে যাচাই করে — নেটওয়ার্কে কোনো গোপন জিনিস যায় না বলেই এটা password-এর চেয়ে নিরাপদ। আর ed25519-এর মাত্র ২৫৬-bit key-তেই RSA-র ৩০৭২ bit-এর সমান (~১২৮-bit) নিরাপত্তা পাওয়া যায় — তাই নতুন key মানেই ed25519।

4.10 SSH protocol — the five steps¶

Client ssh user@host. TCP/22 handshake.
Both sides agree on cipher suite and run Diffie–Hellman → shared secret.
Server identification — server proves it owns its host-key (you check the fingerprint on first connection).
User authentication — by password OR by public-key (preferred). SSH server checks ~/.ssh/authorized_keys for the user's public key.
Session encrypted with AES; user runs commands until exit.

Key-auth handshake — sequence diagram (memorise the lanes):

      CLIENT (laptop)                          SERVER (cluster)
            │                                        │
            │ ── 1. TCP connect to port 22 ────────► │
            │ ◄── 2. protocol versions, ciphers ───► │
            │                                        │
            │ ◄── 3. ECDH key exchange ────────────► │  shared secret K;
            │      server signs with its HOST key;   │  channel now
            │      client checks ~/.ssh/known_hosts  │  AES-encrypted
            │                                        │
            │ ◄── 4. random challenge c ──────────── │  c bound to this
            │                                        │  session (no replay)
            │ ── 5. s = Sign(k_priv, c) ───────────► │  looks up k_pub in
            │      (private key NEVER sent)          │  ~/.ssh/authorized_keys
            │                                        │  Verify(k_pub, c, s)?
            │ ◄── 6. AUTH OK ─────────────────────── │
            │                                        │
            │ ◄══ 7. encrypted session: shell, ════► │
            ▼       scp/sftp, -L/-R tunnels          ▼

4.11 Passwordless SSH (top-priority exam topic)¶

# 1. on local machine
ssh-keygen -t ed25519 -b 4096 -f ~/.ssh/cluster_key
# (-t algorithm, -b bits, -f file)

# 2. push public key to server
ssh-copy-id -i ~/.ssh/cluster_key.pub user@host
# (uses password ONCE to append your pub key to ~/.ssh/authorized_keys)

# 3. write ~/.ssh/config so 'ssh cluster' just works
cat >> ~/.ssh/config <<'EOF'
Host cluster
    HostName host.example.com
    User user
    IdentityFile ~/.ssh/cluster_key
    Port 22
EOF
chmod 600 ~/.ssh/config
chmod 700 ~/.ssh
chmod 600 ~/.ssh/cluster_key
chmod 644 ~/.ssh/cluster_key.pub

After that: ssh cluster logs in without a password.

Permission rules — exam classic:

~/.ssh directory: 700
private keys: 600
public keys: 644
~/.ssh/authorized_keys: 600
~/.ssh/config: 600

বাংলায়: Passwordless SSH-এর রেসিপি মুখস্থ রাখো: প্রথমে ssh-keygen দিয়ে key pair বানাও, তারপর ssh-copy-id দিয়ে public key-টা server-এর authorized_keys-এ পৌঁছে দাও (শুধু এই একবারই password লাগে), শেষে ~/.ssh/config-এ shortcut block লেখো। Permission ভুল হলে SSH key নিতেই অস্বীকার করবে — directory 700, private key 600, public key 644। পরীক্ষায় এই চার ধাপ আর permission টেবিল লিখলেই পুরো নম্বর।

4.12 SSH file transfer¶

Tool	One-shot?	Resumable?	Mount?	Use when
`scp`	yes	no	no	Quick copy
`rsync`	yes	yes (delta)	no	Big or repeated copies
`sftp`	interactive	partial	no	"FTP-like" sessions
`sshfs`	continuous	n/a	yes	Edit remote files like local

Common commands:

scp file.cfg user@host:/path/                  # local → remote
scp user@host:/path/results.tar.gz .           # remote → local
scp -r dir/ user@host:/path/                   # recursive

rsync -avz src/ user@host:/dst/                # mirror, compressed
rsync -avzP --delete src/ user@host:/dst/      # mirror exactly, with progress
rsync -avz user@host:/dst/ ./local/            # pull

sftp user@host                                 # interactive
sftp> put file
sftp> get remote.txt
sftp> bye

sshfs user@host:/remote ~/mnt -o reconnect      # mount
fusermount -u ~/mnt                             # unmount

rsync -avz flags:

-a archive (recursive + permissions + symlinks + times)
-v verbose
-z compress in transit
-P progress + partial
--delete delete on destination if missing on source

Trailing slash trick: rsync src/ dst/ copies contents; rsync src dst/ copies the directory src itself into dst.

rsync's delta-transfer idea — precise statement. The receiver splits its old copy of the file into fixed blocks of size $B$ and sends, for every block, a cheap rolling checksum plus a strong hash. The sender slides a window of width $B$ over the new file one byte at a time; the rolling checksum is designed so that shifting the window by one byte costs $O(1)$:

\[r_{i+1} = f(r_i,\; x_{\mathrm{out}},\; x_{\mathrm{in}})\]

(new checksum computed from the old checksum, the byte leaving the window, and the byte entering it — no rescan of the whole block). Whenever the weak checksum matches one of the receiver's blocks, the strong hash confirms the match, and the sender transmits the instruction "reuse your block $j$" instead of the bytes themselves. Only blocks that changed cross the network; everything else is reconstructed locally on the receiving side.

Worked example. A 1 GiB result file in which only 1 MiB changed, with $B = 32$ KiB and ~20 bytes of checksum metadata per block:

\[\#\text{blocks} = \frac{1\,\mathrm{GiB}}{32\,\mathrm{KiB}} = 32768, \qquad \text{metadata} \approx 32768 \times 20\,\mathrm{B} \approx 640\,\mathrm{KiB}\]

Total traffic $\approx 1\,\mathrm{MiB} + 0.64\,\mathrm{MiB} \approx 1.6\,\mathrm{MiB}$ versus 1024 MiB for scp — roughly 600× less data. This is why repeated syncs of big CFD result directories must use rsync, not scp.

বাংলায়: rsync-এর জাদু হলো delta-transfer: পুরো ফাইল আবার না পাঠিয়ে receiver তার পুরনো কপিকে block-এ ভাগ করে প্রতিটার checksum পাঠায়, আর sender rolling checksum দিয়ে $O(1)$ খরচে window সরিয়ে সরিয়ে মিলিয়ে দেখে কোন block অপরিবর্তিত আছে। ফলে শুধু বদলে যাওয়া block-গুলোই নেটওয়ার্ক পার হয়। তাই বারবার sync করা বড় result directory-র জন্য scp নয়, rsync — পরীক্ষায় "scp vs rsync" এলে delta algorithm আর rolling checksum শব্দ দুটো অবশ্যই লিখবে।

4.13 Port forwarding¶

Form	Syntax	Effect
Local	`ssh -L 8080:localhost:80 user@host`	Local port 8080 → remote port 80
Remote	`ssh -R 9000:localhost:22 user@host`	Remote port 9000 → local port 22
Dynamic	`ssh -D 1080 user@host`	SOCKS5 proxy on local 1080

Local forwarding -L (bring a remote service to MY machine):

   ssh -L 8080:localhost:80 user@server

   LAPTOP                                  SERVER
 ┌───────────────────────┐             ┌───────────────────────┐
 │ browser               │             │ web server on :80     │
 │   │ http://localhost:8080           │          ▲            │
 │   ▼                   │  encrypted  │          │            │
 │ ssh listens on :8080 ─┼─ tunnel ───►│ sshd ────┘            │
 │                       │  (port 22)  │ "localhost:80" is     │
 └───────────────────────┘             │ resolved ON THE SERVER│
                                       └───────────────────────┘
 listening port opens on the LAPTOP; destination seen from the SERVER

Remote forwarding -R (publish MY local service on the remote machine):

   ssh -R 9000:localhost:3000 user@server

   LAPTOP                                  SERVER
 ┌───────────────────────┐             ┌───────────────────────┐
 │ dev app on :3000 ◄──┐ │             │ sshd listens on :9000 │
 │                     │ │  encrypted  │          ▲            │
 │ ssh client ─────────┼─┼─ tunnel ───►│──────────┘            │
 │ (initiates the      │ │  (port 22)  │ anyone on the server  │
 │  connection)        │ │             │ hitting :9000 reaches │
 └─────────────────────┴─┘             │ the laptop's :3000    │
                                       └───────────────────────┘
 listening port opens on the SERVER; destination is back on the LAPTOP

বাংলায়: -L মানে local forwarding: দূরের service-কে নিজের ল্যাপটপে টেনে আনা (যেমন cluster-এর Jupyter ল্যাপটপের browser-এ দেখা)। -R মানে উল্টো: নিজের ল্যাপটপের service-কে দূরের server-এ প্রকাশ করা। মনে রাখার কৌশল: প্রথম port-টা সবসময় সেখানে খোলে যে মেশিনের অক্ষর — -L-এ তোমার (Local) মেশিনে, -R-এ Remote server-এ। আর গন্তব্যের localhost সবসময় server-এর দিক থেকে resolve হয় — এটাই পরীক্ষার সবচেয়ে বড় trap।

Real-life HPC use: open a Jupyter notebook on a compute node and forward port 8888 to your laptop:

ssh -L 8888:compute01:8888 user@cluster

4.14 Diagram explanations from V02.1¶

"Simplified network" diagram: local machine ↔ network ↔ remote server, both with IP+port. Write: "Two endpoints communicate through a TCP connection identified by source/destination IP and port."
"Symmetric vs asymmetric" diagrams: one-key padlock vs two-key letter slot. Use these analogies in answers.
"Encryption / Authentication / Key-exchange" three-pane figure: memorise that all three uses of asymmetric crypto exist; SSH uses (2) and (3).

5. Command / Syntax / Code Breakdown¶

`export VAR=value`¶

Purpose: create environment variable visible to children.
Common mistake: spaces around = (VAR = value is three commands).

`alias name='cmd'`¶

Quotes vital. alias ll=ls -la (no quotes) breaks.
Survives only in the shell that defined it; put in .bashrc for persistence.

`source ~/.bashrc`¶

Re-loads the file in the current shell.

`nohup cmd > log 2>&1 &`¶

nohup: ignore SIGHUP.
> log 2>&1: capture both streams.
&: background.

`ssh user@host`¶

Default port 22 — change with -p 2222.
-i keyfile use specific key.
-X forward X11 (gnuplot windows).
-J jump@gateway user@host jump-host.

`ssh-keygen -t ed25519 -b 4096 -f ~/.ssh/key`¶

-t algorithm: rsa, ed25519 (recommended), ecdsa.
-b bits.
-f filename.
-N "passphrase" non-interactive.

`ssh-copy-id -i ~/.ssh/key.pub user@host`¶

Appends .pub to remote ~/.ssh/authorized_keys. Uses password once.

`scp [-r] [-P PORT] src dst`¶

-r recursive, -P port (uppercase!).

`rsync -avzP --delete src/ user@host:/dst/`¶

Most-used HPC sync command.

`sshfs user@host:/remote ~/mnt`¶

Need package sshfs. Mount until fusermount -u.

`tmux new -s sim` / `tmux a -t sim`¶

Persistent sessions. Detach Ctrl-b d.

6. Mandatory Practical Example¶

Purpose¶

Set up passwordless SSH to a cluster, copy data via rsync, run a long job under nohup, retrieve results.

Input¶

A username and a (placeholder) cluster hostname.

Code / Command¶

# ON LOCAL MACHINE
ssh-keygen -t ed25519 -b 4096 -f ~/.ssh/cluster_key -N ""
ssh-copy-id -i ~/.ssh/cluster_key.pub myuser@cluster.example.com

cat >> ~/.ssh/config <<'EOF'
Host hpc
    HostName cluster.example.com
    User myuser
    IdentityFile ~/.ssh/cluster_key
EOF
chmod 700 ~/.ssh
chmod 600 ~/.ssh/{cluster_key,config}

# Push input data
rsync -avzP ./case01/ hpc:~/cases/case01/

# Open a persistent session
ssh hpc
tmux new -s case01
cd ~/cases/case01
nohup ./run.sh > run.log 2>&1 &
disown
# detach: Ctrl-b d, then `exit` — the job keeps running.

# Pull results back
rsync -avzP hpc:~/cases/case01/results/ ./results/

Expected Output¶

Generating public/private ed25519 key pair.
Your identification has been saved in /home/me/.ssh/cluster_key
Your public key has been saved in /home/me/.ssh/cluster_key.pub
...
sending incremental file list
case01/
case01/in.dat
...
sent 1,234,567 bytes  received 250 bytes  ...  speedup is 5.00

Step-by-Step Explanation¶

Generate Ed25519 key pair, no passphrase (HPC tutorials often allow none for non-critical accounts; a passphrase is safer).
ssh-copy-id adds your .pub to authorized_keys.
~/.ssh/config makes ssh hpc shorthand for the full destination.
rsync -avzP mirrors data with progress and compression.
tmux keeps the shell alive when you disconnect.
nohup ./run.sh > run.log 2>&1 & starts the job, redirects stdout+stderr, and detaches it.
disown removes the job from the shell's tracking, so exit won't kill it.
rsync back to local pulls the results.

Real-Life HPC/CFD Meaning. Exactly the workflow used at LUIS / TU clusters: you push a CFD case, launch the solver inside tmux/nohup, and pull results when done.

Written Exam Relevance. A 10-mark question often asks you to write the full procedure for passwordless login + rsync + remote job. The above covers all required steps.

বাংলায়: এই আটটা ধাপই পরীক্ষার "১০-নম্বরী গল্প": চাবি বানাও → চাবি বসাও → shortcut লেখো → ডেটা পাঠাও → tmux/nohup-এ চালাও → disown → ফল টেনে আনো। ক্রমটা এলোমেলো করলে নম্বর যায় — গল্পের মতো মুখস্থ রাখো।

7. Real HPC/CFD Workflow¶

Daily routine of a CFD researcher:

ssh hpc                                          # 1. login
module load gcc/12 openmpi/4.1                   # 2. environment
cd $WORK/sim_$(date +%F)                         # 3. workdir
git pull                                         # 4. fresh code
mpicc solver.c -O3 -fopenmp -o solver            # 5. build
sbatch run.sbatch                                # 6. queue job
squeue -u $USER                                  # 7. monitor
rsync -avzP results/ ~/local/results/            # 8. fetch
gnuplot plot.gp                                  # 9. plot

Each line links to a chapter — this chapter covers steps 1, 8 (SSH, rsync) and the underlying .bashrc that defines module, PATH, aliases.

8. Exercises and Solutions¶

The lecture's slide deck combines exercises into the lecture; below are exam-grade reproductions.

Exercise 4-A — Pipes vs Redirection¶

List files in /var/log and store into count.txt only the count of .log files.

Solution:

ls /var/log | grep '\.log$' | wc -l > count.txt

বাংলায়: | দিয়ে এক কমান্ডের আউটপুট অন্য কমান্ডে যায়; > দিয়ে শেষ আউটপুট ফাইলে সেভ হয়।

Marking scheme (5 marks): 1 mark ls /var/log, 1 grep filter, 1 wc -l, 1 redirect, 1 correct interpretation.

Exercise 4-B — Background, nohup, tmux¶

A simulation ./solve takes 10 hours. You must log out and return tomorrow. Two reliable ways:

A. nohup ./solve > out.log 2>&1 & then disown.

B. tmux new -s case → run ./solve → detach Ctrl-b d → next day tmux a -t case.

Common mistake. Using just & without nohup — the job dies on logout (SIGHUP).

Exercise 4-C — .bashrc snippet¶

Add ~/bin and /opt/cfd/bin to PATH; alias gs='git status'; function mkcd; coloured prompt.

# ~/.bashrc additions
export PATH="$HOME/bin:/opt/cfd/bin:$PATH"
alias gs='git status'
mkcd() { mkdir -p "$1" && cd "$1"; }
PS1='\[\e[32m\]\u@\h\[\e[0m\]:\[\e[34m\]\w\[\e[0m\]\$ '

Exercise 4-D — Passwordless SSH¶

Configure passwordless login to cluster.iag.de as lab01 using Ed25519:

ssh-keygen -t ed25519 -f ~/.ssh/iag_key -N ""
ssh-copy-id -i ~/.ssh/iag_key.pub lab01@cluster.iag.de
cat >> ~/.ssh/config <<'CFG'
Host iag
    HostName cluster.iag.de
    User lab01
    IdentityFile ~/.ssh/iag_key
CFG
chmod 600 ~/.ssh/iag_key ~/.ssh/config
ssh iag    # done

Marking scheme (8 marks): 2 ssh-keygen options, 2 ssh-copy-id, 2 config block, 1 chmod, 1 final test.

Exercise 4-E — Compare scp / rsync / sftp / sshfs¶

Tool	Mode	Use when
scp	one-shot copy	small/simple
rsync	incremental sync	big or repeated
sftp	interactive	manual exploration
sshfs	continuous mount	edit live with local tools

Exercise 4-F — Port forwarding¶

The compute node cn01 runs Jupyter on port 8888. Forward to your laptop's port 9999:

ssh -L 9999:cn01:8888 user@cluster
# Now open http://localhost:9999 in your laptop browser.

9. Written Exam Focus¶

9.1 Short Answers¶

Q. Difference between symmetric and asymmetric encryption. A. Symmetric uses one key for both encrypt and decrypt — fast (AES-256) but the key must be exchanged securely. Asymmetric uses a public/private key pair — public encrypts (or verifies signatures), private decrypts (or signs). Asymmetric is slower but solves key exchange.

Q. Why is SSH preferred over Telnet? A. Telnet sends everything in plain text including passwords; SSH encrypts the entire session, authenticates the server, and supports public-key authentication.

Q. What does nohup do? A. Ignores the SIGHUP signal sent when the terminal closes, so the process survives logout. Combined with & and redirection it makes a proper detached job.

Q. Difference between .bashrc and .bash_profile. A. .bash_profile is read by login shells (SSH session start) — one-time login setup. .bashrc is read by interactive non-login shells — aliases, functions, prompt. Convention: source .bashrc from .bash_profile.

Q. Why is ssh-keygen more secure than passwords? A. Public-key authentication never sends any secret over the network and resists brute-force.

9.2 Medium Answers¶

Q. (8 marks) Describe the SSH passwordless authentication procedure.

A. 1. Generate a key pair on the client: ssh-keygen -t ed25519 -f ~/.ssh/cluster_key. 2. Copy the public key to the server: ssh-copy-id -i ~/.ssh/cluster_key.pub user@server — appends to ~/.ssh/authorized_keys. 3. Configure a shortcut in ~/.ssh/config (Host, HostName, User, IdentityFile). 4. Permissions: dir 700, private key 600, public 644. 5. Test: ssh cluster. The client signs a server-issued challenge with the private key; the server verifies with the matching public key — no secret crosses the network.

Q. (5 marks) Compare scp and rsync.

A. Both transfer over SSH. scp is a simple full copy that re-sends everything. rsync syncs incrementally via a rolling-checksum delta algorithm, copies only differences, resumes interrupted transfers, preserves permissions/symlinks (-a), compresses (-z), shows progress (-P). For repeatedly synchronised CFD result directories, rsync -avzP is right.

9.3 Long Answer (12 marks)¶

Q. Explain how SSH establishes a secure connection from key handshake to encrypted session.

A.

Introduction. SSH (Secure Shell, RFC 4251) provides a cryptographically protected channel over an untrusted network, on port 22.

Main concept. Asymmetric crypto for handshake/authentication; symmetric crypto for bulk traffic.

Step-by-step.

TCP handshake to port 22.
Algorithm negotiation — key-exchange (curve25519-sha256), host-key (ssh-ed25519), cipher (aes256-gcm), MAC.
Key exchange — ephemeral Elliptic-Curve Diffie–Hellman: both sides derive a shared secret that never crosses the wire.
Server authentication — server signs the handshake with its host key; client checks ~/.ssh/known_hosts (TOFU on first contact).
User authentication — publickey: server sends a challenge, client signs with the private key, server verifies against authorized_keys.
Encrypted session — both switch to symmetric AES-GCM keyed from the shared secret.
Channels — shell, scp/sftp subsystems, -L/-R tunnels share the one secure session.

client ---- TCP ----> server (port 22)
   <-- algos -->
   <-- ECDH key-exchange --> shared_secret
   <-- server sig with host key -->
   <-- client sig with user key --> AUTH OK
   <-- AES-GCM channels (shell, sftp, tunnels) -->

Real HPC/CFD link. This happens at every ssh cluster; the same channel carries scp, rsync, sshfs and forwarded Jupyter ports.

Conclusion. SSH gives confidentiality, integrity and mutual authentication at near-zero cost — the cornerstone of remote HPC work.

9.4 Output Prediction¶

$ alias ll='ls -la'
$ ll | wc -l

→ Number of lines of ls -la (≥ 3: ., .., total).

$ export X=5
$ bash -c 'echo $X'

→ 5. (Without export: empty — child processes see only exported vars.)

$ ssh -L 8000:localhost:80 me@server

→ Local port 8000 tunneled to the server's port 80.

9.5 Comparison¶

	Symmetric	Asymmetric
Keys	1 shared	2 (public+private)
Speed	Fast	~1000× slower
Algos	AES, ChaCha20	RSA, Ed25519, ECDSA
Used in SSH for	session traffic	handshake / auth

Op	Meaning
`>`	overwrite stdout
`>>`	append stdout
`<`	feed stdin
`2>`	redirect stderr
`2>&1`	merge stderr into stdout
`\\|`	pipe stdout into next stdin

	scp	rsync	sftp	sshfs
Mode	one-shot	incremental	interactive	mount
Resumable	no	yes (`-P`)	partial	continuous
Speed on big sync	slow	fast	slow	medium
Use	quick copy	repeated sync	manual exploration	edit remote

9.6 Templates¶

Encryption template: "Symmetric uses one key — fast but key-distribution problem. Asymmetric uses a key pair — slower but solves key distribution. SSH does asymmetric for handshake and auth, then symmetric for the session."

SSH-passwordless template: "1) ssh-keygen 2) ssh-copy-id 3) ~/.ssh/config 4) chmod 600 5) test."

9.7 Marking Scheme — "scp vs rsync" (5 marks)¶

1: both use SSH transport.
1: scp = full copy.
1: rsync = incremental / delta algorithm.
1: rsync flags -a -v -z -P --delete.
1: rsync for repeated big transfers; scp ok for one-shot.

10. Very Hard Questions¶

Beginner

Default SSH port? → 22.
File listing your authorized public keys? → ~/.ssh/authorized_keys.
Command for one-shot file copy? → scp.
Command for incremental sync? → rsync.
What does & do at the end of a command? → Run in background.

Intermediate

Why ed25519 over rsa for new keys? → Smaller, faster, modern, equally secure.
Permission for ~/.ssh/id_ed25519? → 600.
Where do aliases go? → ~/.bashrc.
source script vs executing it? → source modifies the CURRENT shell env.
2>&1 in plain English. → "send stderr to wherever stdout currently points".

Hard

ssh -L 8888:cn01:8888 user@gateway — explain. → Local-port forward: localhost:8888 tunneled via gateway to cn01:8888.
Why does tmux survive disconnection but a plain shell not? → tmux runs a server process owning the pty; the client merely attaches.
~/.ssh is mode 777 — outcome? → SSH refuses the keys for safety.
What is ~/.ssh/known_hosts? → Trusted server fingerprints; detects MITM.
rsync src/ dst/ vs rsync src dst/? → Trailing slash = "contents of"; without it, the dir itself is created inside dst.

Very Hard

Why is TOFU host-key verification a weakness, and the mitigation? → MITM possible at first contact; mitigate with SSHFP DNS records, SSH CAs, or out-of-band fingerprint checks.
Agent forwarding (ssh -A) trade-off? → Lets you hop onward without copying keys; a compromised intermediate host can use (not read) your agent.
Why can rsync resume but scp cannot? → rsync's checksum/delta protocol tracks state; scp is a dumb stream.

Deep Integration

Map this chapter's tools onto a CFD workflow. → ssh login → tmux session → rsync push case → sbatch → detach → rsync pull results.
Why do HPC admins disable password authentication? → kills brute-force; forces auditable key-based access.

Coding/Command

Mirror ~/work to cluster, deleting vanished files. → rsync -avzP --delete ~/work/ cluster:~/work/
Bash function tunneling Jupyter from a node:

jup() { ssh -L 8888:"$1":8888 cluster; }

Debugging

"Permission denied (publickey)" though the key exists. → wrong key perms, key not offered (config/agent), or pubkey missing from authorized_keys.
scp: not found on a new cluster. → modern OpenSSH dropped legacy scp protocol; use scp -O, sftp, or rsync.

Long Written

(250 words) "Describe the complete daily workflow of a CFD researcher using SSH, rsync, tmux, and SLURM."

11. Debugging and Mistake Analysis¶

Mistake	Why wrong	Correct	Explanation
`VAR = 5`	spaces make it a command	`VAR=5`	whitespace-sensitive
`alias ll = 'ls -la'`	same disease	`alias ll='ls -la'`	no spaces around `=`
`chmod 644 id_ed25519`	world-readable private key	`chmod 600`	SSH refuses otherwise
`rsync src dst`	copies dir itself	`rsync src/ dst/`	trailing slash = contents
`scp -p 22 host:f .`	lowercase -p is "preserve"	`scp -P 22 …`	scp port flag is uppercase
Forgot nohup/disown	job dies on logout	`nohup … & disown`	SIGHUP handling
env only in `.bash_profile`	non-login shells miss it	put in `.bashrc`, source it	standard pattern
`>` instead of `>>`	truncates file	`>>`	append
`ssh -X` against strict server	X11 fwd disabled	`-Y` or enable server-side	config
No export for LD_LIBRARY_PATH	child can't see it	`export LD_LIBRARY_PATH=…`	env vs local var

বাংলায়: এই অধ্যায়ের তিনটা সিগনেচার-ভুল: private key-র permission 600 না রাখা (SSH সরাসরি প্রত্যাখ্যান করে), rsync-এর trailing slash গুলিয়ে ফেলা (contents বনাম ফোল্ডার নিজে), আর nohup ছাড়া & দিয়ে ভেবে নেওয়া job বেঁচে থাকবে। তিনটাই পরীক্ষায় "কী ভুল হয়েছে" আকারে আসে।

12. Mini Project for Mastery¶

Goal: Build a tiny "cluster client" CLI that pushes/pulls data and runs a simulation.

# ~/bin/cf (chmod +x)
#!/usr/bin/env bash
set -euo pipefail
CASE_DIR="${HOME}/cases/${1:-default}"
HOST=hpc

case "${2:-help}" in
  push) rsync -avzP --delete "${CASE_DIR}/" "${HOST}:cases/${1}/" ;;
  pull) rsync -avzP --delete "${HOST}:cases/${1}/" "${CASE_DIR}/" ;;
  run)  ssh "${HOST}" "cd cases/${1} && nohup ./run.sh > run.log 2>&1 & disown" ;;
  log)  ssh "${HOST}" "tail -f cases/${1}/run.log" ;;
  *) echo "usage: cf <case> {push|pull|run|log}" ;;
esac

Add to .bashrc: alias cfa='cf case_alpha'. Now cfa push && cfa run && cfa log is one workflow.

Connection to exam: env vars, alias, function, ssh, rsync, nohup, redirection, job control — most of the chapter in 20 lines.

13. Final Chapter Cheat Sheet¶

Topic	Memorise
`.bashrc`	aliases, functions, prompt
`.bash_profile`	sourced once at login; `source ~/.bashrc`
`export VAR=val`	environment variable
`alias ll='ls -la'`	text shortcut
`mkcd(){ mkdir -p "$1" && cd "$1"; }`	function example
`nohup ./run > log 2>&1 &`	survive logout
`tmux new -s` / `tmux a -t`	persistent shell
`Ctrl-b d`	tmux detach
`kill -9 PID`	force kill
Symmetric (AES)	one key, fast
Asymmetric (Ed25519)	pub/priv; ~128-bit security from 256-bit keys (RSA needs 3072)
SSH	port 22, AES-GCM session
`ssh-keygen -t ed25519 -f ~/.ssh/k`	key gen
`ssh-copy-id -i k.pub u@h`	install key
`~/.ssh/config`	shortcut block
chmod 700 `~/.ssh`, 600 keys	required perms
`scp -r src host:dst`	one-shot
`rsync -avzP --delete s/ h:d/`	smart sync
`sshfs h:d ~/m -o reconnect`	mount remote
`ssh -L 8888:host:8888 u@gw`	local fwd
`ssh -R`	reverse fwd
`ssh -D 1080`	SOCKS proxy
Trap	"private key 644" → SSH rejects
Top-grade phrase	"SSH uses ECDH for key-exchange, public-key for authentication, and AES-GCM for the session."

14. Mock Exam — Four Levels¶

Level 1 — Basic (definitions & syntax)¶

Q1. Which file on the SERVER must contain your public key for passwordless login?

Solution: ~/.ssh/authorized_keys (of the account you log into).

Q2. Write the command generating an Ed25519 key pair stored as ~/.ssh/hpc.

Solution: ssh-keygen -t ed25519 -f ~/.ssh/hpc

Q3. What's the difference between scp file host: and rsync file host:?

Solution: Same single-file result, but scp always copies fully; rsync skips/delta-transfers if the destination already matches.

Q4. Which dotfile should contain your aliases, and why not the other one?

Solution: ~/.bashrc — read by every interactive shell; .bash_profile runs only at login, so aliases there would miss new terminals (unless it sources .bashrc).

Q5. Write the tmux commands to create session run1, detach, and re-attach.

Solution: tmux new -s run1 … Ctrl-b d … tmux a -t run1.

Level 2 — Intuitive (predict / explain why)¶

Q1. You add export PATH=$PATH:~/tools to .bashrc but a script run via cron doesn't find your tool. Why?

Solution: cron starts a non-interactive shell that doesn't read .bashrc; set PATH inside the script or in the crontab.

Q2. Why does the server need only your PUBLIC key — what stops someone who steals that public key from logging in?

Solution: The public key can only VERIFY signatures, not create them. Login requires signing the server's challenge, which needs the private key — which never left your laptop.

Q3. Predict: ssh hpc 'echo $HOSTNAME' vs ssh hpc "echo $HOSTNAME" from laptop mylap to host node1.

Solution: Single quotes: the variable expands remotely → node1. Double quotes: your LOCAL shell expands first → mylap. Quoting decides where expansion happens.

Q4. rsync -avzP big/ hpc:big/ is interrupted at 80%. What happens on rerun, and which flag made that possible?

Solution: It resumes/repairs: only missing or partial files are re-sent (-P = --partial --progress keeps partial files; the delta algorithm skips completed ones).

Q5. After ssh -L 5000:db:5432 user@bastion, where does traffic to localhost:5000 actually go, and which machine resolves the name db?

Solution: Laptop:5000 → encrypted tunnel → bastion → onward (unencrypted unless DB encrypts) to db:5432. The name db is resolved BY THE BASTION, not your laptop.

Level 3 — Hard (exam level)¶

Q1. (10 marks) Write the complete passwordless-login setup from laptop to cluster.tu-bs.de (user y0099999) including config shortcut and correct permissions, and explain what each permission protects.

Solution:

ssh-keygen -t ed25519 -f ~/.ssh/tubs -N ""
ssh-copy-id -i ~/.ssh/tubs.pub y0099999@cluster.tu-bs.de
cat >> ~/.ssh/config <<'CFG'
Host tubs
    HostName cluster.tu-bs.de
    User y0099999
    IdentityFile ~/.ssh/tubs
CFG
chmod 700 ~/.ssh
chmod 600 ~/.ssh/tubs ~/.ssh/config
ssh tubs

700 on the dir stops others traversing/listing; 600 on the private key keeps the secret unreadable (SSH refuses group/world-readable keys); config at 600 protects host/user mapping. বাংলা ইঙ্গিত: কোন permission কী রক্ষা করে — এই "explain" অংশটাই বেশির ভাগ ছাত্র বাদ দেয়; দিও না।

Q2. (8 marks) Your 12 h job ran fine in tmux yesterday, but today you started it as ./solve &, closed the laptop, and it died. Explain the mechanism, then give the one-liner that would have survived plus how to check on it tomorrow.

Solution: Closing the session sends SIGHUP to the shell's process group; a plain background job receives it and dies. Survivor: nohup ./solve > solve.log 2>&1 & disown. Check tomorrow: ssh hpc 'tail -f solve.log' (or pgrep -af solve). বাংলা ইঙ্গিত: & শুধু background করে, মৃত্যু থেকে বাঁচায় না — বাঁচায় nohup (SIGHUP উপেক্ষা) আর disown (shell-এর খাতা থেকে নাম কাটা)।

Q3. (8 marks) One rsync command: mirror $WORK/results/ to local ~/res/, compressed, resumable, deleting locally what vanished remotely, but doing a DRY RUN first. Give both commands.

Solution:

rsync -avzPn --delete hpc:'$WORK/results/' ~/res/   # -n: dry run, lists actions
rsync -avzP  --delete hpc:'$WORK/results/' ~/res/   # real run

--delete is destructive — the dry run (-n) preview is the professional habit. Single-quoting $WORK makes the REMOTE shell expand it. বাংলা ইঙ্গিত: --delete যেখানে, dry-run সেখানে আগে — আর remote variable remote-এই expand হতে দাও (single quote)।

Q4. (10 marks) Build the 2-hop config: laptop → gateway.uni.de (user gw1) → hpc-internal (user lab2, reachable only from the gateway). Then state the single command to copy case.tgz to the internal host.

Solution:

Host gate
    HostName gateway.uni.de
    User gw1
Host hpci
    HostName hpc-internal
    User lab2
    ProxyJump gate

Copy: scp case.tgz hpci: (or rsync -avzP case.tgz hpci:) — ProxyJump tunnels transparently through the gateway. বাংলা ইঙ্গিত: ProxyJump (-J) = আধুনিক উত্তর; nc/ProxyCommand-এর পুরোনো কায়দা লিখলে সময় নষ্ট।

Q5. (10 marks) Explain the challenge-response: what exactly does the server send, what does the client return, and why does a replay attack (recording the response and re-sending later) fail?

Solution: The server sends a fresh random nonce (session-bound data). The client signs that nonce (plus session identifiers) with the private key and returns the signature. The server verifies with the stored public key. Replay fails because each session's nonce differs — yesterday's recorded signature doesn't verify against today's fresh challenge. বাংলা ইঙ্গিত: জাদু-শব্দ "fresh random challenge" — প্রতিবার নতুন, তাই পুরোনো উত্তর অচল; এটা লিখলেই প্রশ্নের মেরুদণ্ড দাঁড়িয়ে গেল।

Level 4 — Beyond the lecture (transfer + coding)¶

Q1. Write a bash script sync_watch.sh that pushes your local case dir to the cluster, submits the job, then polls every 2 min and rsyncs results back ONLY once squeue no longer lists the job. (Ch 8 + 15 transfer.)

Solution:

#!/bin/bash
set -euo pipefail
CASE=${1:?usage: sync_watch.sh CASE}
rsync -azP "$CASE/" hpc:"cases/$CASE/"
JID=$(ssh hpc "cd cases/$CASE && sbatch run.sbatch" | awk '{print $4}')
echo "job $JID submitted"
while ssh hpc "squeue -h -j $JID" | grep -q .; do sleep 120; done
rsync -azP hpc:"cases/$CASE/results/" "$CASE/results/"
echo "results synced"

বাংলা ইঙ্গিত: পুরো remote-workflow এক স্ক্রিপ্টে: rsync→sbatch→poll→rsync; job ID ধরা awk '{print $4}' — এটাই glue।

Q2. Security analysis: a colleague pastes their PRIVATE key into authorized_keys on the server "because it didn't work with the public one". Enumerate the consequences and the correct recovery procedure.

Solution: Consequences: the private key is now exposed to every server admin/backup; anyone reading that file can impersonate the colleague on EVERY system using that key pair; authentication still fails (the file expects public keys). Recovery: delete the line server-side, treat the key pair as compromised — generate a NEW pair, install the new public key, remove the old public key from all authorized_keys files it was ever installed in. বাংলা ইঙ্গিত: private key একবার বেরোলেই সেটা মৃত — "মুছে দিলাম, ঠিক আছে" নয়; নতুন জোড়া বানানোই একমাত্র উত্তর।

Q3. Your .bashrc has module load gcc/12 and an echo "welcome". Suddenly scp and rsync to this machine fail with protocol errors while interactive ssh works. Diagnose.

Solution: Non-interactive SSH sessions (which scp/rsync use) also read .bashrc on many systems — any output (echo) corrupts the scp/rsync protocol stream. Fix: guard output with case $- in *i*) echo "welcome";; esac (or [[ $- == *i* ]] || return early), keeping non-interactive startup silent. বাংলা ইঙ্গিত: "interactive ssh চলে, scp ভাঙে" = .bashrc-তে কিছু প্রিন্ট হচ্ছে — classic সমস্যা; নিয়ম: non-interactive পথে কোনো echo নয়।

Q4. Combine with Ch 9: one command on your LAPTOP that runs gnuplot remotely on the cluster's fresh data and brings back only the PNG.

Solution:

ssh hpc 'cd $WORK/sim01 && gnuplot plot.gp' && rsync -azP hpc:'$WORK/sim01/residuals.png' .

The && chains remote render then conditional fetch; only the small PNG crosses the network, not the gigabyte data files. বাংলা ইঙ্গিত: "ডেটা যেখানে, গণনা সেখানে" — বড় ফাইল না টেনে ছবি টানো; এই design-যুক্তিটা উত্তরে এক লাইন লিখে দিও।

End of Chapter 4.

Chapter 4: Bashrc, SSH and Remote Workflows¶

1. Chapter Overview¶

2. Basics from Zero¶

3. Hard English Made Easy¶

4. Deep Theory Explanation¶

4.1 Pipes vs Redirection (recap from Ch. 3 and slide 14)¶

4.2 Job control¶

4.3 Environment variables¶

4.4 Aliases and functions¶

4.5 Sourcing vs running¶

4.6 .bashrc, .bash_profile, .profile¶

4.7 Prompt customisation¶

4.8 Networking primer¶

4.9 Cryptography in one slide¶

4.10 SSH protocol — the five steps¶

4.11 Passwordless SSH (top-priority exam topic)¶

4.12 SSH file transfer¶

4.13 Port forwarding¶

4.14 Diagram explanations from V02.1¶

5. Command / Syntax / Code Breakdown¶

export VAR=value¶

alias name='cmd'¶

source ~/.bashrc¶

nohup cmd > log 2>&1 &¶

ssh user@host¶

ssh-keygen -t ed25519 -b 4096 -f ~/.ssh/key¶

ssh-copy-id -i ~/.ssh/key.pub user@host¶

scp [-r] [-P PORT] src dst¶

rsync -avzP --delete src/ user@host:/dst/¶

sshfs user@host:/remote ~/mnt¶

tmux new -s sim / tmux a -t sim¶

6. Mandatory Practical Example¶

Purpose¶

Input¶

Code / Command¶

Expected Output¶

Step-by-Step Explanation¶

7. Real HPC/CFD Workflow¶

8. Exercises and Solutions¶

Exercise 4-A — Pipes vs Redirection¶

Exercise 4-B — Background, nohup, tmux¶

Exercise 4-C — .bashrc snippet¶

Exercise 4-D — Passwordless SSH¶

Exercise 4-E — Compare scp / rsync / sftp / sshfs¶

Exercise 4-F — Port forwarding¶

9. Written Exam Focus¶

9.1 Short Answers¶

9.2 Medium Answers¶

9.3 Long Answer (12 marks)¶

9.4 Output Prediction¶

9.5 Comparison¶

9.6 Templates¶

9.7 Marking Scheme — "scp vs rsync" (5 marks)¶

10. Very Hard Questions¶

11. Debugging and Mistake Analysis¶

12. Mini Project for Mastery¶

13. Final Chapter Cheat Sheet¶

14. Mock Exam — Four Levels¶

Level 1 — Basic (definitions & syntax)¶

Level 2 — Intuitive (predict / explain why)¶

Level 3 — Hard (exam level)¶

Level 4 — Beyond the lecture (transfer + coding)¶

4.6 `.bashrc`, `.bash_profile`, `.profile`¶

`export VAR=value`¶

`alias name='cmd'`¶

`source ~/.bashrc`¶

`nohup cmd > log 2>&1 &`¶

`ssh user@host`¶

`ssh-keygen -t ed25519 -b 4096 -f ~/.ssh/key`¶

`ssh-copy-id -i ~/.ssh/key.pub user@host`¶

`scp [-r] [-P PORT] src dst`¶

`rsync -avzP --delete src/ user@host:/dst/`¶

`sshfs user@host:/remote ~/mnt`¶

`tmux new -s sim` / `tmux a -t sim`¶