- Print
- PDF
Support for remote access error (Linux)
- Print
- PDF
Available in VPC
This document describes how to troubleshoot symptoms of server remote access errors in the Linux environment.
Check Linux server remote access settings
To remotely access the Linux server, ensure that the IP or subnet of the server to access is applied to the ACG. If not applied, see Set ACG and change the ACG settings.
If there is no problem in ACG settings, check the following matters:
Check if the server allows access to SSH/RDP service.
- SSH service: TCP, allowed port 22
- RDP service: TCP, allowed port 3389
NoteIf the port setting on the server has been changed, update the settings accordingly.
Check the port forwarding settings.
- If both public IP and port forwarding are set simultaneously, you cannot communicate through a public IP. When using a public IP, remove the port forward settings.
Even if no problem is found as a result of checking the above, the SSH service port or the RDP service port may not work normally for various reasons. In this case, the [Server connection console] button is activated in the server information of NAVER Cloud Platform console. To resolve this issue, see Troubleshooting Linux server remote access errors.
Troubleshooting Linux server remote access errors
If Linux server remote access errors occur, see the OS-specific solutions to troubleshoot them.
CentOS 7
To troubleshoot a remote access error on CentOS 7 in Linux environment, perform the following steps in order.
- 1. Check daemon status
- 2. Check status of hosts.deny setting
- 3. Check firewall
- 4. Check routing
- 5. Check authority problem
1. Check daemon status
To check the daemon status, perform the following steps in order.
Run the following command to check if the daemon is properly
running
.systemctl status sshd
- If the daemon is
inactive
, try tostart
. If an error occurs, check the server log to ensure that the sshd daemon can properlystart
.
- If the daemon is
Run the following command to check if ssh is
LISTEN
on port 22.netstat -nap | grep ssh
Note- The default setting on NAVER Cloud Platform's server is port 22.
- If the port setting on the server has been changed, update the settings accordingly.
Run the following command to check if the port and
ListenAddress
have any settings.vi /etc/ssh/sshd_config
- The default setting is annotated.
2. Check status of hosts.deny setting
The hosts.allow
and hosts.deny
files control the service to allow or block specific clients only.
Check if the hosts.allow
and hosts.deny
files have any settings. The default setting is annotated.
- The
/etc/hosts.allow
and/etc/hosts.deny
files control onlytcp_wrappers
. Apply the rules in the following order:- Set to allow what is defined in the
/etc/hosts.allow
file. - Set to block what is not defined in the
/etc/hosts.allow
file but is defined in/etc/hosts.deny
the file. - Set to allow what is defined in both
/etc/hosts.allow
and/etc/hosts.deny
files.
- Set to allow what is defined in the
- It can control certain services of the daemon managed by
tcp_wrappers
andxinetd
.
<example> ssh, telnet, ftp
3. Check firewall
Check the firewall with the following:
If iptables.service
is installed, the daemon is also affected by rules even in the inactive
status and excludes the rules to block ssh in iptables rules. No applied rules in default setting.
The firewalld
is not applied if the daemon is inactive
. If you need to run firewalld
, exclude the rule to block ssh. No applied rules in default setting.
4. Check routing
Without a default route for eth0
, it cannot communicate. Check the static route status for eth0
and 169.254.0.0/16
.
5. Check authority problem
Depending on the ssh config, remote access of the root account may be blocked. If unable to access through root, try connecting with a regular account. If you don't have a regular access account, activate the server connection console to access root.
Ubuntu 18.04
To troubleshoot a remote access error on Ubuntu 18.04 in Linux environment, perform the following steps in order.
- 1. Check daemon status
- 2. Check status of hosts.deny setting
- 3. Check firewall
- 4. Check routing
- 5. Check authority problem
1. Check daemon status
To check the daemon status, perform the following steps in order.
Run the following command to check if the daemon is properly
running
.systemctl status sshd
- If the daemon is
inactive
, try tostart
. If an error occurs, check the server log to ensure that the sshd daemon can properlystart
.
- If the daemon is
Run the following command to check if it is
LISTEN
on the ssh port.netstat -nap | grep ssh
NoteThe default setting on NAVER Cloud Platform's server is port 22.
If the port setting on the server has been changed, update the settings accordingly.
Run the following command to check if the port and
ListenAddress
have any settings.vi /etc/ssh/sshd_config
- The default setting is annotated.
2. Check status of hosts.deny setting
The hosts.allow
and hosts.deny
files control the service to allow or block specific clients only.
Check if the hosts.allow
and hosts.deny
files have any settings. The default setting is annotated.
- The
/etc/hosts.allow
and/etc/hosts.deny
files control onlytcp_wrappers
. Apply the rules in the following order:- Set to allow what is defined in the
/etc/hosts.allow
file. - Set to block what is not defined in the
/etc/hosts.allow
file but is defined in/etc/hosts.deny
the file. - Set to allow what is defined in both
/etc/hosts.allow
and/etc/hosts.deny
files.
- Set to allow what is defined in the
- It can control certain services of the daemon managed by
tcp_wrappers
andxinetd
.
<example> ssh, telnet, ftp
3. Check firewall
Check the firewall with the following:
If iptables.service
is installed, the daemon is also affected by rules even in the inactive
status and excludes the rules to block ssh in iptables rules. No applied rules in default setting.
The ufw
is not applied if the daemon is inactive
. If you need to run ufw
, exclude the rule to block ssh. No applied rules in default setting.
4. Check routing
Without a default route for eth0
, it cannot communicate. Check the static route status for eth0
and 169.254.0.0/16
.
5. Check authority problem
Depending on the ssh config, remote access of the root account may be blocked. If unable to access through root, try connecting with a regular account. If you don't have a regular access account, activate the server connection console to access root.