מאת Matt Connor 2026-08-10 · עודכן 2026-08-13

תיקון שגיאת SSH Permission denied (publickey)

Q: כיצד אוכל לראות איזה מפתח SSH שולח בפועל?

ssh -v host מדפיס שורת debug1: Offering public key: אחת עבור כל מפתח, ומציין את קובץ המקור ואת ה-fingerprint בפורמט SHA256. ssh-add -l מציג את ה-fingerprints שמוחזקים ב-agent. ssh-keygen -lf ~/.ssh/id_ed25519.pub מדפיס את ה-fingerprint של קובץ מפתח בודד, ו-ssh-keygen -y -f ~/.ssh/id_ed25519 מדפיס את המפתח הציבורי שנגזר בפועל ממפתח פרטי. כדי שההתחברות תצליח, ה-fingerprint משורת ה-Offering חייב להופיע גם ב-ssh-keygen -lf, בהרצה מול ה-authorized_keys של השרת.

Q: מדוע sshd מתעלם מקובץ ה-authorized_keys שלי?

מכיוון ש-StrictModes פעיל כברירת מחדל, והקובץ, ספריית ה-.ssh, או ספריית הבית ניתנים לכתיבה על ידי קבוצה או משתמשים אחרים, או שהם בבעלות חשבון שגוי. sshd לא יבטח בנתיב שמישהו אחר יכול לשנות, ולכן הוא מתנהג כאילו לא קיים מפתח. הגדירו את ספריית הבית ל-755 או מחמיר יותר, את .ssh ל-700, את authorized_keys ל-600, וודאו שכל השלושה בבעלות חשבון המשתמש. עם LogLevel VERBOSE השרת מתעד את Authentication refused: bad ownership or modes for directory /home/deploy/.ssh.

שגיאת Permission denied (publickey) מצביעה על חמש תקלות שונות. הריצו ssh -v כדי לזהות את הסיבה המדויקת ולפתור את הבעיה מבלי לאבד גישה לשרת שלכם באופן קבוע.

מה המשמעות האמיתית של השגיאה Permission denied (publickey)

השגיאה Permission denied (publickey) מציינת שהלקוח שלכם שלח מפתח ציבורי אחד או יותר, אך השרת לא קיבל אף אחד מהם. הרשת תקינה והשירות sshd פועל: הסירוב מתרחש בשלב האחרון של האימות. הפתרון אינו ניחוש, כיוון ש-ssh -v מציג לכם איזו מבין חמש סיבות אפשריות רלוונטית למקרה שלכם.

המילים בתוך הסוגריים הן שיטות האימות שהשרת מוכן לקבל. Permission denied (publickey) לבדו אומר שהתחברות באמצעות סיסמה כבויה בשרת זה, ולכן אין סיסמה שאפשר לחזור אליה כחלופה. Permission denied (publickey,password) אומר שסיסמאות היו זמינות כאופציה, אך נכשלתם גם באימות זה.

הודעה אחת מכסה חמישה כשלים שונים, והיא מעורפלת בכוונה. שרת שהיה משיב "no such user" או "that key is not installed" היה מסייע לכל מי שסורק חשבונות תקפים. לכן, אל תתחילו להחליף מפתחות או לערוך קובצי תצורה. הריצו פקודה אחת, קראו שלוש שורות פלט, וחמש סיבות אפשריות יצטמצמו לאחת.

הריצו תחילה ssh -v, וקראו שלוש שורות

חזרו על הפקודה שנכשלה, בתוספת -v:

ssh -v deploy@203.0.113.10

הרצה מציאותית, לאחר קיצוץ, נראית כך:

OpenSSH_9.6p1 Ubuntu-3ubuntu13, OpenSSL 3.0.13 30 Jan 2024
debug1: Connecting to 203.0.113.10 [203.0.113.10] port 22.
debug1: Connection established.
debug1: Authenticating to 203.0.113.10:22 as 'deploy'
debug1: Authentications that can continue: publickey
debug1: Next authentication method: publickey
debug1: Will attempt key: /home/you/.ssh/id_ed25519 ED25519 SHA256:0eL/8sBw... agent
debug1: Offering public key: /home/you/.ssh/id_ed25519 ED25519 SHA256:0eL/8sBw... agent
debug1: Authentications that can continue: publickey
debug1: No more authentication methods to try.
deploy@203.0.113.10: Permission denied (publickey).

שלוש שורות מכילות את כל המידע הדרוש לכם.

Authenticating to 203.0.113.10:22 as 'deploy' הוא שם המשתמש שישמש בפועל. לא זה שהתכוונתם להשתמש בו: זהו השם ש-ssh הסיק משורת הפקודה, מ-~/.ssh/config, או משם המשתמש המקומי שלכם.

Authentications that can continue: publickey היא רשימת השיטות המקובלות על השרת, שנשלחת לפני ניסיון שימוש במפתח כלשהו. אם publickey חסר מהרשימה הראשונית הזו, השרת ביטל את האפשרות להתחברות באמצעות מפתח ציבורי, ולכן שום מפתח לא יעבוד.

Offering public key: ... היא שורה אחת עבור כל מפתח שהלקוח שלכם שלח בפועל, המציינת את שם הקובץ שממנו הגיע ואת ה-fingerprint מסוג SHA256 שלו. מפתח ללא שורת Offering לא נשלח מעולם לשרת.

כעת חלקו את הבעיה לשניים:

אין שורת Offering public key עבור המפתח שאתם מצפים לו. התקלה היא במחשב שלכם, כיוון שהשרת לא ראה את המפתח שלכם כלל.
המפתח מוצע ו-Authentications that can continue: publickey חוזר שוב. השרת קיבל את המפתח וסירב לו, לכן התקלה היא בשרת.

הסיבות להלן מדורגות לפי תדירות הופעתן כפתרון לבעיה.

סיבה 1: אתם מתחברים עם שם משתמש שגוי

הסיבה הנפוצה ביותר היא גם הפחות מעניינת שבהן. sshd, ה-daemon של שרת ה-SSH (secure shell), לעולם לא יציין בפניכם שחשבון מסוים אינו קיים. הוא מנהל את כל תהליך ההתקשרות עבור שם משתמש מומצא ומסרב בסוף עם אותה הודעה, כיוון שחשיפת שמות משתמש תקפים מסייעת לתוקף. שגיאת הקלדה בשם המשתמש נראית בדיוק כמו מפתח תקול.

בדקו את השורה Authenticating to ... as לפני כל דבר אחר. אם היא מציינת את שם המשתמש של המחשב הנייד שלכם במקום את חשבון השרת, סימן ששכחתם לציין את שם המשתמש בפקודה.

ssh -v deploy@203.0.113.10
ssh -v root@203.0.113.10

חשבון ברירת המחדל תלוי ב-image שהספק שלכם בונה. נכון לאוגוסט 2026, ה-images של Ubuntu בענן כוללים בדרך כלל חשבון ubuntu, ה-images של Debian כוללים את debian או admin, ה-images של Rocky Linux ו-AlmaLinux כוללים את rocky ו-almalinux, וספקי VPS רבים מתקינים את המפתח שלכם ישירות לתוך root. לוח הבקרה של הספק שלכם מתעד איזה חשבון הוא יצר. שום פקודה שמורצת מחוץ לשרת לא יכולה לשאול זאת.

בלוק Host בתוך ~/.ssh/config מגדיר גם הוא את שם המשתמש, והוא גובר על שם המשתמש המקומי שלכם:

Host vps-prod
  HostName 203.0.113.10
  User deploy

אם יצרתם את החשבון בעצמכם ולאחר מכן לא הצלחתם להתחבר אליו, כנראה שהמפתח הותקן עבור משתמש ברירת המחדל של ה-image ומעולם לא הועתק לחשבון החדש. שלב זה הוא חלק מ-עשר הדקות הראשונות ב-VPS חדש, וקל מאוד לדלג עליו.

סיבה 2: המפתח שאתם מנסים לשלוח אינו המפתח שנשלח בפועל

כברירת מחדל, ssh מציע רק את המפתחות שמוחזקים על ידי ssh-agent בתוספת קבוצה קבועה של שמות קבצים בתוך ~/.ssh: id_ed25519, id_ecdsa, id_rsa, וגרסאות ה-hardware וה-DSA של שמות אלו. מפתח שנשמר כ-~/.ssh/vps-prod אינו גלוי ל-ssh עד שתציינו אותו בשמו; זו הסיבה שהפלט המפורט (verbose) אינו מציג עבורו שורת Offering public key.

ציינו את שם הקובץ, ומנעו מהמפתחות של ה-agent לתפוס את מקומו:

ssh -i ~/.ssh/vps-prod -o IdentitiesOnly=yes deploy@203.0.113.10

שימוש ב--i לבדו אינו מספיק כאשר ה-agent מחזיק מפתחות, כיוון ש-ssh עדיין מציע את המפתחות של ה-agent תחילה ואת הקובץ שצוין אחרון. זה משמעותי, כיוון שהשרת סופר כל מפתח שנדחה כנגד MaxAuthTries, שערכו כברירת מחדל הוא 6. agent שמחזיק שבעה מפתחות עלול לנצל את המכסה לפני שהמפתח הנכון שלכם מגיע לתור, ואז ההודעה משתנה ל:

Received disconnect from 203.0.113.10 port 22:2: Too many authentication failures

IdentitiesOnly=yes מגביל את הניסיון לקובץ שהעברתם. הציגו את רשימת המפתחות שה-agent מחזיק באמצעות ssh-add -l, ונקו אותם בעזרת ssh-add -D אם הצטברו בו מפתחות ישנים לאורך שנים. לאחר מכן, רשמו את ההגדרות כדי שההתחברות הבאה לא תהיה תלויה בזכירת דגלים (flags):

Host vps-prod
  HostName 203.0.113.10
  User deploy
  IdentityFile ~/.ssh/vps-prod
  IdentitiesOnly yes

מלכודת נוספת בצד הלקוח: ssh מסרב להשתמש במפתח פרטי שחשבונות אחרים במכונה שלכם יכולים לקרוא. הוא מדפיס אזהרה ואז מתעלם מהמפתח, כך שהמפתח לעולם לא מוצע והשרת לעולם לא רואה אותו:

@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@
@         WARNING: UNPROTECTED PRIVATE KEY FILE!          @
@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@
Permissions 0644 for '/home/you/.ssh/vps-prod' are too open.

chmod 600 ~/.ssh/vps-prod מתקן זאת. העברת מפתח באמצעות התקן USB או שיתוף קבצים ב-Windows היא הדרך הנפוצה שבה ההרשאות (mode) הולכות לאיבוד. היכן מפתחות צריכים להישמר וכיצד לקרוא להם מוסבר ב-יסודות ניהול מפתחות SSH.

סיבה 3: המפתח הציבורי לא הגיע לקובץ authorized_keys

אם ssh -v מראה שהמפתח נשלח אך השרת עדיין מסרב לאפשר כניסה, השאלה הבאה היא האם המפתח אכן נמצא בקובץ ה-authorized_keys של החשבון. פתחו את מסוף הניהול של ספק השרתים כדי לבדוק זאת, שכן לא ניתן להתחבר ב-SSH כדי לבצע את הבדיקה.

sudo ls -l /home/deploy/.ssh/
sudo ssh-keygen -lf /home/deploy/.ssh/authorized_keys

הפקודה ssh-keygen -lf על קובץ authorized_keys מדפיסה טביעת אצבע (fingerprint) אחת לכל רשומה:

256 SHA256:0eL/8sBw... you@laptop (ED25519)
3072 SHA256:9Tq2yZk... old-laptop (RSA)

השוו את הפלט לטביעת האצבע בשורת ה-Offering public key שלכם. אם היא אינה מופיעה ברשימה, המפתח אינו מותקן בחשבון, ללא קשר למה שאתם זוכרים שביצעתם.

ארבע סיבות נפוצות לכך שזה משתבש:

הדבקתם את המפתח הפרטי במקום את תוכן קובץ ה-.pub. שורת מפתח ציבורי מתחילה ב-ssh-ed25519 או ב-ssh-rsa. מפתח פרטי מתחיל ב------BEGIN OPENSSH PRIVATE KEY-----.
ההדבקה נשברה למספר שורות. כל רשומה חייבת להופיע בשורה אחת בלבד; מפתח שבור נקרא כרצף רשומות פגומות ואינו תואם דבר.
המפתח הוכנס ל-/root/.ssh/authorized_keys בזמן שאתם מנסים להתחבר כ-deploy, או להפך. הקובץ הוא אישי לכל חשבון ואין קובץ משותף.
תיבת ה-"add my key" של ספק השרתים כתבה את המפתח למשתמש ברירת המחדל של ה-image בלבד, ולכן לחשבון שיצרתם לאחר מכן יש ספריית .ssh ריקה.

הדרך הבטוחה להוסיף מפתח דרך המסוף, כ-root:

sudo install -d -m 700 -o deploy -g deploy /home/deploy/.ssh
sudo tee -a /home/deploy/.ssh/authorized_keys >/dev/null <<'EOF'
ssh-ed25519 AAAAC3NzaC1lZDI1NTE5AAAAIExampleKeyDataHere you@laptop
EOF
sudo chown deploy:deploy /home/deploy/.ssh/authorized_keys
sudo chmod 600 /home/deploy/.ssh/authorized_keys

הריצו את sudo ssh-keygen -lf /home/deploy/.ssh/authorized_keys שוב לאחר מכן. טביעת האצבע החדשה אמורה כעת להופיע ברשימה. ממכונה שעדיין מאפשרת התחברות עם סיסמה, הפקודה ssh-copy-id -i ~/.ssh/vps-prod.pub deploy@203.0.113.10 מבצעת את אותה עבודה ומגדירה עבורכם את ההרשאות בצורה תקינה.

סיבה 4: מדוע sshd מתעלם מ-authorized_keys כאשר ההרשאות פתוחות מדי

StrictModes yes הוא ערך ברירת המחדל של sshd. תחת הגדרה זו, sshd מסרב לקרוא את authorized_keys אם הקובץ עצמו, הספרייה .ssh, או ספריית הבית של המשתמש ניתנים לכתיבה על ידי מישהו שאינו הבעלים. הסיבה לכך ישירה: אם לקבוצה או לכל משתמש אחר יש הרשאת כתיבה לספריית הבית שלך, כל חשבון בעל גישה כזו יכול להחליף את authorized_keys ולהשתלט על תהליך ההתחברות. sshd מתייחס לנתיב שאינו מהימן כאילו לא קיים בו מפתח כלל.

הלקוח רואה הודעת Permission denied פשוטה. לוג השרת מתעד את הסיבה האמיתית:

Authentication refused: bad ownership or modes for directory /home/deploy/.ssh

או, כאשר הבעיה היא בקובץ עצמו:

Authentication refused: bad ownership or modes for file /home/deploy/.ssh/authorized_keys

מה ש-sshd יקבל:

ספריית הבית: ללא הרשאת כתיבה לקבוצה וללא הרשאת כתיבה לכלל המשתמשים. 755, 750 ו-700 כולם תקינים. 775 ו-777 ייכשלו.
~/.ssh: מצב 700.
~/.ssh/authorized_keys: מצב 600.
בעלות: כל השלושה בבעלות החשבון שאליו אתה מתחבר, ולא בבעלות root.

הבעלות חשובה לא פחות מהמצב (mode). קובץ בתוך /home/deploy/.ssh שבבעלות root ייכשל באותה בדיקה, וזה מה שקורה כאשר יוצרים אותו באמצעות sudo nano ושוכחים להעביר את הבעלות בחזרה. תקן את שניהם בבת אחת:

sudo chown -R deploy:deploy /home/deploy/.ssh
sudo chmod 700 /home/deploy/.ssh
sudo chmod 600 /home/deploy/.ssh/authorized_keys
sudo chmod go-w /home/deploy
ls -ld /home/deploy /home/deploy/.ssh

הפקודה האחרונה מציגה את התוצאה. עליך לוודא הרשאות של drwxr-xr-x או מחמירות יותר על ספריית הבית, ו-drwx------ על .ssh. אם מחרוזות אלו אינן ברורות לך עדיין, קרא את כיצד לקרוא מחרוזת הרשאות כמו drwxr-xr-x לפני שתשנה מצבים בשרת פעיל.

ב-Rocky Linux וב-AlmaLinux, הוסף את SELinux (Security-Enhanced Linux) לרשימת החשודים. ספריית .ssh שנוצרה בדרך לא שגרתית עלולה לשאת תווית קובץ (file label) שגויה, ולכן הגישה לקריאה נמנעת מ-sshd גם אם ההרשאות נראות תקינות. sudo restorecon -Rv /home/deploy/.ssh מחזירה את התוויות למצבן התקין, ו-sudo ausearch -m avc -ts recent מציגה האם SELinux היה הרכיב שחסם את הגישה.

סיבה 5: הגדרות sshd מונעות ממך גישה

קריאת /etc/ssh/sshd_config אינה מספיקה במערכות Ubuntu או Debian מודרניות. הקובץ מתחיל ב-Include /etc/ssh/sshd_config.d/*.conf, ו-OpenSSH תמיד משתמש בערך הראשון שהוא מוצא עבור כל הגדרה. לכן, קובץ drop-in כמו 50-cloud-init.conf נקרא ראשון וגובר על כל שינוי שתבצע בהמשך הקובץ הראשי. זו הסיבה לכך ששינוי עשוי להיראות תקין אך לא להשפיע כלל.

בקש מ-sshd להציג את התצורה שבה הוא משתמש בפועל:

sudo sshd -T | grep -Ei 'pubkeyauth|authorizedkeysfile|permitrootlogin|allowusers|allowgroups|denyusers'

פלט תקין נראה כך:

permitrootlogin prohibit-password
pubkeyauthentication yes
authorizedkeysfile .ssh/authorized_keys .ssh/authorized_keys2

מה לחפש בפלט שלך:

pubkeyauthentication no. שום מפתח לא יתקבל. מצב זה יופיע גם ב-ssh -v כרשימת Authentications that can continue: ראשונה ללא publickey בתוכה.
authorizedkeysfile המצביע למקום אחר, לדוגמה /etc/ssh/authorized_keys/%u. במקרה כזה, הקובץ בתיקיית הבית שלך יתעלם לחלוטין, וכללי ההרשאות מסיבה 4 יחולו על הנתיב החדש במקום.
נוכחות של allowusers או allowgroups. כל חשבון שאינו מופיע ברשימה יידחה עם שגיאה זו בדיוק, ללא הסבר נוסף. denyusers ו-denygroups מבצעים פעולה דומה בהיפוך.
permitrootlogin no בזמן שאתה מנסה להתחבר כ-root. prohibit-password היא ההגדרה המאוזנת והמומלצת: root רשאי להשתמש במפתח, אך לא בסיסמה.

בלוקים של Match אינם מופיעים ב-sshd -T רגיל, כיוון שהתוצאה שלהם תלויה בזהות המתחבר. בדוק עבור חיבור ספציפי:

sudo sshd -T -C user=deploy,host=vps.example.com,addr=198.51.100.7

הגדרה נוספת משפיעה על מפתחות ישנים. החל מגרסה 8.8, OpenSSH הפסיק לקבל חתימות SHA-1 (ssh-rsa) כברירת מחדל, לכן מפתח RSA שעבד במשך שנים עלול להפסיק לעבוד מיד לאחר שדרוג השרת. הלקוח ידווח על כך בבירור:

debug1: send_pubkey_test: no mutual signature algorithm

הפתרון הנכון הוא יצירת מפתח חדש: ssh-keygen -t ed25519 -C "deploy@vps-prod", ולאחר מכן התקנת הקובץ .pub כפי שהוצג לעיל. הגדרת PubkeyAcceptedAlgorithms +ssh-rsa בשרת מאפשרת מחדש את החתימות הישנות ומאפשרת לך להיכנס כעת, אך התייחס לכך כאל פתרון זמני לגישה לשרת, ולא כסיום המשימה. שאר הגדרות השרת שכדאי לבחון נמצאות ב-אבטחת שרת SSH ב-VPS.

כיצד לוודא שמפתח פרטי תואם למפתח ציבורי מותקן

חלק גדול מהניחושים סביב שגיאה זו נובע מחוסר ודאות אם שני קבצים מהווים זוג. פקודה אחת מספקת את התשובה:

ssh-keygen -y -f ~/.ssh/vps-prod

פקודה זו מציגה את המפתח הציבורי שנגזר מהמפתח הפרטי. היא אינה קוראת את קובץ ה-.pub שנמצא לצדו, ולכן היא מציגה את מהות המפתח הפרטי כפי שהיא באמת, ולא כפי שקובץ .pub מיושן טוען. אם למפתח יש passphrase, הפקודה תבקש אותו, מה שמוכיח גם שאתם עדיין יודעים את ה-passphrase.

ssh-keygen -lf ~/.ssh/vps-prod.pub
ssh-add -l

הפקודה הראשונה מציגה את ה-fingerprint של קובץ מפתח ציבורי אחד. השנייה מציגה את ה-fingerprints שסוכן ה-SSH שלכם מחזיק. כעת, השוו בין ארבעה מופעים של אותה מחרוזת: ה-fingerprint בשורת ה-Offering public key מתוך ssh -v, ה-fingerprint של קובץ ה-.pub שלכם, ה-fingerprints בתוך ssh-keygen -lf על גבי ה-authorized_keys של השרת, וה-fingerprint בלוג השרת. הנקודה שבה הם מפסיקים להתאים היא המקור לתקלה.

קריאת לוג השרת בזמן כשל בהתחברות

הלקוח אינו מקבל מידע מועיל במכוון. השרת כותב את הסיבה האמיתית. הפעילו מעקב אחר הלוג בסשן ה-console, ולאחר מכן הריצו את הפקודה ssh שנכשלה מהמחשב הנייד שלכם.

sudo journalctl -u ssh -f

Ubuntu 24.04 אינה מתקינה את rsyslog כברירת מחדל, לכן /var/log/auth.log עשוי שלא להיות קיים שם. ב-Rocky Linux וב-AlmaLinux היחידה נקראת sshd, ואותם רישומים מופיעים גם ב-/var/log/secure.

הגדירו את LogLevel VERBOSE בתצורת ה-sshd וטענו מחדש את השירות. כל ניסיון יתועד כעת עם ה-fingerprint שהשרת קיבל בפועל:

Failed publickey for deploy from 198.51.100.7 port 49812 ssh2: ED25519 SHA256:0eL/8sBw...

שורה זו מציינת באיזה צד נמצא הכשל. אם ה-fingerprint מוכר לכם, סימן שהמפתח הגיע אך נדחה על ידי השרת; עיינו בסיבות 3, 4 ו-5. אם ה-fingerprint אינו מוכר, סימן שהלקוח שלח מפתח שלא התכוונתם לשלוח; חזרו לסיבה 2.

כאשר הלוג עדיין אינו ברור, הריצו מופע sshd שני בפורט אחר במצב debug. הוא יישאר ב-foreground, ישרת חיבור אחד, ידפיס את הניתוח שלו ויסתיים:

sudo /usr/sbin/sshd -ddd -p 2222

מהסשן ב-console באותו שרת, התחברו אליו דרך כתובת ה-loopback:

ssh -p 2222 -i ~/.ssh/vps-prod -o IdentitiesOnly=yes deploy@127.0.0.1

עבודה דרך 127.0.0.1 מוציאה את ה-firewall מחוץ למשוואת הבדיקה. פלט ה-debug מציין את הקובץ שנפתח, את ה-fingerprint שהושווה, ואת סיבת הסירוב המדויקת, כולל שורות כגון Authentication refused: bad ownership or modes for directory /home/deploy. לחצו על Ctrl+C לאחר שתקבלו את התשובה. ה-sshd האמיתי בפורט 22 נותר ללא שינוי לאורך כל התהליך.

כיצד להימנע מחסימת גישה לשרת

כל פעולה של עריכת תצורת השרת מחייבת דרך חלופית לכניסה שאינה תלויה ב-SSH. הגדירו זאת בזמן ש-SSH עדיין עובד, ולא לאחר שהגישה נחסמה.

פתחו את מסוף הניהול (console) של ספק השרת שלכם, דרך serial או VNC (virtual network computing), וודאו שאתם מצליחים להתחבר באמצעותו.
ודאו שאתם מכירים סיסמה מקומית תקינה לחשבון בעל הרשאות sudo. אם אין לכם כזו, אפסו את סיסמת ה-root דרך מסוף הספק תחילה.
השאירו את סשן ה-SSH הנוכחי שלכם פתוח. סשן פעיל שורד systemctl restart ssh, ולכן הוא נשאר דרך חזרה לשרת אם התצורה החדשה שגויה.
בדקו את התחביר לפני ביצוע restart: הפקודה sudo sshd -t לא מדפיסה דבר כאשר הקובץ תקין, ומדפיסה את שם הקובץ ומספר השורה כאשר הוא אינו תקין.
פתחו טרמינל שני והתחברו מחדש לפני סגירת הראשון. תצורה שגויה מונעת התחברויות חדשות אך משאירה את הקיימות פעילות, כך שהסשן שבו אתם נמצאים לא יכול להעיד אם השינוי עבד.

בצעו restart באמצעות sudo systemctl restart ssh ב-Debian וב-Ubuntu, או sudo systemctl restart sshd ב-Rocky Linux וב-AlmaLinux. ב-Ubuntu 24.04 השירות sshd מופעל מתוך socket unit, לכן שינוי ב-Port או ב-ListenAddress מחייב גם sudo systemctl restart ssh.socket לפני שהשינוי ייכנס לתוקף.

FAQ

מדוע אני מקבל שגיאת Permission denied (publickey) למרות שאותו מפתח עובד בשרת אחר?

הסיבה היא שהמפתח תקין, אך משהו בסביבה שלו אינו תקין. הריצו את ssh -v וחפשו את השורה Offering public key. אם המפתח שלכם לא מופיע שם, ssh לא שלח אותו: הקובץ אינו נמצא ב-~/.ssh תחת שם ברירת מחדל והוא לא טעון ב-agent, לכן הוסיפו אותו באמצעות -i /path/to/key -o IdentitiesOnly=yes. אם המפתח מופיע והשרת עדיין מסרב, סימן שהמפתח חסר ב-authorized_keys של החשבון, הנתיב אליו ניתן לכתיבה על ידי קבוצה, או שהגדרות sshd חוסמות את המשתמש. הלוג של השרת מבדיל בין המקרים הללו.

כיצד אוכל לראות איזה מפתח SSH שולח בפועל?

ssh -v host מדפיס שורת debug1: Offering public key: אחת עבור כל מפתח, ומציין את קובץ המקור ואת ה-fingerprint בפורמט SHA256. ssh-add -l מציג את ה-fingerprints שמוחזקים ב-agent. ssh-keygen -lf ~/.ssh/id_ed25519.pub מדפיס את ה-fingerprint של קובץ מפתח בודד, ו-ssh-keygen -y -f ~/.ssh/id_ed25519 מדפיס את המפתח הציבורי שנגזר בפועל ממפתח פרטי. כדי שההתחברות תצליח, ה-fingerprint משורת ה-Offering חייב להופיע גם ב-ssh-keygen -lf, בהרצה מול ה-authorized_keys של השרת.

מדוע sshd מתעלם מקובץ ה-authorized_keys שלי?

מכיוון ש-StrictModes פעיל כברירת מחדל, והקובץ, ספריית ה-.ssh, או ספריית הבית ניתנים לכתיבה על ידי קבוצה או משתמשים אחרים, או שהם בבעלות חשבון שגוי. sshd לא יבטח בנתיב שמישהו אחר יכול לשנות, ולכן הוא מתנהג כאילו לא קיים מפתח. הגדירו את ספריית הבית ל-755 או מחמיר יותר, את .ssh ל-700, את authorized_keys ל-600, וודאו שכל השלושה בבעלות חשבון המשתמש. עם LogLevel VERBOSE השרת מתעד את Authentication refused: bad ownership or modes for directory /home/deploy/.ssh.

המפתח שלי הפסיק לעבוד מיד לאחר שדרוג שרת. מה השתנה?

אם מדובר במפתח RSA, סביר להניח שמדובר בשינוי הקשור ל-SHA-1. גרסת OpenSSH 8.8 ביטלה את השימוש בחתימות ssh-rsa SHA-1 כברירת מחדל, ולכן מפתח שיכול לחתום רק בדרך זו נדחה כעת. הפלט המפורט של הלקוח יציג debug1: send_pubkey_test: no mutual signature algorithm. צרו מפתח מודרני באמצעות ssh-keygen -t ed25519 והתקינו את קובץ ה-.pub שלו. אם אתם זקוקים לגישה מיידית, PubkeyAcceptedAlgorithms +ssh-rsa בשרת יאפשר מחדש את החתימות הישנות, ועליכם להסיר שורה זו ברגע שהמפתח החדש יעבוד.

ערכתי את sshd_config ועכשיו אני לא מצליח להתחבר כלל. איך אוכל לחזור פנימה?

השתמשו במסוף (console) של ספק השרת שלכם, שאינו עובר דרך SSH. התחברו שם עם סיסמה מקומית, הריצו את sudo sshd -t כדי לראות את שגיאת ה-syntax ומספר השורה שלה, בטלו את השינוי, ואתחלו את השירות. לאחר מכן בדקו את sudo sshd -T כדי לוודא את הערכים הפעילים, כיוון שקובץ ב-/etc/ssh/sshd_config.d/ עשוי לדרוס את התצורה הראשית. אם אין לכם סיסמה מקומית, אפסו תחילה את סיסמת ה-root מהמסוף, ולאחר מכן תקנו את הקובץ.

#ssh#openssh#troubleshooting #permissions #vps