Ubuntu VPS ನಲ್ಲಿ SSH ಸಂಪರ್ಕ ಸಮಸ್ಯೆ ಪರಿಹಾರ

ಇವುಗಳನ್ನು ಸ್ಥಳೀಯ ಶೆಲ್‌ನಲ್ಲಿ ರನ್ ಮಾಡಿ. ssh -V ಕ್ಲೈಂಟ್ ಅನ್ನು ಗುರುತಿಸುತ್ತದೆ; ಆಯ್ಕೆಮಾಡಿದ ಖಾಸಗಿ ಕೀಲಿಯು ಅಸ್ತಿತ್ವದಲ್ಲಿದೆಯೇ ಮತ್ತು ಅದರ ಅನುಮತಿಗಳನ್ನು ಫೈಲ್ ಪಟ್ಟಿಯು ತೋರಿಸುತ್ತದೆ. ಖಾಸಗಿ-ಕೀ ವಿಷಯಗಳನ್ನು ಮುದ್ರಿಸುವುದಿಲ್ಲ.

ssh -V
ssh_address='203.0.113.10'
ssh_user='ubuntu'
ssh_port='22'
ssh_key="$HOME/.ssh/ubuntu_vps"
ls -l "$ssh_key"
ssh -G -p "$ssh_port" -i "$ssh_key" "$ssh_user@$ssh_address"
date -u '+%Y-%m-%dT%H:%M:%SZ'
ssh -v -S none -o ConnectTimeout=10 -o StrictHostKeyChecking=ask -p "$ssh_port" -i "$ssh_key" "$ssh_user@$ssh_address"

ಐಚ್ಛಿಕ ನೇರ TCP ಚೆಕ್, ನಿಮ್ಮ ಕ್ಲೈಂಟ್ ಈಗಾಗಲೇ ನೆಟ್‌ಕ್ಯಾಟ್ ಹೊಂದಿದ್ದರೆ:

nc -vz -w 5 "$ssh_address" "$ssh_port"

ಯಶಸ್ವಿ TCP ಪರಿಶೀಲನೆಯು ಪೋರ್ಟ್ ಅನ್ನು ಮಾತ್ರ ತಲುಪುತ್ತದೆ. ಇದು SSH, ಹೋಸ್ಟ್ ಗುರುತು ಅಥವಾ ನಿಮ್ಮ ಲಾಗಿನ್ ಅನ್ನು ಪರಿಶೀಲಿಸುವುದಿಲ್ಲ. ಜಂಪ್-ಹೋಸ್ಟ್ ಮಾರ್ಗಕ್ಕಾಗಿ, ಈ ನೇರ ತನಿಖೆಯು ಪ್ರಾಕ್ಸಿಜಂಪ್ ಅನ್ನು ಅನುಸರಿಸುವುದಿಲ್ಲ.

Windows OpenSSH ಕ್ಲೈಂಟ್ ಅನ್ನು ಬಳಸಿ. Get-Command ssh ಅನ್ನು ಕಂಡುಹಿಡಿಯಲಾಗದಿದ್ದರೆ, OpenSSH ಕ್ಲೈಂಟ್ ಐಚ್ಛಿಕ ವೈಶಿಷ್ಟ್ಯವನ್ನು ಸ್ಥಾಪಿಸಿ; ಸಂಪರ್ಕಿಸಲು ವಿಂಡೋಸ್ SSH ಸರ್ವರ್ ಅಗತ್ಯವಿಲ್ಲ. ಕೆಳಗಿನವುಗಳನ್ನು ಪವರ್‌ಶೆಲ್‌ನಲ್ಲಿ ರನ್ ಮಾಡಿ, ರಿಮೋಟ್ Ubuntu ಶೆಲ್‌ನಲ್ಲಿ ಅಲ್ಲ.

Get-Command ssh
ssh -V
$sshAddress = '203.0.113.10'
$sshUser = 'ubuntu'
$sshPort = 22
$sshKey = Join-Path $env:USERPROFILE '.ssh\ubuntu_vps'
Get-Item -LiteralPath $sshKey
Get-Acl -LiteralPath $sshKey | Format-List Owner,AccessToString
ssh -G -p $sshPort -i "$sshKey" "$sshUser@$sshAddress"
Test-NetConnection -ComputerName $sshAddress -Port $sshPort -InformationLevel Detailed
(Get-Date).ToUniversalTime().ToString('o')
ssh -v -S none -o ConnectTimeout=10 -o StrictHostKeyChecking=ask -p $sshPort -i "$sshKey" "$sshUser@$sshAddress"

ರಿಮೋಟ್ ವಿಳಾಸವನ್ನು ಪರಿಶೀಲಿಸಿ ಮತ್ತು TcpTest ಯಶಸ್ವಿಯಾಗಿದೆ. ನಿಜ ಎಂದರೆ ಆ ನೇರ ಮಾರ್ಗದಲ್ಲಿ TCP ಸಂಪರ್ಕಗೊಂಡಿದೆ; ಇದು ಹೋಸ್ಟ್-ಕೀ ಅಥವಾ ದೃಢೀಕರಣ ಪರಿಶೀಲನೆ ಅಲ್ಲ. ಕಾಣೆಯಾದ ಫೈಲ್ ಅಥವಾ ACL ದೋಷವು Windows ಗೆ ಸ್ಥಳೀಯವಾಗಿದೆ. ನಿಖರವಾದ ಖಾಸಗಿ ಫೈಲ್‌ನ ಮಾಲೀಕತ್ವ/ಪ್ರವೇಶವನ್ನು ಪರಿಶೀಲಿಸಿ; Linux chmod ಆಜ್ಞೆಗಳನ್ನು PowerShell ಗೆ ಅಂಟಿಸಬೇಡಿ.

ನಿಮ್ಮ ಕೆಲಸ ಮಾಡುವ ಕ್ಲೈಂಟ್ ಪುಟ್ಟಿ ಆಗಿದ್ದರೆ, ಅದರ .ppk ಕೀ ವಿಭಿನ್ನ ಸ್ವರೂಪವಾಗಿದೆ. ಕ್ಲೈಂಟ್‌ಗಳನ್ನು ಬದಲಾಯಿಸುವಾಗ ಹೊಸ ಸಂರಕ್ಷಿತ ಫೈಲ್‌ಗೆ OpenSSH ಖಾಸಗಿ ಕೀಲಿಯನ್ನು ರಫ್ತು ಮಾಡಲು ಸ್ಥಳೀಯವಾಗಿ PutTYgen ಅನ್ನು ಬಳಸಿ. ಮೂಲವನ್ನು ಸಂರಕ್ಷಿಸಿ ಮತ್ತು ಖಾಸಗಿ-ಕೀ ಫೈಲ್ ಅನ್ನು ಎಂದಿಗೂ ಅಪ್‌ಲೋಡ್ ಮಾಡಬೇಡಿ.

ಗುರಿಗೆ ನೇರ TCP ಸಂಪರ್ಕದ ಮೊದಲು ಹೆಸರು-ರೆಸಲ್ಯೂಶನ್ ದೋಷ ಸಂಭವಿಸುತ್ತದೆ. ಮುದ್ರಣದೋಷ ಅಥವಾ ತಪ್ಪಿಸಿಕೊಂಡಿರುವ SSH ಅಲಿಯಾಸ್ ಅನ್ನು ಮೊದಲು ಸರಿಪಡಿಸಿ. ssh -G ಪರೀಕ್ಷಿಸಿ: ಹೋಸ್ಟ್ ಬ್ಲಾಕ್ ಮತ್ತೊಂದು ಬಳಕೆದಾರಹೆಸರು, ಕೀ, ಪೋರ್ಟ್ ಅಥವಾ ಪ್ರಾಕ್ಸಿಜಂಪ್ ಅನ್ನು ಆಯ್ಕೆ ಮಾಡಬಹುದು, ಆದ್ದರಿಂದ "IP ವರ್ಕ್ಸ್" ಸ್ವತಃ ಮುರಿದ DNS ಅನ್ನು ಸಾಬೀತುಪಡಿಸುವುದಿಲ್ಲ.

ಮೌಲ್ಯಮಾಪನ ಮಾಡಲಾದ ಹೋಸ್ಟ್ ಹೆಸರು ಮತ್ತು ಡೀಬಗ್ ಔಟ್‌ಪುಟ್ ಮೂಲಕ ತೋರಿಸಿರುವ ನಿಜವಾದ ವಿಳಾಸವನ್ನು ಹೋಲಿಕೆ ಮಾಡಿ. ಹೋಸ್ಟ್‌ಹೆಸರು A ಮತ್ತು AAAA ದಾಖಲೆಗಳನ್ನು ಹೊಂದಿದ್ದರೆ, ಒಂದೇ ಖಾತೆ, ಪೋರ್ಟ್ ಮತ್ತು ಕೀಲಿಯೊಂದಿಗೆ ಒಂದು ssh -4 ಮತ್ತು ಒಂದು ssh -6 ಪ್ರಯತ್ನವನ್ನು ಹೋಲಿಕೆ ಮಾಡಿ. IPv6 ಗೆ ತನ್ನದೇ ಆದ ಕೆಲಸದ ಮಾರ್ಗ, ಕೇಳುಗ ಮತ್ತು ನಿಯಮಗಳ ಅಗತ್ಯವಿದೆ. ಜಂಪ್ ಹೋಸ್ಟ್‌ನೊಂದಿಗೆ, ಹೆಸರು ರೆಸಲ್ಯೂಶನ್ ಮತ್ತು ಗುರಿ ಸಂಪರ್ಕವು ಅಲ್ಲಿ ಸಂಭವಿಸಬಹುದು; ಸ್ಥಳೀಯ DNS ಪರಿಶೀಲನೆಯು ಸಂಪೂರ್ಣ ಮಾರ್ಗವಲ್ಲ.

ಮುಂದಿನ ಕ್ರಿಯೆ: ಒಂದು ಹೊಂದಿಕೆಯಾಗದ ಸೆಟ್ಟಿಂಗ್ ಅಥವಾ ಹಳೆಯ ದಾಖಲೆಯನ್ನು ಸರಿಪಡಿಸಿ. ಬೇರೆ ಗಮ್ಯಸ್ಥಾನವನ್ನು ಮರೆಮಾಡಲು ಜಾಗತಿಕವಾಗಿ ಕಾರ್ಯನಿರ್ವಹಿಸುವ IPv6 ಅನ್ನು ತೆಗೆದುಹಾಕಬೇಡಿ.

ಈ ಸಂದೇಶಗಳು ಕ್ಲೈಂಟ್‌ನ ಸ್ಥಳೀಯ ಕೀಗೆ ಸಂಬಂಧಿಸಿವೆ. ಸಂಪೂರ್ಣ ಉಲ್ಲೇಖಿಸಿದ ಮಾರ್ಗ, ಫೈಲ್ ಹೆಸರು ಮತ್ತು ಫೈಲ್ ಮಾಲೀಕರನ್ನು ಪರಿಶೀಲಿಸಿ. ಒದಗಿಸುವವರಿಗೆ ಅಪ್‌ಲೋಡ್ ಮಾಡಲಾದ ಸಾರ್ವಜನಿಕ ಕೀಲಿಗಿಂತ ಖಾಸಗಿ ಕೀ ವಿಭಿನ್ನವಾಗಿದೆ. ಖಾಸಗಿ ಕೀಲಿಯನ್ನು ಈ ಪುಟಕ್ಕೆ ಅಥವಾ ಬೆಂಬಲ ಸಂದೇಶಗಳಿಗೆ ಎಂದಿಗೂ ಅಂಟಿಸಬೇಡಿ.

Linux/macOS/WSL ನಲ್ಲಿ, ls -l ನೊಂದಿಗೆ ಫೈಲ್ ಮಾಲೀಕರು ಮತ್ತು ಮೋಡ್ ಅನ್ನು ಪರೀಕ್ಷಿಸಿ. ನೀವು ಹೊಂದಿರುವ ಸಾಮಾನ್ಯ ಖಾಸಗಿ ಫೈಲ್‌ಗಾಗಿ, ಮೋಡ್ 600 ಅದರ ಮಾಲೀಕರಿಗೆ ಪ್ರವೇಶವನ್ನು ನಿರ್ಬಂಧಿಸುತ್ತದೆ; ಪರಿಶೀಲಿಸಿದ ಫೈಲ್‌ಗೆ ಮಾತ್ರ ಅನುಮತಿ ಬದಲಾವಣೆಯನ್ನು ಅನ್ವಯಿಸಿ. ವಿಂಡೋಸ್ ಬ್ಯಾಷ್ ಅನುಮತಿಗಳ ಬದಲಿಗೆ ಫೈಲ್ ACL ಗಳನ್ನು ಬಳಸುತ್ತದೆ. ಸ್ವರೂಪವು ಅಮಾನ್ಯವಾಗಿದ್ದರೆ, ಫೈಲ್ ಅನ್ನು ಮೊಟಕುಗೊಳಿಸಲಾಗಿದೆಯೇ, ಸಾರ್ವಜನಿಕ ಕೀ ಅಥವಾ OpenSSH ಫಾರ್ಮ್ಯಾಟ್‌ಗೆ ಸ್ಥಳೀಯ ರಫ್ತು ಅಗತ್ಯವಿರುವ ಪುಟ್ಟಿ PPK ಫೈಲ್ ಅನ್ನು ಪರಿಶೀಲಿಸಿ. ಮೂಲವನ್ನು ಸಂರಕ್ಷಿಸಿ; ವಿಸ್ತರಣೆಯನ್ನು ಬದಲಾಯಿಸುವುದು ಅದನ್ನು ಪರಿವರ್ತಿಸುವುದಿಲ್ಲ.

ಮುಂದಿನ ಕ್ರಿಯೆ: ಕೀಯನ್ನು ಓದಬಹುದಾದ ನಂತರ ಮರುಪ್ರಯತ್ನಿಸಿ. ಸ್ಥಳೀಯ ಓದುವ ದೋಷವನ್ನು ನಿಗ್ರಹಿಸಲು ಕೀಗಳನ್ನು ಮರುಸೃಷ್ಟಿಸಬೇಡಿ ಅಥವಾ ಸರ್ವರ್‌ನ ಅಧಿಕೃತ ಕೀಗಳನ್ನು ಬದಲಾಯಿಸಬೇಡಿ.

ಸರ್ವರ್ ದೃಢೀಕರಣ ಪ್ರಯತ್ನಗಳನ್ನು ಕೊನೆಗೊಳಿಸಿದೆ. ಅನೇಕ ಸಂಬಂಧವಿಲ್ಲದ ಕೀಗಳನ್ನು ನೀಡುವ ಏಜೆಂಟ್ ಒಂದು ಸಂಭವನೀಯ ಕಾರಣವಾಗಿದೆ, ಖಚಿತತೆಯಲ್ಲ. ನೀಡಲಾದ ಫಿಂಗರ್‌ಪ್ರಿಂಟ್‌ಗಳನ್ನು ಪರೀಕ್ಷಿಸಿ ಮತ್ತು existing-ಕೀ ಪ್ರಯತ್ನವನ್ನು IdentitiesOnly ನೊಂದಿಗೆ ಬಳಸಿ. ಸ್ಪಷ್ಟ ಐಡೆಂಟಿಟಿಫೈಲ್ ನಮೂದುಗಳು ಇನ್ನೂ ಗುರುತುಗಳನ್ನು ಸೇರಿಸಬಹುದು; ssh -G ಅನ್ನು ಸಹ ಪರೀಕ್ಷಿಸಿ.

ಅತಿಥಿ ಪ್ರವೇಶದೊಂದಿಗೆ: ಹೊಂದಾಣಿಕೆಯ ಲಾಗ್ ನಮೂದು ಮತ್ತು ಅನ್ವಯವಾಗುವ MaxAuthTries ನೀತಿಯನ್ನು ಪರಿಶೀಲಿಸಿ. ಅನಗತ್ಯ ಪ್ರಯತ್ನಗಳನ್ನು ಗುರುತಿಸುವ ಮೊದಲು ಪುನರಾವರ್ತಿತ ಮರುಪ್ರಯತ್ನಗಳನ್ನು ಅಥವಾ ಮಿತಿಯನ್ನು ಹೆಚ್ಚಿಸುವುದನ್ನು ತಪ್ಪಿಸಿ.

ಒಂದು ಪೂರ್ವ-ದೃಢೀಕರಣದ ಸಂಪರ್ಕ ಕಡಿತವು ಅಂತ್ಯಬಿಂದು, ನೆಟ್‌ವರ್ಕ್ ಮಧ್ಯವರ್ತಿ ಅಥವಾ ಪ್ರವೇಶ ನಿಯಮದಿಂದ ಬರಬಹುದು. ಪಠ್ಯ ಮಾತ್ರ ಯಾವುದನ್ನು ಗುರುತಿಸುವುದಿಲ್ಲ. ಕೊನೆಯ ಡೀಬಗ್ ಲೈನ್‌ಗಳು ಮತ್ತು ಒಂದು ಟೈಮ್‌ಸ್ಟ್ಯಾಂಪ್ ಅನ್ನು ಸೆರೆಹಿಡಿಯಿರಿ. ಉದ್ದೇಶಿತ ಪೋರ್ಟ್‌ನಲ್ಲಿ ನೀವು SSH ಅನ್ನು ತಲುಪುತ್ತಿರುವಿರಿ ಎಂದು ದೃಢೀಕರಿಸಿ, ನಂತರ ಪೂರೈಕೆದಾರರ ಭದ್ರತಾ ಘಟನೆಗಳು ಮತ್ತು ಅತಿಥಿ SSH ಜರ್ನಲ್ ಅನ್ನು ಪ್ರವೇಶಿಸಬಹುದಾದಲ್ಲಿ ಪರಸ್ಪರ ಸಂಬಂಧಿಸಿ.

ದೋಷವು ಯಾವುದೇ ಹೊಂದಾಣಿಕೆಯ ಕೀ-ವಿನಿಮಯ, ಹೋಸ್ಟ್-ಕೀ ಅಥವಾ ಸೈಫರ್ ಅಲ್ಗಾರಿದಮ್ ಅನ್ನು ಸ್ಪಷ್ಟವಾಗಿ ಹೇಳಿದರೆ, ಕ್ಲೈಂಟ್/ಸರ್ವರ್ ಆವೃತ್ತಿಗಳು ಮತ್ತು ಅನ್ವಯವಾಗುವ ಭದ್ರತಾ ನೀತಿಯನ್ನು ಹೋಲಿಕೆ ಮಾಡಿ. ಬೆಂಬಲಿತ ಹೊಂದಾಣಿಕೆಯ ಕಾನ್ಫಿಗರೇಶನ್‌ಗೆ ಆದ್ಯತೆ ನೀಡಿ. ಬಳಕೆಯಲ್ಲಿಲ್ಲದ ಅಲ್ಗಾರಿದಮ್‌ಗಳನ್ನು ಸಾರ್ವತ್ರಿಕವಾಗಿ ಸಕ್ರಿಯಗೊಳಿಸಬೇಡಿ. ಲಾಗ್‌ಗಳು ಬದಲಿಗೆ ಮೂಲ ಬ್ಲಾಕ್ ಅಥವಾ ಸಂಪರ್ಕ ಮಿತಿಯನ್ನು ಗುರುತಿಸಿದರೆ, ಆ ನಿರ್ದಿಷ್ಟ ಸ್ಥಿತಿಯನ್ನು ಸರಿಪಡಿಸಿ; ಜಾಗತಿಕವಾಗಿ ಫೈರ್‌ವಾಲ್ ಅನ್ನು ಫ್ಲಶ್ ಮಾಡಬೇಡಿ ಅಥವಾ ರಕ್ಷಣೆಯನ್ನು ನಿಷ್ಕ್ರಿಯಗೊಳಿಸಬೇಡಿ.

Authenticated to ಸಂದೇಶವು ದೃಢೀಕರಣದ ನಂತರ ವೈಫಲ್ಯವನ್ನು ಇರಿಸುತ್ತದೆ. Server accepts key ಮಾತ್ರ ಮಾಡುವುದಿಲ್ಲ. ಮೊದಲು SFTP, ರಿಮೋಟ್ ಕಮಾಂಡ್, ಪೋರ್ಟ್ ಫಾರ್ವರ್ಡ್ ಅಥವಾ ssh -N ನಿಂದ ಸಂವಾದಾತ್ಮಕ ಶೆಲ್ ಅನ್ನು ಪ್ರತ್ಯೇಕಿಸಿ, ಇದು ಉದ್ದೇಶಪೂರ್ವಕವಾಗಿ ಯಾವುದೇ ರಿಮೋಟ್ ಆಜ್ಞೆಯನ್ನು ಪ್ರಾರಂಭಿಸುವುದಿಲ್ಲ.

ಅತಿಥಿ ಪ್ರವೇಶದೊಂದಿಗೆ: getent passwd ubuntu ನೊಂದಿಗೆ ಹೊಂದಾಣಿಕೆಯ ಸೆಷನ್ ಲಾಗ್ ಮತ್ತು ಗುರಿ ಖಾತೆಯನ್ನು ಪರೀಕ್ಷಿಸಿ (ಬಳಕೆದಾರ ಹೆಸರನ್ನು ಬದಲಾಯಿಸಿ). ಅದರ ಉದ್ದೇಶಿತ ಶೆಲ್/ಹೋಮ್, ಅನ್ವಯವಾಗುವ ForceCommand, PermitTTY ಮತ್ತು ChrootDirectory ಮತ್ತು ನಿರ್ದಿಷ್ಟ ಅಧಿಕೃತ ಕೀ ಅಥವಾ ಪ್ರಮಾಣಪತ್ರದ ಮೇಲಿನ ನಿರ್ಬಂಧಗಳನ್ನು ಪರಿಶೀಲಿಸಿ. ಫಾರ್ವರ್ಡ್-ಚಾನೆಲ್ ವೈಫಲ್ಯಕ್ಕೆ ತನ್ನದೇ ಆದ ಫಾರ್ವರ್ಡ್ ಮಾಡುವಿಕೆ/ಗಮ್ಯಸ್ಥಾನ ಪರಿಶೀಲನೆಗಳ ಅಗತ್ಯವಿದೆ; ಲಾಗಿನ್ ವಿಫಲವಾಗಿದೆ ಎಂದು ಇದು ಸಾಬೀತುಪಡಿಸುವುದಿಲ್ಲ.

ಲಾಗ್ ಪೂರ್ಣ ಫೈಲ್‌ಸಿಸ್ಟಮ್, ಐನೋಡ್ ನಿಶ್ಯಕ್ತಿ ಅಥವಾ ಪ್ರಕ್ರಿಯೆ/ಮೆಮೊರಿ ವೈಫಲ್ಯವನ್ನು ವರದಿ ಮಾಡಿದರೆ, ಆ ಸಂಪನ್ಮೂಲವನ್ನು df -h, df -i, free -h ಮತ್ತು ಸಂಬಂಧಿತ ಜರ್ನಲ್‌ನೊಂದಿಗೆ ಪರೀಕ್ಷಿಸಿ. ಇವುಗಳು ಅವಲೋಕನಗಳಾಗಿವೆ, ಕಾರಣದ ಪುರಾವೆ ಅಲ್ಲ. ಯಾದೃಚ್ಛಿಕವಾಗಿ ಡೇಟಾವನ್ನು ಅಳಿಸದೆ ಅಥವಾ ಉದ್ದೇಶಪೂರ್ವಕ ಖಾತೆ ನಿರ್ಬಂಧಗಳನ್ನು ತೆಗೆದುಹಾಕದೆಯೇ ದೃಢಪಡಿಸಿದ ನೀತಿ, ಮಾರ್ಗ ಅಥವಾ ಸಂಪನ್ಮೂಲ ಸ್ಥಿತಿಯನ್ನು ಸರಿಪಡಿಸಿ.

systemctl cat ssh.service ssh.socket --no-pager
systemctl show ssh.service -p ActiveState -p MainPID -p ExecStart -p FragmentPath -p DropInPaths -p NeedDaemonReload --no-pager
systemctl show ssh.socket -p ActiveState -p Listen -p FragmentPath -p DropInPaths -p NeedDaemonReload --no-pager
sudo ps -C sshd -o pid,ppid,args

cat ಯುನಿಟ್ ಫೈಲ್‌ಗಳನ್ನು ಮತ್ತು ಡಿಸ್ಕ್‌ನಲ್ಲಿ ಡ್ರಾಪ್-ಇನ್‌ಗಳನ್ನು ತೋರಿಸುತ್ತದೆ. show ಸಾಕೆಟ್ ಆಲಿಸಿ ಮತ್ತು ಕಾನ್ಫಿಗರ್ ಮಾಡಲಾದ ಸೇವೆಯ ಪ್ರಾರಂಭವನ್ನು ಒಳಗೊಂಡಂತೆ ನಿರ್ವಾಹಕರ ಲೋಡ್ ಮಾಡಲಾದ ಗುಣಲಕ್ಷಣಗಳನ್ನು ವರದಿ ಮಾಡುತ್ತದೆ. NeedDaemonReload=ಹೌದು ಲೋಡ್ ಆಗುವುದರಿಂದ ಯುನಿಟ್-ಫೈಲ್ ಬದಲಾವಣೆಯನ್ನು ಸೂಚಿಸುತ್ತದೆ; ಇದು ಒಂದು ವೀಕ್ಷಣೆಯಾಗಿದೆ, ಕುರುಡಾಗಿ ಮರುಲೋಡ್ ಮಾಡಲು ಒಂದು ಕಾರಣವಲ್ಲ. ಸಂಪರ್ಕ ಪ್ರಕ್ರಿಯೆಗಳಿಂದ ಡೀಮನ್ ಅನ್ನು ಪ್ರತ್ಯೇಕಿಸಲು MainPID ಮತ್ತು ಪ್ರಕ್ರಿಯೆ ಪಟ್ಟಿಯನ್ನು ಬಳಸಿ. ಆ ಕ್ಷಣದಲ್ಲಿ ಯಾವುದೇ ಚಾಲನೆಯಲ್ಲಿರುವ ಡೀಮನ್ ಸಾಕೆಟ್ ಸಕ್ರಿಯಗೊಳಿಸುವಿಕೆಯೊಂದಿಗೆ ಸಾಮಾನ್ಯವಾಗಿರುವುದಿಲ್ಲ.

Ubuntuನ ಸಾಕೆಟ್ ನಡವಳಿಕೆಯು ಬಿಡುಗಡೆಯಾದ್ಯಂತ ಬದಲಾಗಿದೆ; Ubuntu 24.04 ಪೋರ್ಟ್ ಮತ್ತು ಲಿಸ್ಟೆನ್ ಅಡ್ರೆಸ್ ಅನ್ನು ಓದುವ ಜನರೇಟರ್ ಅನ್ನು ಪರಿಚಯಿಸಿತು. ಈ ಯಂತ್ರದಲ್ಲಿ ನಿಜವಾದ ಮೋಡ್ ಮತ್ತು ಅತಿಕ್ರಮಣಗಳನ್ನು ನಿರ್ಧರಿಸಿ. ವಿತರಣಾ ಆವೃತ್ತಿ ಅಥವಾ ಎಡಿಟ್ ಮಾಡಿದ ಪೋರ್ಟ್ ಲೈನ್ ಮಾತ್ರ ಪ್ರಸ್ತುತ ಕೇಳುಗರನ್ನು ಸ್ಥಾಪಿಸುವುದಿಲ್ಲ. ಲೋಡ್ ಮಾಡಲಾದ ಘಟಕ, ಯಾವುದೇ ಉಡಾವಣಾ ಸಮಯದ -f/-o/-p ಆಯ್ಕೆಗಳು ಮತ್ತು ತಿದ್ದುಪಡಿಯನ್ನು ಯೋಜಿಸುವ ಮೊದಲು ss ಅನ್ನು ಹೋಲಿಕೆ ಮಾಡಿ.

sshd -T ಪಾರ್ಸ್ ಮಾಡಿದ ಪರಿಣಾಮಕಾರಿ ಸಂರಚನೆಯನ್ನು ಮುದ್ರಿಸುತ್ತದೆ; -C ಅನ್ವಯವಾಗುವ ಹೊಂದಾಣಿಕೆಯ ನಿಯಮಗಳಿಗೆ ಸಂಪರ್ಕ ಸಂದರ್ಭವನ್ನು ಒದಗಿಸುತ್ತದೆ. ಈ ಉದಾಹರಣೆಯು ಡೀಫಾಲ್ಟ್ ಕಾನ್ಫಿಗರೇಶನ್ ಅನ್ನು ಬಳಸುತ್ತದೆ. ನಿಜವಾದ ಉಡಾವಣೆಯು ಮತ್ತೊಂದು ಫೈಲ್ ಅನ್ನು ಆಯ್ಕೆಮಾಡಿದರೆ ಅಥವಾ ಸೆಟ್ಟಿಂಗ್‌ಗಳನ್ನು ಅತಿಕ್ರಮಿಸಿದರೆ, ಪರೀಕ್ಷೆಯಲ್ಲಿ ಆ ಕಾನ್ಫಿಗರೇಶನ್ ಆಯ್ಕೆಗಳನ್ನು ಸೇರಿಸಿ. -D ನಂತಹ ಡೀಮನ್-ಸ್ಟಾರ್ಟ್ ಫ್ಲ್ಯಾಗ್‌ಗಳನ್ನು ಈ ತಪಾಸಣೆಗೆ ನಕಲಿಸಬೇಡಿ.

ಎಲ್ಲಾ ಉದಾಹರಣೆ ಮೌಲ್ಯಗಳನ್ನು sshd ನೋಡುವುದರೊಂದಿಗೆ ಬದಲಾಯಿಸಿ: user ಗುರಿ ಖಾತೆಯಾಗಿದೆ; addr ಸಂಪರ್ಕಿಸುವ ಮೂಲ ವಿಳಾಸವಾಗಿದೆ (ಬಹುಶಃ ಜಂಪ್ ಹೋಸ್ಟ್/NAT); host ಎಂಬುದು ಪರಿಹರಿಸಲಾದ ಮೂಲ ಹೋಸ್ಟ್ ಹೆಸರು, VPS ಹೋಸ್ಟ್ ಹೆಸರಲ್ಲ; laddr ಮತ್ತು lport ಅತಿಥಿ ಕಡೆಯ ತಾಣವಾಗಿದೆ. NAT ಹಿಂದೆ, ಲ್ಯಾಡರ್ ಖಾಸಗಿಯಾಗಿರಬಹುದು. ಮೂಲ-ಹೆಸರಿನ ಲುಕಪ್ ಅನ್ನು ಬಳಸದಿದ್ದಾಗ, ಸಂಖ್ಯಾ ಮೂಲ ಮೌಲ್ಯವನ್ನು ಬಳಸಿ; ರಿವರ್ಸ್ ಹೋಸ್ಟ್ ಹೆಸರನ್ನು ಆವಿಷ್ಕರಿಸಬೇಡಿ.

check_user='ubuntu'
check_source='198.51.100.25'
check_source_name='198.51.100.25'
check_local='10.0.0.5'
check_port='22'
sudo /usr/sbin/sshd -T -C "user=$check_user,addr=$check_source,host=$check_source_name,laddr=$check_local,lport=$check_port"

PubkeyAuthentication, AuthenticationMethods, AuthorizedKeysFile/AuthorizedKeysCommand, AllowUsers/DenyUsers, ಗುಂಪು ನಿಯಮಗಳು, ForceCommand ಮತ್ತು PermitTTY ಅನ್ನು ಸಂಬಂಧಿತವಾಗಿ ಪರೀಕ್ಷಿಸಿ. getent passwd ನಿಂದ ಖಾತೆಯ ನಿಜವಾದ ಮನೆಯ ವಿರುದ್ಧ ಸಂಬಂಧಿತ ಅಧಿಕೃತ-ಕೀ ಮಾರ್ಗಗಳನ್ನು ಪರಿಹರಿಸಿ. ಒದಗಿಸುವವರು-ನಿರ್ವಹಿಸುವ ಕೀ ಕಮಾಂಡ್‌ಗಳು ಅಥವಾ ಪ್ರಮಾಣಪತ್ರ ನೀತಿಯು ಸರಳವಾದ ಫೈಲ್-ಆಧಾರಿತ ಮಾರ್ಗವನ್ನು ಬದಲಾಯಿಸಬಹುದು.

Ubuntu ಸಾಮಾನ್ಯವಾಗಿ sshd_config.d ತುಣುಕುಗಳನ್ನು sshd_config ನ ಪ್ರಾರಂಭದ ಬಳಿ ಒಳಗೊಂಡಿರುತ್ತದೆ. ಅನೇಕ ಸೆಟ್ಟಿಂಗ್‌ಗಳು ಮೊದಲು ಪಡೆದ ಮೌಲ್ಯವನ್ನು ಬಳಸುತ್ತವೆ ಮತ್ತು ಷರತ್ತುಬದ್ಧ ಹೊಂದಾಣಿಕೆ ನಿಯಮಗಳಿಗೆ ಸರಿಯಾದ ಸಂದರ್ಭದ ಅಗತ್ಯವಿದೆ. ನಂತರದ ನಕಲು ಸಾಲನ್ನು ಸೇರಿಸುವುದರಿಂದ ಪರಿಣಾಮಕಾರಿ ಫಲಿತಾಂಶವು ಬದಲಾಗುವುದಿಲ್ಲ. StrictModes ಅಥವಾ ಖಾತೆ ನಿರ್ಬಂಧಗಳನ್ನು ನಿಷ್ಕ್ರಿಯಗೊಳಿಸುವ ಬದಲು ಅನ್ವಯವಾಗುವ ಫೈಲ್/ನಿಯಮವನ್ನು ಪರಿಶೀಲಿಸಿ.

ಪರೀಕ್ಷೆಯು ಈಗ ಕಾನ್ಫಿಗರೇಶನ್ ಅನ್ನು ಓದುತ್ತದೆ; ಡೀಮನ್ ಈ ಹಿಂದೆ ಏನನ್ನು ಲೋಡ್ ಮಾಡಿದೆ, ದೃಢೀಕರಣವು ಹಾದುಹೋಗುತ್ತದೆಯೇ ಅಥವಾ ಪ್ರಸ್ತುತ ಯಾವ systemd ಕೇಳುತ್ತಿದೆ ಎಂಬುದನ್ನು ಇದು ಸಾಬೀತುಪಡಿಸಲು ಸಾಧ್ಯವಿಲ್ಲ. ಕೇಳುಗ ಮತ್ತು ಲಾಗ್ ಚೆಕ್‌ಗಳನ್ನು ಪ್ರತ್ಯೇಕವಾಗಿ ಇರಿಸಿ.

ಯುಟಿಸಿಯಲ್ಲಿ ಕ್ಲೈಂಟ್ ಪ್ರಯತ್ನವನ್ನು ರೆಕಾರ್ಡ್ ಮಾಡಿ, ಅತಿಥಿ ಗಡಿಯಾರವನ್ನು ಪರಿಶೀಲಿಸಿ ಮತ್ತು ಕೆಳಗಿನ ಎರಡೂ ಉದಾಹರಣೆ ಎಂಡ್‌ಪಾಯಿಂಟ್‌ಗಳನ್ನು ಆ ಪ್ರಯತ್ನದ ಸುತ್ತಲೂ ಚಿಕ್ಕ ವಿಂಡೋದೊಂದಿಗೆ ಬದಲಾಯಿಸಿ:

date -u '+%Y-%m-%dT%H:%M:%SZ'
sudo journalctl -u ssh.service -u ssh.socket --since '2026-10-13 12:00:00 UTC' --until '2026-10-13 12:02:00 UTC' --utc -o short-iso-precise --no-pager

ಸಮಯ, ಮೂಲ ಮತ್ತು ಖಾತೆಯನ್ನು ಹೊಂದಿಸಿ, ನಂತರ ಸಮಾಲೋಚನೆ, ದೃಢೀಕರಣ ಮತ್ತು ಅಧಿವೇಶನ ಸಂದೇಶಗಳನ್ನು ಪ್ರತ್ಯೇಕಿಸಿ. ನಿಮ್ಮ ಸೇವೆಯು ಮತ್ತೊಂದು ಘಟಕ ಅಥವಾ ಲಾಗಿಂಗ್ ಗಮ್ಯಸ್ಥಾನವನ್ನು ಬಳಸಿದರೆ, ಆ ಕಾನ್ಫಿಗರ್ ಮಾಡಿದ ಗಮ್ಯಸ್ಥಾನವನ್ನು ಪರೀಕ್ಷಿಸಿ. ಯಾವುದೇ ನಮೂದು ಎಂದರೆ ವಿನಂತಿಯು ಎಂದಿಗೂ ಬಂದಿಲ್ಲ ಎಂದು ಅರ್ಥೈಸಬಹುದು, ಆದರೆ ವಿಭಿನ್ನ ಲಾಗಿಂಗ್, ಸಾಕಷ್ಟು ಅನುಮತಿಗಳು, ಗಡಿಯಾರ ಹೊಂದಿಕೆಯಾಗದಿರುವುದು ಅಥವಾ ಅವಧಿ ಮೀರಿದ ದಾಖಲೆಗಳು; ಇದು ಫೈರ್‌ವಾಲ್ ಕಾರಣವನ್ನು ಸಾಬೀತುಪಡಿಸುವುದಿಲ್ಲ.