Hi David,
> After the latest update to openssh 7.7p1-2
What version didn't have the problem? For example, /var/log/pacman.log
should help determine you were running 7.6p1-2 for a while without the
issue.
> (it's a pilot thing, every time
> I'm watching something with an interest in the time is 1-1000, 2-1000, 3-1000,
> etc..)
One can use time(1).
$ time ssh foo :
real 0m0.851s
user 0m0.067s
sys 0m0.019s
$
> Did the last update add some type of timer to intentionally slow the
> connection time to discourage or combat DOS type attacks?
That wouldn't have happened; it would penalise to many for little gain
when there's better methods of punishing the repeated attempts at login.
> It's like there is something between:
>
> 09:20:24 phoinix systemd[1]: Started Session c18 of user david.
> and
> 09:20:28 phoinix sshd[2654]: Received disconnect from 66.76.46.195
> port 59956:11: disconnected by user
Yes, I'd guess a timeout on a DNS query on the network.
> Also interestingly, the 5 boxes on my lan that are in the backup
> list do not show this type of delay.
...
> Jul 17 09:18:50 valkyrie sshd[1327]: Received disconnect from
> 192.168.6.104 port 52414:11: disconnected by user
I'd strongly suspect a timeout on a DNS query on the network. :-)
It's probably attempting a reverse-DNS looking on the incoming IP
address 66.76.46.195 that's not getting any answers whereas the LAN
192.168.6.104 doesn't suffer.
To confirm, you could try adding 66.76.46.195 to /etc/hosts. It might
be necessary to `systemctl restart sshd.service'. There's also `UseDNS'
in sshd_config(5).
--
Cheers, Ralph.
https://plus.google.com/+RalphCorderoy
