The tutorial for a clone messenger app states that a hostname for the On Premise server should be specified:
But in my Mesibo console, the option to enter a hostname is not there:
Hence I am getting an error(Or atleast im assuming its becase of that):
console error
E0608-131427-190 (1): Unable to open /proc/sys/kernel/core_pattern
(truncate 1) E0608-131427-191 (1): starting mesibo E0608-131427-191
(1): PID: 1 E0608-131427-193 (1): build date: Tue Jul 28 15:17:28 2020
UTC E0608-131427-193 (1): build number: 2591 E0608-131427-193 (1):
module_exports_init E0608-131427-193 (1): Local IP count: 2
E0608-131427-193 (1): --> multiple(2) IPs found - listening on all the
IPs. If you like to use particular IPs only, set them in configuration
using one or more 'ip' fields E0608-131427-200 (1): signal ignored: 17
E0608-131427-200 (1): Local IP Address: 172.31.46.94 E0608-131427-200
(1): Local IP Address: 172.17.0.1 E0608-131427-568 (12):
***************** ERROR *****************
==> Missing Configuration - go to Mesibo console and enter on-premise configuration
E0608-131427-569 (12): on termination: 15 E0608-131427-569 (12):
onexit called: 1 0 E0608-131427-569 (12): Deleting all users and
saving notifications
There is no hostname in the console now, so ignore that part in the tutorial and configure the rest of the fields. The latest mesibo version is allowing you to configure it from the command line and it is optional.
https://mesibo.com/documentation/on-premise/#command-line-arguments
Related
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 have set up my outbound emails on phabricator by following this guide.
However, my emails don't arrive. All the emails are queued. When I went to the daemons in Phabricator UI, I see that several tasks are failing. They all look like this.
Task 448: PhabricatorMetaMTAWorker
Task 448
Task StatusQueuedTask ClassPhabricatorMetaMTAWorkerLease StatusLeasedLease Owner13195:1624502950:mail.icicbcoin.com:11Lease Expires1 h, 59 mDurationNot Completed
Data phabricator/ $ ./bin/mail show-outbound --id 154
Retries
Failure Count5Maximum Retries250Retries After1 m, 2 m, 4 m, 6 m, 8 m, 11 m, 14 m, 17 m, 20 m, 23 m, 27 m, ...
I'm curious of this data part. To me it sounds like phabricator fails running this command which is weir because if I run ./bin/mail show-outbound --id 154 manually I get this:
ID: 154
Status: queued
Related PHID:
Message: fputs(): send of 28 bytes failed with errno=32 Broken pipe
PARAMETERS
sensitive: 1
mustEncrypt:
subject: [Phabricator] Welcome to Phabricator
to: ["PHID-USER-qezqlvc7rxton2lshjue"]
force: 1
HEADERS
TEXT BODY
Welcome to Phabricator!
admin (John Doe) has created an account for you.
Username: some.person
To log in to Phabricator, follow this link and set a password:
http://phabricator.innolabsolutions.rs/login/once/welcome/9/b2jf7j6mg5xomwjhmcfcxbigs7474jyq/10/
After you have set a password, you can log in to Phabricator in the future by going here:
http://phabricator.innolabsolutions.rs/
Love,
Phabricator
HTML BODY
(This message has no HTML body.)
Actually, the problem was the SMTP server configuration, even though this error didn't tell me that. I changed the SMTP port from 465 to 587, restarted the daemons and it worked.
I had the same problem twice.
The second time, it was because I could not resolve the smtp server name:
$ ping gandi.net
ping: gandi.net: Temporary failure in name resolution
Then I added a dns server in /etc/resolv.conf
nameserver 127.0.0.1
nameserver 8.8.8.8 # <--- added
search home
and restarted the service
sudo service systemd-resolved restart
Right after, Phabricator automatically sent all the queued emails.
How to fix the ERR_SSL_VERSION_OR_CIPHER_MISMATCH error?
In one of our CentOS server, we are encountering the following error in Chrome
A secure connection cannot be established because this site uses an unsupported protocol with Error Code - ERR_SSL_VERSION_OR_CIPHER_MISMATCH
We tried following command - openssl s_client -connect <<domain>>:<<port>> -tls1_2
It gives the following output. It doesn't provide a chain of certificates and negotiated cipher.
$ openssl s_client -connect <<domain>>:<<port>> -tls1_2
CONNECTED(00000003)
139874418423624:error:14094410:SSL routines:SSL3_READ_BYTES:sslv3 alert handshake failure:s3_pkt.c:1275:SSL alert number 40
139874418423624:error:1409E0E5:SSL routines:SSL3_WRITE_BYTES:ssl handshake failure:s3_pkt.c:598:
---
no peer certificate available
---
No client certificate CA names sent
---
SSL handshake has read 7 bytes and written 0 bytes
---
New, (NONE), Cipher is (NONE)
Secure Renegotiation IS NOT supported
Compression: NONE
Expansion: NONE
SSL-Session:
Protocol : TLSv1.2
Cipher : 0000
Session-ID:
Session-ID-ctx:
Master-Key:
Key-Arg : None
Krb5 Principal: None
PSK identity: None
PSK identity hint: None
Start Time: 1505770082
Timeout : 7200 (sec)
Verify return code: 0 (ok)
We checked available ciphers on VM using command - # /usr/bin/openssl ciphers -v. This command provides a list of available ciphers which also include ciphers supported by TLS 1.2
We also checked certificates. The same certs work on different servers.
Can someone please guide what is missing in this scenario?
When we use openssl, if the connection gets terminated with the alert 40 error, that means we should explicitly specify the servername in our command, so that the server can return the right certificate the client is expecting.
Specify the exact hostname you want with -servername parameter. E.g:
openssl s_client -connect yourserver.domain.com:443 -servername yourserver.domain.com
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 want to SSH to a machine (call it A). It's sshd config file looks like below:
AllowGroups wheel
AllowTcpForwarding no
AuthorizedKeysFile .ssh/authorized_keys
Banner /etc/issue
ChallengeResponseAuthentication no
Ciphers aes256-ctr,aes128-ctr
Compression delayed
GatewayPorts no
MACs hmac-sha1
MaxSessions 1
PasswordAuthentication yes
PermitRootLogin yes
PermitTunnel no
PermitUserEnvironment no
Protocol 2
RhostsRSAAuthentication no
StrictModes yes
Subsystem sftp /usr/lib64/ssh/sftp-server
UsePAM yes
UsePrivilegeSeparation yes
X11Forwarding no
I have another machine (call it B - ssh client)
Now, if I try to ssh to machineA as below, it works perfect:
ssh root#machineA
and then interactively provide password. Works perfect!
Now, I try passing password via a script using sshpass utility as below:
sshpass -p PASSWORD ssh -vvv -o=StrictHostKeyChecking=no root#machineA
This fails.
Last few lines from debug of -vvv gives below:
debug3: remaining preferred: ,password
debug3: authmethod_is_enabled password
debug1: Next authentication method: password
debug3: packet_send2: adding 64 (len 51 padlen 13 extra_pad 64)
debug2: we sent a password packet, wait for reply
debug1: Authentications that can continue: publickey,password
Permission denied, please try again.
/var/log/auth.log on machine A says below:
Connection from machineB port 44408
Failed password for root from machineB port 44408 ssh2
Connection closed by machineB port 44408 [preauth]
lastb command gives below:
root ssh:notty machineB Sun Jul 3 04:20 - 04:20 (00:00)
root ssh:notty machineB Sun Jul 3 04:19 - 04:19 (00:00)
I have been reading around for it. But, not something that I can stop at. Do you have any pointers? What could be the problem?
Anything related to sshpass or something?
I would try to narrow the problem:
Try with a simpler password, without special characters.
Try with a user different than root.
Try using certificates instead of password.
That is explained here: https://git-scm.com/book/en/v2/Git-on-the-Server-Generating-Your-SSH-Public-Key , https://www.digitalocean.com/community/tutorials/how-to-set-up-ssh-keys--2 etc.
Have a look at the server logs as well, check /var/log/secure or alike.