[PATCH] Print errno information in write_packet
This patch put the error information into the log output to have a better view
on the reason of a packet write failure.
Signed-off-by: Ronny Meeus
diff --git a/packet.c b/packet.c
--- a/packet.c
+++ b/packet.c
@@ -90,7 +90,7 @@ void write_packet() {
TRACE2(("leave write_packet: EINTR"))
return;
} else {
- dropbear_exit("Error writing");
+ dropbear_exit("Error writing %s", strerror(errno));
}
}
@@ -131,7 +131,7 @@ void write_packet() {
TRACE2(("leave writepacket: EINTR"))
return;
} else {
- dropbear_exit("Error writing");
+ dropbear_exit("Error writing %s", strerror(errno));
}
}
all_ignore = (packet_type == SSH_MSG_IGNORE);
[PATCH] Limit size of the iovect passed to writev in packet.c
The writev allows only a limited number of entries to be present in the
iovector. This number depends on the OS. If more entries are passed, the
writev operation fails and the connection is closed.
This patch limits the size of the vector to the maximum number accepted
by the OS. On some operating systems IOV_MAX is not defined, if this is
the case UIO_MAXIOV is being used as the maximum value.
In the problematic scenario the Linux box, running dropbear, has a slow
uplink. If an ssh is done to the box and a command is executed that
generates a lot of small fragments (for example a 'find .' in the root),
a lot of small interactions are seen between dropbear and the shell process.
The observation was that the amount of entries pending in the queue could
go up to 7500. Since all entries present in the queue will be passed to
writev an error will be returned since Linux only accepts 1024 entries to
be present in the vector. The result is that the connection is being closed.
Signed-off-by: Ronny Meeus
diff --git a/packet.c b/packet.c
--- a/packet.c
+++ b/packet.c
@@ -64,13 +64,24 @@ void write_packet() {
struct iovec *iov = NULL;
int i;
struct Link *l;
+ int iov_max_count;
#endif
TRACE2(("enter write_packet"))
dropbear_assert(!isempty(&ses.writequeue));
#ifdef HAVE_WRITEV
- iov = m_malloc(sizeof(*iov) * ses.writequeue.count);
+
+#ifndef IOV_MAX
+#define IOV_MAX UIO_MAXIOV
+#endif
+
+ /* Make sure the size of the iov is below the maximum allowed by the
OS. */
+ iov_max_count = ses.writequeue.count;
+ if (iov_max_count > IOV_MAX)
+ iov_max_count = IOV_MAX;
+
+ iov = m_malloc(sizeof(*iov) * iov_max_count);
for (l = ses.writequeue.head, i = 0; l; l = l->link, i++)
{
writebuf = (buffer*)l->item;
@@ -83,7 +94,7 @@ void write_packet() {
iov[i].iov_base = buf_getptr(writebuf, len);
iov[i].iov_len = len;
}
- written = writev(ses.sock_out, iov, ses.writequeue.count);
+ written = writev(ses.sock_out, iov, iov_max_count);
if (written < 0) {
if (errno == EINTR) {
m_free(iov);
Failed to connect to dropbear version 2020.81
Hello we have a dropbear version 2020,81 running in an old release of our SW as our login server. Currently we experience issues logging in on the system from the remote system running Openssh (using dropbear also on the client side we see a similar result). At the end of the mail I pasted the output we get. (after the trace "debug1: expecting SSH2_MSG_KEX_ECDH_REPLY", nothing is seen anymore) This issue is not seen persistently and seems to occur on random systems. After a reboot the issue seems to be resolved, not clear whether it will come back after some time or not. For the moment it is impossible to collect local traces on the server node since we cannot reach it anymore. Doing a telnet to the port is actually showing the dropbear version etc, meaning that the connection as such (at TCP level) seems to be OK. Is this a known issue and is there something we can do as a workaround (or do we have means to collect more information about the root cause)? Thanks. Best regards, Ronny ~ # ssh -p root@169.254.1.4 - OpenSSH_8.4p1, OpenSSL 1.1.1j 16 Feb 2021 debug1: Reading configuration data /etc/ssh/ssh_config debug2: resolve_canonicalize: hostname 169.254.1.4 is address debug3: expanded UserKnownHostsFile '~/.ssh/known_hosts' -> '/root/.ssh/known_hosts' debug3: expanded UserKnownHostsFile '~/.ssh/known_hosts2' -> '/root/.ssh/known_hosts2' debug1: Authenticator provider $SSH_SK_PROVIDER did not resolve; disabling debug2: ssh_connect_direct debug1: Connecting to 169.254.1.4 [169.254.1.4] port . debug1: Connection established. debug1: identity file /root/.ssh/id_rsa type -1 debug1: identity file /root/.ssh/id_rsa-cert type -1 debug1: identity file /root/.ssh/id_dsa type -1 debug1: identity file /root/.ssh/id_dsa-cert type -1 debug1: identity file /root/.ssh/id_ecdsa type -1 debug1: identity file /root/.ssh/id_ecdsa-cert type -1 debug1: identity file /root/.ssh/id_ecdsa_sk type -1 debug1: identity file /root/.ssh/id_ecdsa_sk-cert type -1 debug1: identity file /root/.ssh/id_ed25519 type -1 debug1: identity file /root/.ssh/id_ed25519-cert type -1 debug1: identity file /root/.ssh/id_ed25519_sk type -1 debug1: identity file /root/.ssh/id_ed25519_sk-cert type -1 debug1: identity file /root/.ssh/id_xmss type -1 debug1: identity file /root/.ssh/id_xmss-cert type -1 debug1: Local version string SSH-2.0-OpenSSH_8.4 debug1: Remote protocol version 2.0, remote software version dropbear_2020.81 debug1: no match: dropbear_2020.81 debug2: fd 3 setting O_NONBLOCK debug1: Authenticating to 169.254.1.4: as 'root' debug3: put_host_port: [169.254.1.4]: debug3: hostkeys_foreach: reading file "/root/.ssh/known_hosts" debug3: send packet: type 20 debug1: SSH2_MSG_KEXINIT sent debug3: receive packet: type 20 debug1: SSH2_MSG_KEXINIT received debug2: local client KEXINIT proposal debug2: KEX algorithms: curve25519-sha256,curve25519-sha...@libssh.org,ecdh-sha2-nistp256,ecdh-sha2-nistp384,ecdh-sha2-nistp521,diffie-hellman-group-exchange-sha256,diffie-hellman-group16-sha512,diffie-hellman-group18-sha512,diffie-hellman-group14-sha256,ext-info-c debug2: host key algorithms: ecdsa-sha2-nistp256-cert-...@openssh.com,ecdsa-sha2-nistp384-cert-...@openssh.com,ecdsa-sha2-nistp521-cert-...@openssh.com,sk-ecdsa-sha2-nistp256-cert-...@openssh.com,ssh-ed25519-cert-...@openssh.com,sk-ssh-ed25519-cert-...@openssh.com,rsa-sha2-512-cert-...@openssh.com,rsa-sha2-256-cert-...@openssh.com,ssh-rsa-cert-...@openssh.com,ecdsa-sha2-nistp256,ecdsa-sha2-nistp384,ecdsa-sha2-nistp521,sk-ecdsa-sha2-nistp...@openssh.com,ssh-ed25519,sk-ssh-ed25...@openssh.com,rsa-sha2-512,rsa-sha2-256,ssh-rsa debug2: ciphers ctos: chacha20-poly1...@openssh.com,aes128-ctr,aes192-ctr,aes256-ctr,aes128-...@openssh.com,aes256-...@openssh.com debug2: ciphers stoc: chacha20-poly1...@openssh.com,aes128-ctr,aes192-ctr,aes256-ctr,aes128-...@openssh.com,aes256-...@openssh.com debug2: MACs ctos: umac-64-...@openssh.com,umac-128-...@openssh.com,hmac-sha2-256-...@openssh.com,hmac-sha2-512-...@openssh.com,hmac-sha1-...@openssh.com,umac...@openssh.com,umac-...@openssh.com,hmac-sha2-256,hmac-sha2-512,hmac-sha1 debug2: MACs stoc: umac-64-...@openssh.com,umac-128-...@openssh.com,hmac-sha2-256-...@openssh.com,hmac-sha2-512-...@openssh.com,hmac-sha1-...@openssh.com,umac...@openssh.com,umac-...@openssh.com,hmac-sha2-256,hmac-sha2-512,hmac-sha1 debug2: compression ctos: none,z...@openssh.com,zlib debug2: compression stoc: none,z...@openssh.com,zlib debug2: languages ctos: debug2: languages stoc: debug2: first_kex_follows 0 debug2: reserved 0 debug2: peer server KEXINIT proposal debug2: KEX algorithms: curve25519-sha256,curve25519-sha...@libssh.org,ecdh-sha2-nistp521,ecdh-sha2-nistp384,ecdh-sha2-nistp256,diffie-hellman-group14-sha256,diffie-hellman-group14-sha1,kexgue...@matt.ucc.asn.au debug2: host key algorithms: ssh-ed25519,ecdsa-sha2-nistp256,rsa-sha2-256,ssh-rsa debug2: ciphers ctos: chacha20-poly1...@openssh.com,aes128-ctr,aes256-ctr debug2: ciphers stoc: chacha20-po
Re: Failed to connect to dropbear version 2020.81
Hello the root cause has been found in the meantime. The problem was that the file system on which the keys are stored was full. Since the dropbear is started with the -R option, the keys are generated only the first time a login is done. If at that moment there is no room left, the reported behavior is seen. Best regards Ronny Op ma 5 jun 2023 om 14:41 schreef Ronny Meeus : > > Hello > > we have a dropbear version 2020,81 running in an old release of our SW > as our login server. > Currently we experience issues logging in on the system from the > remote system running Openssh (using dropbear also on the client side > we see a similar result). > > At the end of the mail I pasted the output we get. > (after the trace "debug1: expecting SSH2_MSG_KEX_ECDH_REPLY", nothing > is seen anymore) > > This issue is not seen persistently and seems to occur on random systems. > After a reboot the issue seems to be resolved, not clear whether it > will come back after some time or not. > > For the moment it is impossible to collect local traces on the server > node since we cannot reach it anymore. > Doing a telnet to the port is actually showing the dropbear > version etc, meaning that the connection as such (at TCP level) seems > to be OK. > > Is this a known issue and is there something we can do as a workaround > (or do we have means to collect more information about the root > cause)? > > Thanks. > > Best regards, > Ronny > > ~ # ssh -p root@169.254.1.4 - > OpenSSH_8.4p1, OpenSSL 1.1.1j 16 Feb 2021 > debug1: Reading configuration data /etc/ssh/ssh_config > debug2: resolve_canonicalize: hostname 169.254.1.4 is address > debug3: expanded UserKnownHostsFile '~/.ssh/known_hosts' -> > '/root/.ssh/known_hosts' > debug3: expanded UserKnownHostsFile '~/.ssh/known_hosts2' -> > '/root/.ssh/known_hosts2' > debug1: Authenticator provider $SSH_SK_PROVIDER did not resolve; disabling > debug2: ssh_connect_direct > debug1: Connecting to 169.254.1.4 [169.254.1.4] port . > debug1: Connection established. > debug1: identity file /root/.ssh/id_rsa type -1 > debug1: identity file /root/.ssh/id_rsa-cert type -1 > debug1: identity file /root/.ssh/id_dsa type -1 > debug1: identity file /root/.ssh/id_dsa-cert type -1 > debug1: identity file /root/.ssh/id_ecdsa type -1 > debug1: identity file /root/.ssh/id_ecdsa-cert type -1 > debug1: identity file /root/.ssh/id_ecdsa_sk type -1 > debug1: identity file /root/.ssh/id_ecdsa_sk-cert type -1 > debug1: identity file /root/.ssh/id_ed25519 type -1 > debug1: identity file /root/.ssh/id_ed25519-cert type -1 > debug1: identity file /root/.ssh/id_ed25519_sk type -1 > debug1: identity file /root/.ssh/id_ed25519_sk-cert type -1 > debug1: identity file /root/.ssh/id_xmss type -1 > debug1: identity file /root/.ssh/id_xmss-cert type -1 > debug1: Local version string SSH-2.0-OpenSSH_8.4 > debug1: Remote protocol version 2.0, remote software version dropbear_2020.81 > debug1: no match: dropbear_2020.81 > debug2: fd 3 setting O_NONBLOCK > debug1: Authenticating to 169.254.1.4: as 'root' > debug3: put_host_port: [169.254.1.4]: > debug3: hostkeys_foreach: reading file "/root/.ssh/known_hosts" > debug3: send packet: type 20 > debug1: SSH2_MSG_KEXINIT sent > debug3: receive packet: type 20 > debug1: SSH2_MSG_KEXINIT received > debug2: local client KEXINIT proposal > debug2: KEX algorithms: > curve25519-sha256,curve25519-sha...@libssh.org,ecdh-sha2-nistp256,ecdh-sha2-nistp384,ecdh-sha2-nistp521,diffie-hellman-group-exchange-sha256,diffie-hellman-group16-sha512,diffie-hellman-group18-sha512,diffie-hellman-group14-sha256,ext-info-c > debug2: host key algorithms: > ecdsa-sha2-nistp256-cert-...@openssh.com,ecdsa-sha2-nistp384-cert-...@openssh.com,ecdsa-sha2-nistp521-cert-...@openssh.com,sk-ecdsa-sha2-nistp256-cert-...@openssh.com,ssh-ed25519-cert-...@openssh.com,sk-ssh-ed25519-cert-...@openssh.com,rsa-sha2-512-cert-...@openssh.com,rsa-sha2-256-cert-...@openssh.com,ssh-rsa-cert-...@openssh.com,ecdsa-sha2-nistp256,ecdsa-sha2-nistp384,ecdsa-sha2-nistp521,sk-ecdsa-sha2-nistp...@openssh.com,ssh-ed25519,sk-ssh-ed25...@openssh.com,rsa-sha2-512,rsa-sha2-256,ssh-rsa > debug2: ciphers ctos: > chacha20-poly1...@openssh.com,aes128-ctr,aes192-ctr,aes256-ctr,aes128-...@openssh.com,aes256-...@openssh.com > debug2: ciphers stoc: > chacha20-poly1...@openssh.com,aes128-ctr,aes192-ctr,aes256-ctr,aes128-...@openssh.com,aes256-...@openssh.com > debug2: MACs ctos: > umac-64-...@openssh.com,umac-128-...@openssh.com,hmac-sha2-256-...@openssh.com,hmac-sha2-512-...@openssh.com,hmac-sha1-...@openssh.com,umac...@openssh.com,umac-...@openssh.com,hmac-sha2-256,hmac-sha2-512,hmac-sha1 > debug
