Mailing List Archive

strange failure
There is a Centos 7 machine where this falls after 80 loops

target="same host"
while [ $i -ne 500 ];do
echo -e "$i"
ssh -p 22 root@${target} "ls / 1>/dev/null && exit;"
((i++))
done
The loop does not fail against Ubuntu boxes.
kindly let me know if I am doing something wrong.

This is my sshd_config
sshd -T
port 22
addressfamily any
listenaddress [::]:22
listenaddress 0.0.0.0:22
usepam no
logingracetime 120
x11displayoffset 10
maxauthtries 20
maxsessions 100
clientaliveinterval 0
clientalivecountmax 3
streamlocalbindmask 0177
permitrootlogin without-password
ignorerhosts yes
ignoreuserknownhosts no
hostbasedauthentication no
hostbasedusesnamefrompacketonly no
pubkeyauthentication yes
kerberosauthentication no
kerberosorlocalpasswd yes
kerberosticketcleanup yes
gssapiauthentication no
gssapicleanupcredentials yes
passwordauthentication no
kbdinteractiveauthentication yes
challengeresponseauthentication yes
printmotd yes
printlastlog yes
x11forwarding no
x11uselocalhost yes
permittty yes
permituserrc yes
strictmodes no
tcpkeepalive yes
permitemptypasswords no
compression yes
gatewayports no
usedns no
allowtcpforwarding yes
allowagentforwarding yes
disableforwarding no
allowstreamlocalforwarding yes
streamlocalbindunlink no
fingerprinthash SHA256
exposeauthinfo no
pidfile /var/run/sshd.pid
xauthlocation /usr/bin/xauth
ciphers chacha20-poly1305@openssh.com,aes128-ctr,aes192-ctr,aes256-ctr,
aes128-gcm@openssh.com,aes256-gcm@openssh.com
macs umac-64-etm@openssh.com,umac-128-etm@openssh.com,
hmac-sha2-256-etm@openssh.com,hmac-sha2-512-etm@openssh.com,
hmac-sha1-etm@openssh.com,umac-64@openssh.com,umac-128@openssh.com
,hmac-sha2-256,hmac-sha2-512,hmac-sha1
banner none
forcecommand none
chrootdirectory none
trustedusercakeys none
revokedkeys none
authorizedprincipalsfile none
versionaddendum none
authorizedkeyscommand none
authorizedkeyscommanduser none
authorizedprincipalscommand none
authorizedprincipalscommanduser none
hostkeyagent none
kexalgorithms curve25519-sha256,curve25519-sha256@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,diffie-hellman-group14-sha1
casignaturealgorithms
ecdsa-sha2-nistp256,ecdsa-sha2-nistp384,ecdsa-sha2-nistp521,ssh-ed25519,rsa-sha2-512,rsa-sha2-256,ssh-rsa
hostbasedacceptedkeytypes ecdsa-sha2-nistp256-cert-v01@openssh.com,
ecdsa-sha2-nistp384-cert-v01@openssh.com,
ecdsa-sha2-nistp521-cert-v01@openssh.com,ssh-ed25519-cert-v01@openssh.com,
rsa-sha2-512-cert-v01@openssh.com,rsa-sha2-256-cert-v01@openssh.com,
ssh-rsa-cert-v01@openssh.com
,ecdsa-sha2-nistp256,ecdsa-sha2-nistp384,ecdsa-sha2-nistp521,ssh-ed25519,rsa-sha2-512,rsa-sha2-256,ssh-rsa
hostkeyalgorithms ecdsa-sha2-nistp256-cert-v01@openssh.com,
ecdsa-sha2-nistp384-cert-v01@openssh.com,
ecdsa-sha2-nistp521-cert-v01@openssh.com,ssh-ed25519-cert-v01@openssh.com,
rsa-sha2-512-cert-v01@openssh.com,rsa-sha2-256-cert-v01@openssh.com,
ssh-rsa-cert-v01@openssh.com
,ecdsa-sha2-nistp256,ecdsa-sha2-nistp384,ecdsa-sha2-nistp521,ssh-ed25519,rsa-sha2-512,rsa-sha2-256,ssh-rsa
pubkeyacceptedkeytypes ecdsa-sha2-nistp256-cert-v01@openssh.com,
ecdsa-sha2-nistp384-cert-v01@openssh.com,
ecdsa-sha2-nistp521-cert-v01@openssh.com,ssh-ed25519-cert-v01@openssh.com,
rsa-sha2-512-cert-v01@openssh.com,rsa-sha2-256-cert-v01@openssh.com,
ssh-rsa-cert-v01@openssh.com
,ecdsa-sha2-nistp256,ecdsa-sha2-nistp384,ecdsa-sha2-nistp521,ssh-ed25519,rsa-sha2-512,rsa-sha2-256,ssh-rsa
rdomain none
loglevel INFO
syslogfacility AUTH
authorizedkeysfile .ssh/authorized_keys
hostkey /etc/ssh/ssh_host_rsa_key
hostkey /etc/ssh/ssh_host_ecdsa_key
hostkey /etc/ssh/ssh_host_ed25519_key
allowusers root
authenticationmethods any
subsystem sftp /usr/libexec/sftp-server
maxstartups 500:30:500
permittunnel no
ipqos af21 cs1
rekeylimit 0 0
permitopen any
permitlisten any
permituserenvironment no
_______________________________________________
openssh-unix-dev mailing list
openssh-unix-dev@mindrot.org
https://lists.mindrot.org/mailman/listinfo/openssh-unix-dev
Re: strange failure [ In reply to ]
Hi,

Saint Michael wrote:
> There is a Centos 7 machine where this falls after 80 loops
>
> target="same host"
> while [ $i -ne 500 ];do
> echo -e "$i"
> ssh -p 22 root@${target} "ls / 1>/dev/null && exit;"
> ((i++))
> done
> The loop does not fail against Ubuntu boxes.

Can you describe the failure? Is there any error message?


> kindly let me know if I am doing something wrong.

There's nothing wrong with the above snippet - that should always
result in 500 times ls output.


> This is my sshd_config

That looks fine to me, nothing in there strikes me as a cause for
intermittent issues.


One thing to keep in mind is that nearly all Linux distributions make
modifications to lots of packages, including OpenSSH, and I've experienced
such distributions changes to cause their OpenSSH packages to malfunction
while the upstream version (as published by this community) doesn't have
those same issues. It can be worthwhile to build the corresponding
upstream version yourself and retest.


Kind regards

//Peter
_______________________________________________
openssh-unix-dev mailing list
openssh-unix-dev@mindrot.org
https://lists.mindrot.org/mailman/listinfo/openssh-unix-dev
Re: strange failure [ In reply to ]
On Sun, 25 Jul 2021, Peter Stuge wrote:

> Can you describe the failure? Is there any error message?

Also look in syslog. Could be some kind of rate limiter.

bye,
//mirabilos
--
Infrastrukturexperte • tarent solutions GmbH
Am Dickobskreuz 10, D-53121 Bonn • http://www.tarent.de/
Telephon +49 228 54881-393 • Fax: +49 228 54881-235
HRB AG Bonn 5168 • USt-ID (VAT): DE122264941
Geschäftsführer: Dr. Stefan Barth, Kai Ebenrett, Boris Esser, Alexander Steeg

*************************************************

Mit dem tarent-Newsletter nichts mehr verpassen: www.tarent.de/newsletter

*************************************************
_______________________________________________
openssh-unix-dev mailing list
openssh-unix-dev@mindrot.org
https://lists.mindrot.org/mailman/listinfo/openssh-unix-dev
Re: strange failure [ In reply to ]
On Sun, 25 Jul 2021, Saint Michael wrote:

> There is a Centos 7 machine where this falls after 80 loops
>
> target="same host"
> while [ $i -ne 500 ];do
> echo -e "$i"
> ssh -p 22 root@${target} "ls / 1>/dev/null && exit;"
> ((i++))
> done
> The loop does not fail against Ubuntu boxes.
> kindly let me know if I am doing something wrong.

It's very hard to figure out what is wrong without logs (both client
and server), but I'd start by checking your PAM configuration.

-d
_______________________________________________
openssh-unix-dev mailing list
openssh-unix-dev@mindrot.org
https://lists.mindrot.org/mailman/listinfo/openssh-unix-dev
Re: strange failure [ In reply to ]
On Sun, Jul 25, 2021 at 10:32 PM Damien Miller <djm@mindrot.org> wrote:
>
> On Sun, 25 Jul 2021, Saint Michael wrote:
>
> > There is a Centos 7 machine where this falls after 80 loops
> >
> > target="same host"
> > while [ $i -ne 500 ];do
> > echo -e "$i"
> > ssh -p 22 root@${target} "ls / 1>/dev/null && exit;"
> > ((i++))
> > done
> > The loop does not fail against Ubuntu boxes.
> > kindly let me know if I am doing something wrong.
>
> It's very hard to figure out what is wrong without logs (both client
> and server), but I'd start by checking your PAM configuration.

Stop playing with redirects and funkified exit values on the far end
if you don't have to. Just use ""/bin/true". And print $i locally,
with a success or failure, to see *exactly* how many successful
connections you get.

Some smart alecks put in various rate limiting on intervening
firewalls or proxies, to limit port scanning and host scanning. You
might check there as well.
_______________________________________________
openssh-unix-dev mailing list
openssh-unix-dev@mindrot.org
https://lists.mindrot.org/mailman/listinfo/openssh-unix-dev
Re: strange failure [ In reply to ]
I am connecting to 127.0.01 and the problem persists. I am not using PAM.
But thanks for the /bin/true tip.



On Mon, Jul 26, 2021 at 12:44 AM Nico Kadel-Garcia <nkadel@gmail.com> wrote:

> On Sun, Jul 25, 2021 at 10:32 PM Damien Miller <djm@mindrot.org> wrote:
> >
> > On Sun, 25 Jul 2021, Saint Michael wrote:
> >
> > > There is a Centos 7 machine where this falls after 80 loops
> > >
> > > target="same host"
> > > while [ $i -ne 500 ];do
> > > echo -e "$i"
> > > ssh -p 22 root@${target} "ls / 1>/dev/null && exit;"
> > > ((i++))
> > > done
> > > The loop does not fail against Ubuntu boxes.
> > > kindly let me know if I am doing something wrong.
> >
> > It's very hard to figure out what is wrong without logs (both client
> > and server), but I'd start by checking your PAM configuration.
>
> Stop playing with redirects and funkified exit values on the far end
> if you don't have to. Just use ""/bin/true". And print $i locally,
> with a success or failure, to see *exactly* how many successful
> connections you get.
>
> Some smart alecks put in various rate limiting on intervening
> firewalls or proxies, to limit port scanning and host scanning. You
> might check there as well.
>
_______________________________________________
openssh-unix-dev mailing list
openssh-unix-dev@mindrot.org
https://lists.mindrot.org/mailman/listinfo/openssh-unix-dev
Re: strange failure [ In reply to ]
On Mon, 26 Jul 2021, Saint Michael wrote:

> I am connecting to 127.0.01 and the problem persists. I am not using PAM.
> But thanks for the /bin/true tip.

Have you explicitly disabled it in sshd_config? If not, and you are
using your vendor's OpenSSH package then you are using PAM.

-d
_______________________________________________
openssh-unix-dev mailing list
openssh-unix-dev@mindrot.org
https://lists.mindrot.org/mailman/listinfo/openssh-unix-dev
Re: strange failure [ In reply to ]
Yes, I did disable it
It's a mystery.


On Mon, Jul 26, 2021, 8:47 PM Damien Miller <djm@mindrot.org> wrote:

> On Mon, 26 Jul 2021, Saint Michael wrote:
>
> > I am connecting to 127.0.01 and the problem persists. I am not using PAM.
> > But thanks for the /bin/true tip.
>
> Have you explicitly disabled it in sshd_config? If not, and you are
> using your vendor's OpenSSH package then you are using PAM.
>
> -d
>
_______________________________________________
openssh-unix-dev mailing list
openssh-unix-dev@mindrot.org
https://lists.mindrot.org/mailman/listinfo/openssh-unix-dev