Điểm:0

Error SSH connection. Connection timed ou t

lá cờ cn

I am not able to connect via SSH to my server and I dont know the reasons.

SSHD its running and ports are open in UFW. I tried to change ports but the issue persist. Also tried differents machines and networks.

If I reboot the server, sometimes I can establish connection but after a time the problem comeback.

My sshd_config:

#   $OpenBSD: sshd_config,v 1.103 2018/04/09 20:41:22 tj Exp $

# This is the sshd server system-wide configuration file.  See
# sshd_config(5) for more information.

# This sshd was compiled with PATH=/usr/bin:/bin:/usr/sbin:/sbin

# The strategy used for options in the default sshd_config shipped with
# OpenSSH is to specify options with their default value where
# possible, but leave them commented.  Uncommented options override the
# default value.

Port 1402
#AddressFamily any
#ListenAddress 0.0.0.0
#ListenAddress ::

#HostKey /etc/ssh/ssh_host_rsa_key
#HostKey /etc/ssh/ssh_host_ecdsa_key
#HostKey /etc/ssh/ssh_host_ed25519_key

# Ciphers and keying
#RekeyLimit default none

# Logging
#SyslogFacility AUTH
LogLevel VERBOSE

# Authentication:

#LoginGraceTime 2m
#PermitRootLogin prohibit-password
StrictModes yes
#MaxAuthTries 6
#MaxSessions 10

#PubkeyAuthentication yes

# Expect .ssh/authorized_keys2 to be disregarded by default in future.
#AuthorizedKeysFile .ssh/authorized_keys .ssh/authorized_keys2

#AuthorizedPrincipalsFile none

#AuthorizedKeysCommand none
#AuthorizedKeysCommandUser nobody

# For this to work you will also need host keys in /etc/ssh/ssh_known_hosts
#HostbasedAuthentication no
# Change to yes if you don't trust ~/.ssh/known_hosts for
# HostbasedAuthentication
#IgnoreUserKnownHosts no
# Don't read the user's ~/.rhosts and ~/.shosts files
#IgnoreRhosts yes

# To disable tunneled clear text passwords, change to no here!
#PasswordAuthentication yes
PermitEmptyPasswords no

# Change to yes to enable challenge-response passwords (beware issues with
# some PAM modules and threads)
ChallengeResponseAuthentication yes

# Kerberos options
#KerberosAuthentication no
#KerberosOrLocalPasswd yes
#KerberosTicketCleanup yes
#KerberosGetAFSToken no

# GSSAPI options
#GSSAPIAuthentication no
#GSSAPICleanupCredentials yes
#GSSAPIStrictAcceptorCheck yes
#GSSAPIKeyExchange no

# Set this to 'yes' to enable PAM authentication, account processing,
# and session processing. If this is enabled, PAM authentication will
# be allowed through the ChallengeResponseAuthentication and
# PasswordAuthentication.  Depending on your PAM configuration,
# PAM authentication via ChallengeResponseAuthentication may bypass
# the setting of "PermitRootLogin without-password".
# If you just want the PAM account and session checks to run without
# PAM authentication, then enable this but set PasswordAuthentication
# and ChallengeResponseAuthentication to 'no'.
UsePAM yes

#AllowAgentForwarding yes
AllowTcpForwarding no
#GatewayPorts no
X11Forwarding no
#X11DisplayOffset 10
#X11UseLocalhost yes
#PermitTTY yes
PrintMotd no
#PrintLastLog yes
#TCPKeepAlive yes
#PermitUserEnvironment no
#Compression delayed
KeepAlive yes
ClientAliveInterval 90000
ClientAliveCountMax 2
UseDNS no
#PidFile /var/run/sshd.pid
#MaxStartups 10:30:100
#PermitTunnel no
#ChrootDirectory none
#VersionAddendum none

# no default banner path
#Banner none

# Allow client to pass locale environment variables
AcceptEnv LANG LC_*

# override default of no subsystems
Subsystem   sftp    /usr/lib/openssh/sftp-server

# Example of overriding settings on a per-user basis
#Match User anoncvs
#   X11Forwarding no
#   AllowTcpForwarding no
#   PermitTTY no
#   ForceCommand cvs server
PermitRootLogin no
PasswordAuthentication yes

I get a timeout error with: ssh [email protected] -p 1402

And nmap answer the following:

      user@linux:~$ nmap -p 1402 -Pn xx.xxx.xxx.xxx 
Starting Nmap 7.70 ( https://nmap.org ) at 2021-09-07 22:06 CEST
Nmap scan report for xx.xxx.xxx.xxx
Host is up.

PORT     STATE    SERVICE
1402/tcp filtered prm-sm-np

Nmap done: 1 IP address (1 host up) scanned in 6.99 seconds

Some ideas?

EDIT

UFW Config

    user@localhost:~$ sudo ufw status verbose
[sudo] password for user: 
Status: active
Logging: on (low)
Default: deny (incoming), allow (outgoing), disabled (routed)
New profiles: skip

To                         Action      From
--                         ------      ----
1402/tcp                   LIMIT IN    Anywhere                  
3000/tcp                   ALLOW IN    Anywhere                  
9100/tcp                   ALLOW IN    Anywhere                  
12798/tcp                  ALLOW IN    Anywhere                  
6000/tcp                   ALLOW IN    Anywhere                  
60000/tcp                  ALLOW IN    Anywhere                  
1402/tcp (v6)              LIMIT IN    Anywhere (v6)             
3000/tcp (v6)              ALLOW IN    Anywhere (v6)             
9100/tcp (v6)              ALLOW IN    Anywhere (v6)             
12798/tcp (v6)             ALLOW IN    Anywhere (v6)             
6000/tcp (v6)              ALLOW IN    Anywhere (v6)             
60000/tcp (v6)             ALLOW IN    Anywhere (v6)     
Michael Hampton avatar
lá cờ cz
Kiểm tra tường lửa của bạn.
Shugui avatar
lá cờ cn
Xong, UFW vẫn ổn và tường lửa từ máy chủ lưu trữ của tôi cũng vậy
Michael Hampton avatar
lá cờ cz
Nhưng bạn đã không đăng một bản sao của chúng trong bài viết của bạn.
Shugui avatar
lá cờ cn
Đã thêm cấu hình UFW. Đã thay đổi cấu hình cổng 1402 từ GIỚI HẠN thành CHO PHÉP VÀO mà vẫn không có kết nối
Michael Hampton avatar
lá cờ cz
Còn tường lửa khác thì sao?
George Y avatar
lá cờ vn
trước tiên bạn nên kiểm tra xem cổng có đang mở không. Cố gắng kết nối với cổng bằng cách sử dụng `telnet` từ máy cục bộ của bạn. Nếu nó vào chế độ hộp thoại, nhấn `Ctrl`+`]` để thoát, nếu không thì cổng không thể truy cập được. Sau đó, bạn nên kiểm tra tất cả các cài đặt tường lửa bao gồm cả bên trong Linux và bên ngoài Linux (một số dịch vụ Đám mây sẽ đặt tường lửa mặc định cho bạn)
Shugui avatar
lá cờ cn
@GeorgeY nmap trả lời tốt như tôi đã đăng, nhưng telnet (telnet xx.xxx.xxx.xx 1402) trả lời với: Không thể kết nối với máy chủ từ xa: Đã hết thời gian kết nối. Sao có thể như thế được? Không phải là một chuyên gia ở đây
George Y avatar
lá cờ vn
@Shugui sử dụng telnet trên cùng một máy và nếu bạn vẫn không thể mở nó, thì sự cố nằm ở `sshd` của bạn.
Điểm:-1
lá cờ vn
KeepAlive có
ClientAliveInterval 90000
ClientAliveCountMax 2

Ba dòng này chỉ ra rằng nếu trong vòng 90000*2 giây không có gói TCP nào từ máy khách, nó sẽ tự động cắt kết nối.

Đây là một cơ chế bảo vệ bởi SSH. Thay vào đó, bạn thay đổi tham số hoặc sử dụng Bitvise ssh Client, ứng dụng này sẽ tự động gửi các gói nhịp tim TCP Ping-Pong đến máy chủ.

Michael Hampton avatar
lá cờ cz
Điều này hoàn toàn đúng, nhưng nó hoàn toàn không liên quan đến câu hỏi.
Shugui avatar
lá cờ cn
Tôi đồng ý với @MichaelHampton. Tôi đã thay đổi các tham số đó trong trường hợp sự cố do ssh-client gây ra, nhưng không phải vậy

Đăng câu trả lời

Hầu hết mọi người không hiểu rằng việc đặt nhiều câu hỏi sẽ mở ra cơ hội học hỏi và cải thiện mối quan hệ giữa các cá nhân. Ví dụ, trong các nghiên cứu của Alison, mặc dù mọi người có thể nhớ chính xác có bao nhiêu câu hỏi đã được đặt ra trong các cuộc trò chuyện của họ, nhưng họ không trực giác nhận ra mối liên hệ giữa câu hỏi và sự yêu thích. Qua bốn nghiên cứu, trong đó những người tham gia tự tham gia vào các cuộc trò chuyện hoặc đọc bản ghi lại các cuộc trò chuyện của người khác, mọi người có xu hướng không nhận ra rằng việc đặt câu hỏi sẽ ảnh hưởng—hoặc đã ảnh hưởng—mức độ thân thiện giữa những người đối thoại.