הגדרת שרת Ubuntu לאתר הראשון שלכם
המדריך להגדרת שרת Ubuntu מתחיל במכונת Ubuntu 24.04 חדשה ומסתיים באתר סטטי קטן עם Nginx ו-HTTPS. תגדירו משתמש ניהול נפרד, כניסה במפתח SSH, חידוש תעודה ובדיקה שהאתר חוזר לאחר הפעלה מחדש.
VPSuntu · עודכן ב- · כ-6 דקות קריאה
במדריך הזה
מכינים שרת חדש וגישה לשחזור
נדרשת מכונת Ubuntu 24.04 חדשה עם IPv4 ציבורית, SSH בפורט 22 ומשתמש ראשוני בעל sudo. הכינו מתחם שבשליטתכם וגישה לקונסולת שחזור מהימנה של הספק. כאן מוסיפים מפתח בעת יצירת שרת חדש; זו אינה הוראה לשנות גישה באתר קיים.
החליפו את 203.0.113.10 בכתובת השרת ואת app.example.com בשם המארח שלכם. המשתמש הראשוני בדוגמה הוא ubuntu; השתמשו בחשבון הנכון של הספק בכל הפקודות. פקודות מקומיות מיועדות ל-Bash במחשב Linux, macOS או WSL. פקודות שרת מריצים לאחר כניסה. אם נתיב בדוגמה כבר בשימוש, עצרו.
יוצרים מפתח לפני הקמת המכונה
הריצו במחשב שלכם. אם ~/.ssh/ubuntu_vps כבר קיים, בחרו שם אחר והחליפו אותו בכל השלבים. השתמשו בביטוי סיסמה ושמרו את המפתח הפרטי במחשב.
mkdir -p ~/.ssh
ssh-keygen -t ed25519 -f ~/.ssh/ubuntu_vps
cat ~/.ssh/ubuntu_vps.pubצרו את המכונה עם תוכן קובץ .pub בשדה המפתח הציבורי של הספק. ודאו את שם המשתמש הראשוני; את המפתח הפרטי אין להעלות.
מאמתים את זהות השרת לפני הכניסה
תחילה הריצו בקונסולת השחזור המהימנה של המכונה החדשה את בדיקת מפתח המארח הציבורי מסוג Ed25519:
sudo ssh-keygen -lf /etc/ssh/ssh_host_ed25519_key.pubכעת התחברו ממסוף מקומי חדש. השוו אלגוריתם וטביעת אצבע לתוצאה מהקונסולה לפני האישור.
ssh -i ~/.ssh/ubuntu_vps ubuntu@203.0.113.10אם הטביעה שונה, בדקו כתובת ומזהה מכונה. מפתח המארח של השרת אינו מפתח הכניסה הפרטי שלכם. השאירו את דרך השחזור זמינה במהלך שינויי הגישה.
יוצרים מנהל חדש ובודקים כניסה נפרדת
בדקו בשרת getent passwd deploy. לא אמור להיות משתמש קיים בשם זה. אם הוא תפוס, בחרו שם חדש והחליפו בכל הדוגמה שמות, קבוצות ונתיבי בית. כך לא תדרסו מפתחות של חשבון קיים.
ממסוף מקומי נוסף העתיקו את המפתח הציבורי:
scp -i ~/.ssh/ubuntu_vps ~/.ssh/ubuntu_vps.pub ubuntu@203.0.113.10:ubuntu-vps-admin.pubבחיבור המקורי כמשתמש ubuntu הריצו את בדיקות המערכת, עברו על העדכונים וצרו את deploy עם סיסמה חזקה ל-sudo. פקודות install מגדירות בעלות והרשאות מוגבלות לחשבון החדש.
cat /etc/os-release
free -h
df -h /
sudo apt update
sudo apt upgrade
sudo adduser deploy
sudo usermod -aG sudo deploy
sudo install -d -m 700 -o deploy -g deploy /home/deploy/.ssh
sudo install -m 600 -o deploy -g deploy ~/ubuntu-vps-admin.pub /home/deploy/.ssh/authorized_keysפתחו במחשב חיבור נוסף עם המשתמש החדש:
ssh -i ~/.ssh/ubuntu_vps deploy@203.0.113.10בחיבור החדש בדקו sudo. התוצאה צריכה להיות root, לאחר הזנת סיסמה אם התבקשתם. המשיכו רק כאשר הכניסה וההרשאה פועלות, ושמרו גם את החיבור המקורי.
sudo whoamiמתקינים Nginx ומשתמשים בחומת אש מתאימה
כמשתמש הניהול החדש, התקינו בשרת:
sudo apt install nginx
sudo systemctl enable --now nginxברשת של הספק אפשרו TCP בפורט 22 מכתובת הניהול שלכם ופורטים 80 ו-443 למבקרי האתר. אם SSH מוגדר בפורט אחר, שמרו את הפורט האמיתי. גם חומת האש של הספק וגם זו של מערכת ההפעלה צריכות לאפשר את הגישה.
בתמונות Ubuntu של Oracle Cloud דלגו על כל בלוק UFW הבא. שמרו את כללי iptables שסופקו עם התמונה, כולל iSCSI. הגדירו security lists או NSG ברשת OCI ואת כללי HTTP/HTTPS הנתמכים בתוך האורח. UFW עלול להתנגש בהגדרות התמונה ולחסום גישה נחוצה.
בתמונה חדשה אחרת, השתמשו בבלוק רק אם הספק תומך בשיטה הזאת. הדוגמה מניחה SSH בפורט 22; אפשרו את הפורט האמיתי לפני ההפעלה.
sudo apt install ufw
sudo ufw allow 22/tcp
sudo ufw allow 80/tcp
sudo ufw allow 443/tcp
sudo ufw enable
sudo ufw status verboseלאחר כל שינוי גישה, נסו חיבור SSH חדש. חיבור ישן שנשאר פתוח אינו מוכיח שחיבורים חדשים מותרים.
מפרסמים דף בתצורת Nginx נפרדת
ודאו ש-/var/www/first-site וקובץ התצורה המתאים אינם שייכים לאתר קיים. החליפו את שם המארח בתוך הבלוק. שמרו את סמני EOF במירכאות כדי שה-shell לא ירחיב משתנים כמו $uri.
sudo install -d -m 755 /var/www/first-site
printf '%s\n' '<!doctype html><html lang="en"><title>First deployment</title><h1>Ubuntu VPS is serving this page</h1></html>' | sudo tee /var/www/first-site/index.html
sudo tee /etc/nginx/sites-available/first-site >/dev/null <<'EOF'
server {
listen 80;
listen [::]:80;
server_name app.example.com;
root /var/www/first-site;
index index.html;
location / {
try_files $uri $uri/ =404;
}
}
EOF
sudo ln -s /etc/nginx/sites-available/first-site /etc/nginx/sites-enabled/first-site
sudo nginx -tהכותרת האנגלית היא התוכן של קובץ הבדיקה. טענו מחדש את Nginx רק לאחר ש-nginx -t הסתיים ללא שגיאה:
sudo systemctl reload nginxמהמחשב שלכם, בדקו את שם המארח ישירות מול כתובת השרת לפני שינוי DNS:
curl --resolve app.example.com:80:203.0.113.10 http://app.example.com/צריך לראות את כותרת דף הבדיקה ולא את דף ברירת המחדל. אם לא, בדקו server_name, תצורה פעילה וכתובת יעד.
מחברים DNS ומנפיקים תעודת HTTPS
צרו רשומת A ל-IPv4 של השרת. פרסמו AAAA רק אם IPv6 פועלת באותה מכונה. רשומה ישנה עלולה להפנות משתמשים ואת בדיקת התעודה לשרת שגוי. הדוגמה משתמשת ב-DNS ישיר ללא proxy.
מהמחשב, ודאו ש-http://app.example.com/ מציג את דף הבדיקה בלי --resolve. לאחר מכן התקינו בשרת Certbot ואת תוסף Nginx ממאגרי Ubuntu. החבילות דורשות Universe; פתרו בעיית חבילה חסרה לפני המשך.
sudo apt install certbot python3-certbot-nginx
sudo certbot --nginx -d app.example.com --redirect
sudo nginx -t
sudo certbot renew --dry-run
systemctl list-timers --all certbot.timerהשלימו את שאלות הדוא״ל ותנאי השירות של Certbot. הכלי משנה תצורה ומגדיר הפניה ל-HTTPS. בדקו חידוש מתוזמן; אם הטיימר אינו פעיל, הפעילו sudo systemctl enable --now certbot.timer. השאירו פורט 80 נגיש לצורך אימות וחידוש HTTP.
בודקים מבחוץ ולאחר הפעלה מחדש
במחשב המקומי בדקו הפניית HTTP, תעודה תקינה ותוכן. אל תוסיפו curl -k, שמסתיר שגיאות תעודה.
curl -I http://app.example.com/
curl -I https://app.example.com/
curl -fsS https://app.example.com/כשהשרת עדיין בסביבת ניסוי, בצעו בו sudo reboot. התחברו מחדש עם deploy, בדקו systemctl is-active nginx וחזרו על בדיקת HTTPS החיצונית. הפעלה מחדש מנתקת את SSH; אם אין גישה לאחריה, השתמשו בקונסולה.
שומרים תצורה ועותק שניתן לשחזר
במסך קטן ניתן לגלול את הטבלה הצידה כדי לראות את כל העמודות.
| תוצאה לא תקינה | מה לבדוק קודם |
|---|---|
| זמן המתנה ב-SSH | כתובת, שתי חומות האש וקונסולת שחזור |
| מפתח כניסה נדחה | משתמש, מפתח פרטי והרשאות authorized_keys |
| מופיע דף Nginx הרגיל | יעד DNS, server_name ותצורה פעילה |
| אימות תעודה נכשל | רשומות A/AAAA ציבוריות ופורט 80 |
| Nginx לא עולה | nginx -t ויומן השירות |
לבעיות גישה השתמשו באבחון SSH. שמרו קובצי אתר, תצורה, רשומות DNS והוראות הקמה מחוץ לשרת, ותרגלו שחזור קבצים בלי לדרוס את האתר הפעיל.
אם מעתיקים מפתח תעודה פרטי, יש להגן על העותק; אחרת תכננו הנפקה מחדש. הוסיפו ניטור זמינות ותוקף תעודה. המדריך מפרסם קבצים סטטיים בלבד: WordPress, Node.js ומסד נתונים דורשים הגדרות וגיבוי נוספים.
שאלות ותשובות
אפשר להריץ את הדוגמה באתר קיים?
התחילו בשרת בדיקה נפרד. אתר קיים דורש סקירת משתמשים, הרשאות גישה, אתרים ויכולת שחזור לפני שינוי.
חייבים מתחם כדי להתחבר ב-SSH?
לא. SSH יכול להשתמש בכתובת IP. שלב התעודה במדריך דורש שם מתחם שבשליטתכם ו-DNS תקין.
האם מותקן גם מסד נתונים?
לא. התוצאה היא אתר HTTPS סטטי. הוסיפו סביבת ריצה ומסד לאחר שבדקתם את ההתקנה הבסיסית, האתחול והשחזור.