I wanted to connect to vpn and used ready configuration file provided by company I work at. I am using macOS and thus tunnelblick. But when I click on "connect" then I got stuck in "authorization":
2021-02-22 20:08:45.407794 MANAGEMENT: Client connected from [AF_INET]127.0.0.1:53745
2021-02-22 20:08:45.445975 MANAGEMENT: CMD 'pid'
2021-02-22 20:08:45.446048 MANAGEMENT: CMD 'auth-retry interact'
2021-02-22 20:08:45.446088 MANAGEMENT: CMD 'state on'
2021-02-22 20:08:45.446109 MANAGEMENT: CMD 'state'
2021-02-22 20:08:45.446142 MANAGEMENT: CMD 'bytecount 1'
2021-02-22 20:08:45.446819 *Tunnelblick: Established communication with OpenVPN
2021-02-22 20:08:45.459662 *Tunnelblick: >INFO:OpenVPN Management Interface Version 1 -- type 'help' for more info
2021-02-22 20:08:45.461317 MANAGEMENT: CMD 'hold release'
2021-02-22 20:08:45.461564 NOTE: the current --script-security setting may allow this configuration to call user-defined scripts
2021-02-22 20:08:45.484613 *Tunnelblick: Obtained passphrase from the Keychain
2021-02-22 20:08:45.485552 MANAGEMENT: CMD 'password [...]'
2021-02-22 20:08:45.488601 Outgoing Control Channel Authentication: Using 160 bit message hash 'SHA1' for HMAC authentication
2021-02-22 20:08:45.488642 Incoming Control Channel Authentication: Using 160 bit message hash 'SHA1' for HMAC authentication
2021-02-22 20:08:45.488939 MANAGEMENT: >STATE:1614006525,RESOLVE,,,,,,
2021-02-22 20:08:45.496536 TCP/UDP: Preserving recently used remote address: [AF_INET]109.107.200.210:1192
2021-02-22 20:08:45.496616 Socket Buffers: R=[786896->786896] S=[9216->9216]
2021-02-22 20:08:45.496635 UDP link local: (not bound)
2021-02-22 20:08:45.496650 UDP link remote: [AF_INET]109.107.200.210:1192
2021-02-22 20:08:45.496679 MANAGEMENT: >STATE:1614006525,WAIT,,,,,,
2021-02-22 20:08:45.589736 MANAGEMENT: >STATE:1614006525,AUTH,,,,,,
2021-02-22 20:08:45.589801 TLS: Initial packet from [AF_INET]109.107.200.210:1192, sid=ccb6a360 722532cd
2021-02-22 20:09:45.121118 TLS Error: TLS key negotiation failed to occur within 60 seconds (check your network connectivity)
2021-02-22 20:09:45.121224 TLS Error: TLS handshake failed
2021-02-22 20:09:45.121413 SIGUSR1[soft,tls-error] received, process restarting
2021-02-22 20:09:45.121436 MANAGEMENT: >STATE:1614006585,RECONNECTING,tls-error,,,,,
2021-02-22 20:09:45.145721 MANAGEMENT: CMD 'hold release'
2021-02-22 20:09:45.145779 NOTE: the current --script-security setting may allow this configuration to call user-defined scripts
2021-02-22 20:09:45.145880 MANAGEMENT: >STATE:1614006585,RESOLVE,,,,,,
2021-02-22 20:09:45.147176 TCP/UDP: Preserving recently used remote address: [AF_INET]109.107.200.210:1192
2021-02-22 20:09:45.147225 Socket Buffers: R=[786896->786896] S=[9216->9216]
2021-02-22 20:09:45.147240 UDP link local: (not bound)
2021-02-22 20:09:45.147252 UDP link remote: [AF_INET]109.107.200.210:1192
2021-02-22 20:09:45.147270 MANAGEMENT: >STATE:1614006585,WAIT,,,,,,
2021-02-22 20:09:45.147507 MANAGEMENT: CMD 'hold release'
2021-02-22 20:09:45.244033 MANAGEMENT: >STATE:1614006585,AUTH,,,,,,
2021-02-22 20:09:45.244138 TLS: Initial packet from [AF_INET]109.107.200.210:1192, sid=1ea09cc1 79075a36
the question is how did I do incorrectly and is it possible to track the issue?
Related
go t my server up and when loading client get this error. thank you for any help!
server config
port 1194
proto udp
dev tun
auth-nocache
ca "C:\Program Files\OpenVPN\easy-rsa\pki\ca.crt"
cert "C:\Program Files\OpenVPN\easy-rsa\pki\issued\server.crt"
key "C:\Program Files\OpenVPN\easy-rsa\pki\private\server.key"
dh "C:\Program Files\OpenVPN\easy-rsa\pki\dh.pem"
server 10.8.0.0 255.255.255.0
ifconfig-pool-persist ipp.txt
keepalive 10 120
tls-auth "C:\Program Files\OpenVPN\easy-rsa\ta.key" 0 # This file is secret
cipher AES-256-CBC
data-ciphers AES-256-GCM:AES-128-GCM:AES-256-CBC
data-ciphers cipher AES-256-CBC
persist-key
persist-tun
status openvpn-status.log
verb 3
explicit-exit-notify 1
client config
client
dev tun
;dev-node MyTap
;proto tcp
proto udp
remote 174.141.223.114 1194
;remote my-server-2 1194
;remote-random
resolv-retry infinite
nobind
;user nobody
;group nobody
persist-key
persist-tun
;http-proxy-retry # retry on connection failures
;http-proxy [proxy server] [proxy port #]
;mute-replay-warnings
remote-cert-tls server
cipher BF-CBC
comp-lzo
verb 3
;mute 20
log file on startup
MANAGEMENT: CMD 'signal SIGHUP'
2022-12-15 13:33:04 SIGHUP[hard,init_instance] received, process restarting
2022-12-15 13:33:04 MANAGEMENT: >STATE:1671129184,RECONNECTING,init_instance,,,,,
2022-12-15 13:33:04 WARNING: Compression for receiving enabled. Compression has been used in the past to break encryption. Sent packets are not compressed unless "allow-compression yes" is also set.
2022-12-15 13:33:04 DEPRECATED OPTION: --cipher set to 'BF-CBC' but missing in --data-ciphers (AES-256-GCM:AES-128-GCM). OpenVPN ignores --cipher for cipher negotiations.
2022-12-15 13:33:04 Note: '--allow-compression' is not set to 'no', disabling data channel offload.
2022-12-15 13:33:04 OpenVPN 2.6_beta1 [git:release/2.6/e778a6fd26d849dc] Windows-MSVC [SSL (OpenSSL)] [LZO] [LZ4] [PKCS11] [AEAD] [DCO] built on Dec 2 2022
2022-12-15 13:33:04 Windows version 6.1 (Windows 7), amd64 executable
2022-12-15 13:33:04 library versions: OpenSSL 3.0.7 1 Nov 2022, LZO 2.10
2022-12-15 13:33:04 Restart pause, 5 second(s)
2022-12-15 13:33:09 Outgoing Control Channel Authentication: Using 160 bit message hash 'SHA1' for HMAC authentication
2022-12-15 13:33:09 Incoming Control Channel Authentication: Using 160 bit message hash 'SHA1' for HMAC authentication
2022-12-15 13:33:09 TCP/UDP: Preserving recently used remote address: [AF_INET]174.141.223.114:1194
2022-12-15 13:33:09 Socket Buffers: R=[8192->8192] S=[8192->8192]
2022-12-15 13:33:09 UDPv4 link local: (not bound)
2022-12-15 13:33:09 UDPv4 link remote: [AF_INET]174.141.223.114:1194
2022-12-15 13:33:09 MANAGEMENT: >STATE:1671129189,WAIT,,,,,,
2022-12-15 13:33:09 read UDPv4: Connection reset by peer (WSAECONNRESET) (fd=240,code=10054)
2022-12-15 13:33:11 read UDPv4: Connection reset by peer (WSAECONNRESET) (fd=240,code=10054)
2022-12-15 13:33:15 read UDPv4: Connection reset by peer (WSAECONNRESET) (fd=240,code=10054)
many thanks
followed the openvpn documentation, bit confusing
I face following issues when trying to connect from my PS using either PowerShell or Cygwin to AWS on which my Wordpress site is hosted (Bitnami).
(I simply what to log in to the server either this way or using Putty as described here (LINK Putty is throwing an error "using username bitnami. Server refused our key. No supported authentication methods available. server sent publickey")
What I tried so far:
I execute either or both of the following commands...
chmod 600 <key-pair-from-aws>.pem
chmod 400 <key-pair-from-aws>.pem
(When I logged in to ec2 instance, under Key Pairs section I saw an entry, but I could not download it. That's why I generated a new key pair and that is the file I am using in the commands below.)
Then I enter the following command...
ssh bitnami#<public-ip-address> -i <key-pair-from-aws>.pem
... I get the following error:
Permissions for '(key-pair-from-aws).pem' are too open.
It is required that your private key files are NOT accessible by others.
This private key will be ignored.
Load key ".pem": bad permissions
bitnami#(public-ip-address): Permission denied (publickey).
Now, if I select the file on the PC "Properties -> Security -> Advanced -> disable inheritance", and then remove every user except my user, and then execute the same command ...
ssh bitnami#<public-ip-address> -i <key-pair-from-aws>.pem
... I get the following error:
bitnami#<public-ip-address>: Permission denied (publickey).
here I am stuck because I do not have any idea how to proceed further.
Searching on Stackoverflow and google I could not find anything to help me solve this issue.
can anyone please help with concrete, step-by-step instructions?
Thank you!
Update: here is the result of the command
$ ssh -v -i "pem-file-name.pem" bitnami#
> OpenSSH_for_Windows_8.1p1, LibreSSL 3.0.2
debug1: Connecting to <public-ip-address> [<public-ip-address>] port 22.
debug1: Connection established.
debug1: identity file kljuc_par_ime.pem type -1
debug1: identity file kljuc_par_ime.pem-cert type -1
debug1: Local version string SSH-2.0-OpenSSH_for_Windows_8.1
debug1: Remote protocol version 2.0, remote software version OpenSSH_8.4p1 Debian-
5+deb11u1
debug1: match: OpenSSH_8.4p1 Debian-5+deb11u1 pat OpenSSH* compat 0x04000000
debug1: Authenticating to <public-ip-address>:22 as 'bitnami'
debug1: SSH2_MSG_KEXINIT sent
debug1: SSH2_MSG_KEXINIT received
debug1: kex: algorithm: curve25519-sha256
debug1: kex: host key algorithm: ecdsa-sha2-nistp256
debug1: kex: server->client cipher: chacha20-poly1305#openssh.com MAC: <implicit>
compression: none
debug1: kex: client->server cipher: chacha20-poly1305#openssh.com MAC: <implicit>
compression: none
debug1: expecting SSH2_MSG_KEX_ECDH_REPLY
debug1: Server host key: <deleted for sec purposes> SHA256:<deleted for security purposes>
debug1: Host '<public-ip-address>' is known and matches the ECDSA host key.
debug1: Found key in C:\\Users\\My-User/.ssh/known_hosts:1
debug1: rekey out after 134217728 blocks
debug1: SSH2_MSG_NEWKEYS sent
debug1: expecting SSH2_MSG_NEWKEYS
debug1: SSH2_MSG_NEWKEYS received
debug1: rekey in after 134217728 blocks
debug1: pubkey_prepare: ssh_get_authentication_socket: No such file or directory
debug1: Will attempt key: kljuc_par_ime.pem explicit
debug1: SSH2_MSG_EXT_INFO received
debug1: kex_input_ext_info: server-sig-algs=<ssh-ed25519,sk-ssh-ed25519#openssh.co
m,ssh-rsa,rsa-sha2-256,rsa-sha2-512,ssh-dss,ecdsa-sha2-nistp256,ecdsa-sha2-nistp38
4,ecdsa-sha2-nistp521,sk-ecdsa-sha2-nistp256#openssh.com,webauthn-sk-ecdsa-sha2-ni
stp256#openssh.com>
debug1: SSH2_MSG_SERVICE_ACCEPT received
debug1: Authentications that can continue: publickey
debug1: Next authentication method: publickey
debug1: Trying private key: kljuc_par_ime.pem
debug1: Authentications that can continue: publickey
debug1: No more authentication methods to try.
bitnami#<public-ip-address>: Permission denied (publickey)
To use a keypair with an Amazon EC2 instance, you should specify the keypair when launching the instance. It is not possible to SSH into an instance using a keypair generated after the instance is launched.
Also, Bitnami AMIs generate a random password for Wordpress, which can be extracted from the System Log after the instance boots.
See: Bitnami: Find application credentials
I'm seeing the following error messages when trying to sftp from a windows client to my redhat server:
Client:
C:\Users\Administrator\.ssh>sftp -P 7822 -v user#x.x.x.x
.
.
debug1: kex_input_ext_info: server-sig-algs=<rsa-sha2-256,rsa-sha2-512>
debug1: SSH2_MSG_SERVICE_ACCEPT received
debug1: Authentications that can continue: publickey,gssapi-keyex,gssapi-with-mic
debug1: Next authentication method: publickey
debug1: Offering public key: RSA SHA256:FczboY8BDSWtdA87euFDWSDrwBNRMbYzHUR3VmMpbk
C:\\Users\\Administrator/.ssh/id_rsa
debug1: Authentications that can continue: publickey,gssapi-keyex,gssapi-with-mic
debug1: Trying private key: C:\\Users\\Administrator/.ssh/id_dsa
debug1: Trying private key: C:\\Users\\Administrator/.ssh/id_ecdsa
debug1: Trying private key: C:\\Users\\Administrator/.ssh/id_ed25519
debug1: Trying private key: C:\\Users\\Administrator/.ssh/id_xmss
debug1: No more authentication methods to try.
user#x.x.x.x Permission denied (publickey,gssapi-keyex,gssapi-with-mic).
Server:
Aug 4 23:27:09 3oy1jxwr1k81l.xxx.io sshd[16064]: Connection reset by x.x.x.x port 65256 [preauth]
Aug 4 23:27:14 3oy1jxwr1k81l.xxx.io sshd[16117]: Did not receive identification string from x.x.x.x port 12593
Aug 4 23:27:24 3oy1jxwr1k81l.xxx.io sshd[16259]: Did not receive identification string from x.x.x.x port 48329
Aug 4 23:27:34 3oy1jxwr1k81l.xxx.io sshd[16394]: Did not receive identification string from x.x.x.x port 2040
I'm positive that all ports open in firewall, and authorized_keys are setup up correctly.
So i stop the sshd service, and run from cmd line with -ddd hoping to get more information.
However when running in debug mode, the connection succeeds !?!?
/user/sbin/sshd -D -ddd
Client:
C:\Users\Administrator\.ssh>sftp -P 7822 user#x.x.x.x
Connected to user#x.x.x.x.
sftp> exit
Any ideas what could be happening? (Note this is 100% reproducible, fails every time when sshd is run normally, and succeeds always when run with -ddd)
So looks like the problem was due to a missing .bash_profile in the user home dir on the server.
After adding the user profile back, it seems to resolve the issue.
Why sshd didn't care it was missing when run in debug mode seems like a bug in sshd.
I was also getting the Connection reset by [ip] port x [preauth] message.
For me, however, it was a firewall issue on the client side. The IT department had blocked SSH outside the network. After updating the firewall, the connection worked.
I recently switched the ssh listen port on my server running Dropbear from 22 to a random one to prevent the system log from being flooded by someone brute-forcing.
Everything is fine and I am able to connect to the server from the wan side using termux(an
Android terminal emulator that you can install packages).
Until when I try using my MacBook to ssh into the server(under the same network with my phone, was previously able to ssh into the server when dropbear was listening on 22). The connection immediately drops and ssh throws this at me:
kex_exchange_identification: write: Broken pipe
The verbose output does not really show anything helpful(and cut really abruptly may I add):
OpenSSH_8.1p1, LibreSSL 2.7.3
debug1: Reading configuration data /Users/my_username/.ssh/config
debug1: Reading configuration data /etc/ssh/ssh_config
debug1: /etc/ssh/ssh_config line 47: Applying options for *
debug1: Connecting to remote.yhaoquan.top port 2123.
debug1: Connection established.
debug1: identity file /Users/my_username/.ssh/id_rsa type 0
debug1: identity file /Users/my_username/.ssh/id_rsa-cert type -1
debug1: identity file /Users/my_username/.ssh/id_dsa type -1
debug1: identity file /Users/my_username/.ssh/id_dsa-cert type -1
debug1: identity file /Users/my_username/.ssh/id_ecdsa type -1
debug1: identity file /Users/my_username/.ssh/id_ecdsa-cert type -1
debug1: identity file /Users/my_username/.ssh/id_ed25519 type -1
debug1: identity file /Users/my_username/.ssh/id_ed25519-cert type -1
debug1: identity file /Users/my_username/.ssh/id_xmss type -1
debug1: identity file /Users/my_username/.ssh/id_xmss-cert type -1
kex_exchange_identification: write: Broken pipe
Telnetting to port 2123 shows that I actually successfully made the connection to the server:
>telnet {hostname} 2123
Trying {host IP address}...
Connected to {hostname}
Escape character is '^]'.
SSH-2.0-dropbear
|
��]J044��d����curve25519-sha256,curve25519-sha256#libssh.org,diffie-hellman-group14-sha256,diffie-hellman-group14-sha1,kexguess2#matt.ucc.asn.aursa-sha2-256,ssh-rsa3chacha20-poly1305#openssh.com,aes128-ctr,aes256-ctr3chacha20-poly1305#openssh.com,aes128-ctr,aes256-ctrhmac-sha1,hmac-sha2-256hmac-sha1,hmac-sha2-256nonenoneM�'�Rf
When I change the port back to 22 on my server, everything works again.
Does anyone know where the problem might be or what way should I go about diagnosing the problem?
Thanks in advance :)
EDIT 1:
For those of you who are experiencing the same issue, a temporary solution would be using OpenSSH. The easiest way (that makes this a drop-in solution) to do this is by using Homebrew:
brew install openssh
This command will change the ssh client you use from /usr/bin/ssh to an alias placed at /usr/local/bin/ssh points to the OpenSSH you just installed using brew, which the symptom doesn't seem to appear on.
This does not solve the problem that this post is about. I am still looking for a solution for it.
I had the same issue: ssh returns "kex_exchange_identification: write: Broken pipe" without network activity.
In my case the guilty party was AdGuard.
I added the port I use for ssh in the advanced configuration, network.extension.exclude.ports and it works now.
network.extension.exclude.domains may be a better choice for you depending on your configuration.
This solved my issue with /usr/bin/ssh.
Background:
ssh to a named host would fail with kex_exchange_identification: write: Broken pipe.
ssh to an IP address would work.
Installing a new version of SSH (using Homebrew) worked (from the terminal, using /usr/local/bin/ssh).
Mac Mail was still broken (it uses SSH to connect to my IMAP accounts).
I found this post where someone (yesterday) was experiencing the exact same symptoms as me from a piece of Broadcom antivirus software (WSS Agent) which I do not use:
https://community.broadcom.com/symantecenterprise/communities/community-home/digestviewer/viewthread?GroupId=2593&MessageKey=57c16f08-06e4-4c1d-adc7-bd3f51cc4516&CommunityKey=84278e0f-9c57-4f93-8cff-4530b03e3c07&tab=digestviewer&ReturnUrl=%2Fbrowse%2Fallrecentposts
That reminded me that Sophos (Antivirus) had recently (maybe yesterday, maybe the day before) installed a "SophosWebNetworkExtentsion". They posted this video (of how to accept the install) on 2021 Jan 19th (two days ago):
https://www.youtube.com/watch?v=z-qWdv1ynMs
The Fix:
I logged into Sophos, and under "Web Protection" disabled Web Protection.
I needed to reboot for the change to affect SSH. After rebooting, usr/bin/ssh started working again and Mac Mail started working again.
Before the fix:
$ /usr/bin/ssh s0-backend -v
OpenSSH_8.1p1, LibreSSL 2.7.3
debug1: Reading configuration data /Users/eric/.ssh/config
debug1: /Users/eric/.ssh/config line 62: Applying options for s0-backend
debug1: Reading configuration data /etc/ssh/ssh_config
debug1: /etc/ssh/ssh_config line 47: Applying options for *
debug1: Connecting to s0-backend port 61917.
debug1: Connection established.
debug1: identity file /Users/eric/.ssh/id_rsa type 0
debug1: identity file /Users/eric/.ssh/id_rsa-cert type -1
debug1: identity file /Users/eric/.ssh/id_dsa type -1
debug1: identity file /Users/eric/.ssh/id_dsa-cert type -1
debug1: identity file /Users/eric/.ssh/id_ecdsa type -1
debug1: identity file /Users/eric/.ssh/id_ecdsa-cert type -1
debug1: identity file /Users/eric/.ssh/id_ed25519 type -1
debug1: identity file /Users/eric/.ssh/id_ed25519-cert type -1
debug1: identity file /Users/eric/.ssh/id_xmss type -1
debug1: identity file /Users/eric/.ssh/id_xmss-cert type -1
kex_exchange_identification: write: Broken pipe
$
After the fix (successful SSH login):
usr/bin/ssh s0-backend -v
OpenSSH_8.1p1, LibreSSL 2.7.3
debug1: Reading configuration data /Users/eric/.ssh/config
debug1: /Users/eric/.ssh/config line 62: Applying options for s0-backend
debug1: Reading configuration data /etc/ssh/ssh_config
debug1: /etc/ssh/ssh_config line 47: Applying options for *
debug1: Connecting to s0-backend port {redacted}.
debug1: Connection established.
debug1: identity file /Users/eric/.ssh/id_rsa type 0
debug1: identity file /Users/eric/.ssh/id_rsa-cert type -1
debug1: identity file /Users/eric/.ssh/id_dsa type -1
debug1: identity file /Users/eric/.ssh/id_dsa-cert type -1
debug1: identity file /Users/eric/.ssh/id_ecdsa type -1
debug1: identity file /Users/eric/.ssh/id_ecdsa-cert type -1
debug1: identity file /Users/eric/.ssh/id_ed25519 type -1
debug1: identity file /Users/eric/.ssh/id_ed25519-cert type -1
debug1: identity file /Users/eric/.ssh/id_xmss type -1
debug1: identity file /Users/eric/.ssh/id_xmss-cert type -1
debug1: Local version string SSH-2.0-OpenSSH_8.1
debug1: Remote protocol version 2.0, remote software version OpenSSH_8.2p1 Ubuntu-4ubuntu0.1
debug1: match: OpenSSH_8.2p1 Ubuntu-4ubuntu0.1 pat OpenSSH* compat 0x04000000
debug1: Authenticating to s0-backend:61917 as '{redacted}'
debug1: SSH2_MSG_KEXINIT sent
debug1: SSH2_MSG_KEXINIT received
debug1: kex: algorithm: curve25519-sha256
debug1: kex: host key algorithm: ssh-ed25519
debug1: kex: server->client cipher: chacha20-poly1305#openssh.com MAC: <implicit> compression: none
debug1: kex: client->server cipher: chacha20-poly1305#openssh.com MAC: <implicit> compression: none
debug1: expecting SSH2_MSG_KEX_ECDH_REPLY
debug1: Server host key: ssh-ed25519 SHA256: {redacted}
debug1: Host '[s0-backend]:{redacted}' is known and matches the ED25519 host key.
debug1: Found key in /Users/eric/.ssh/known_hosts:40
debug1: rekey out after 134217728 blocks
debug1: SSH2_MSG_NEWKEYS sent
...
{redacted}
...
debug1: Sending env LANG = en_US.UTF-8
debug1: Sending env LC_TERMINAL = iTerm2
debug1: Sending env LC_TERMINAL_VERSION = 3.4.3
Welcome to Ubuntu 20.04.1 LTS (GNU/Linux 5.4.0-62-generic x86_64)
...
{redacted}
...
$
Is there your server with port 22 in .ssh/known_hosts?
If so, maybe you can remove this line and try to log again with the new port.
According to your log, built in ssh command loads configuration from /Users/my_username/.ssh/config
debug1: Reading configuration data /Users/my_username/.ssh/config
Check inside this file, there should be some configuration preventing the default client using any other port than 22. Since OpenSSH client doesn't use this configuration file, it has no issue connecting to port 2123.
Here is a similar issue
https://github.com/hashicorp/vagrant/issues/410#issuecomment-207278540
I install ROS on my server, but when I called ros start and it will running at my server, here is the log:
login as: root
root#*.*.*.*'s password:
Welcome to Ubuntu 16.04.3 LTS (GNU/Linux 4.4.0-109-generic x86_64)
* Documentation: https://help.ubuntu.com
* Management: https://landscape.canonical.com
* Support: https://ubuntu.com/advantage
Welcome to Alibaba Cloud Elastic Compute Service !
root#iZwz940pq66re8qvh8adzuZ:~# ros start
info: Loaded feature token capabilities=[Sync], expires=Wed Apr 19 2017 22:15:29 GMT+0800 (CST)
info: Realm Object Server version 2.5.1 is starting
info: [sync] Realm sync server started ([realm-core-4.0.4], [realm- sync-2.1.10])
info: [sync] Directory holding persistent state: /root/data/sync/user_data
info: [sync] Operating mode: master_with_no_slave
info: [sync] Log level: info
info: [sync] Download log compaction is enabled
info: [sync] Max download size: 131072 bytes
info: [sync] Listening on 127.0.0.1:35571 (sync protocol version 22)
info: Realm Object Server has started and is listening on http://0.0.0.0:9080
But when I entered the address in the browser, It told me that I could not connect.And I use Realm Studio to connect it also tell me that could not reach the server, did i forget something steps? Maybe my server's security policy forbide the port?
Per to the log description, Realm Object Server has started and is listening on http://0.0.0.0:9080.
Please ensure you've allowed TCP port 9080 in your ECS security group.
For detail steps, please refer the document
Add a security group rule