VPS SSH જોડાણની ભૂલો કેવી રીતે સુધારશો?

એક નિષ્ફળ પ્રયાસ નોંધો અને જૂની ઍક્સેસ જાળવો

સફળ SSH session ખુલ્લું રાખો અને provider recovery console શોધો. Client commands કમ્પ્યુટરના Linux/macOS/WSL terminalમાં, server commands હાલના login અથવા authenticated consoleમાં ચલાવો. Server commands local terminalમાં paste ન કરો.

Documentation IP 203.0.113.10, ubuntu account, port 22 અને key pathને સાચી વિગતો આપો. પહેલાં effective client settings જુઓ, પછી એક નવું જોડાણ કરો:

ssh -G -p 22 -i ~/.ssh/ubuntu_vps ubuntu@203.0.113.10
ssh -v -S none -o ConnectTimeout=10 -o StrictHostKeyChecking=ask -p 22 -i ~/.ssh/ubuntu_vps ubuntu@203.0.113.10

Hostname, user, port, identityfile અને proxy settings તપાસો. બીજો command માત્ર આ પ્રયાસ માટે connection sharing બંધ કરે છે. સમય અને અંતિમ error નોંધો. નવા host promptને આગળની identity તપાસથી verify કરો. Debug output શેર કરતાં username, IP અને paths ઢાંકો; private key ક્યારેય ન મોકલો.

Error પ્રમાણે યોગ્ય માર્ગ લો

નાની સ્ક્રીન પર બધા કૉલમ જોવા કોષ્ટકને આડું સરકાવો.

આ observations સંભવિત કારણો ઓછાં કરે છે, એક કારણ સાબિત નથી કરતા. Timeout પહેલાં Connection established દેખાય તો handshake અને server logs તપાસો; બધાં packets block હતા એવું ન માનો.

Timeout: ઇચ્છિત network path તપાસો

Ssh -vમાં destinationને provider panelના current address સાથે સરખાવો. Hostnameમાં જૂનો DNS અથવા જુદો IPv6 destination હોઈ શકે. VPS માટે public IP, VPN કે jump host જરૂરી છે કે નહીં જુઓ.

Instance running અને public routing હાજર છે તે તપાસો. Provider firewallમાં actual SSH destination port અને current public source IP મળતા હોવા જોઈએ. ઘરનો IP બદલાઈ શકે, જૂનો /32 rule નહીં. Consoleથી guest firewall પણ જુઓ.

Oracleમાં security lists, NSG, routing અને guest firewall બધું મહત્વનું છે. Diagnostic તરીકે UFW install કે iptables flush કરશો નહીં. Oracle network setup પ્રમાણે imageના rules જાળવો. Ping નિષ્ફળ થવું એકલું SSH unavailable હોવાનો પુરાવો નથી.

Refused connection: listener જુઓ

Refusal મળવાથી destination તમારો VPS હોવાનું સાબિત થતું નથી. Identity અને port ખાતરી કર્યા પછી serverની હાલની ઍક્સેસ અથવા consoleમાંથી આ read-only checks કરો:

systemctl status ssh.service ssh.socket --no-pager
sudo ss -lntp
sudo /usr/sbin/sshd -t
sudo journalctl -u ssh.service -u ssh.socket --since '15 minutes ago' --no-pager

ઇચ્છિત address/port પર listener અને તમારા પ્રયાસના સમયના logs જુઓ. Ubuntu socket activation વાપરી શકે: ssh.socket listening હોય ત્યારે ssh.service inactive હોવું એકલું SSH unavailable નથી બતાવતું.

Sshd -t daemon શરૂ કર્યા વગર configuration અને host-key validity તપાસે છે. Silent successથી network reachability સાબિત નથી થતી. Error આવે તો ચોક્કસ file/setting શોધો, ત્યાર પછી reload વિચારો; અંધાધૂંધ restart ન કરો.

Public key ન સ્વીકારાય: account અને offered key તપાસો

Providerનું initial account અથવા તમે બનાવેલો admin વાપરો, અંદાજેલું username નહીં. Client debugમાં કયો fingerprint offer થયો છે તે જુઓ. Agentની અસંબંધિત keys ઓછી કરવા કમ્પ્યુટર પર ફરી પ્રયાસ કરો:

ssh -v -S none -o IdentitiesOnly=yes -o StrictHostKeyChecking=ask -p 22 -i ~/.ssh/ubuntu_vps ubuntu@203.0.113.10

Configured IdentityFile entries હજી લાગુ પડી શકે છે, તેથી ssh -G જુઓ. Key unreadable અથવા private file permissions વધુ ખુલ્લી હોય તો પહેલાં local fileની ઍક્સેસ સુધારો, server નહીં.

Server પર target account અને authorized public keys તપાસો. ઉદાહરણ home /home/ubuntu માને છે; getentમાંથી મળેલું સાચું home મૂકો:

getent passwd ubuntu
sudo ls -ld /home/ubuntu /home/ubuntu/.ssh /home/ubuntu/.ssh/authorized_keys
sudo ssh-keygen -lf /home/ubuntu/.ssh/authorized_keys

Authorized અને offered fingerprints સરખાવો. Ownership, permissions અથવા account-policy failures માટે journal જુઓ. Default path ન હોય તો AuthorizedKeysFile, included snippets અને Match rules તપાસો. Provider-managed key service પણ અલગ mechanism આપી શકે. Existing keys જાળવો; કારણ છુપાવવા StrictModes disable કે passwords enable ન કરો.

Host identity બદલાય: પહેલાં verify કરો

Rebuild અથવા ફરી ફાળવાયેલો IP host key બદલી શકે છે. અજાણ્યો ફેરફાર ખોટો endpoint અથવા interception પણ હોઈ શકે. Authenticated provider panelમાંથી instance ID અને planned rebuild ખાતરી કરો.

Guestના trusted consoleમાં client બતાવે તે algorithmની public host key તપાસો. Ed25519 માટે:

sudo ssh-keygen -lf /etc/ssh/ssh_host_ed25519_key.pub -E sha256

SHA256ને client warning સાથે સરખાવો. આ server key છે, તમારી login key કે provider console gatewayની key નહીં. Verified replacement હોય તો પહેલાં known_hosts backup કરો અને માત્ર આ serverની entry સુધારો. અન્ય entries રાખો; આખી file કાઢશો નહીં કે checking bypass કરશો નહીં. Identity સમજાતી ન હોય તો જોડાણ અટકાવી તપાસો.

ચોક્કસ સુધારો નવા sessionમાં ચકાસો

મળેલું ખોટું address, user, key, narrow network rule અથવા configuration સુધારો. Server change દરમિયાન independent access રાખો અને SSH configuration validate કરો. નવો port socket activation settingsને પણ અસર કરી શકે; માત્ર service restart પૂરતો ન હોઈ શકે.

Connection sharing બંધ રાખીને original attempt ફરી કરો. Fresh login expected accountમાં પહોંચે છે અને જરૂરી sudo ચાલે છે તે જુઓ. જૂનું session ચાલુ રહેવું એ જ test નથી. કારણ અને ફેરફાર નોંધો, પછી deployment guide પર પાછા જાઓ.

પ્રશ્નો અને જવાબો

દસ્તાવેજો અને સ્રોતો

• સ્રોત: Ubuntu OpenSSH server documentation
• સ્રોત: OpenSSH client manual
• સ્રોત: OpenSSH client configuration manual
• સ્રોત: OpenSSH server test modes
• સ્રોત: OpenSSH server configuration manual
• સ્રોત: OpenSSH key fingerprint tools
• સ્રોત: Ubuntu 24.04 OpenSSH socket activation
• સ્રોત: Oracle image firewall requirements