#1667: ssh login to upload.osgeo.org not possible
---------------------------+-------------------
Reporter: jef | Owner: sac@…
Type: defect | Status: new
Priority: major | Milestone:
Component: Systems Admin | Keywords:
---------------------------+-------------------
Currently ssh login to upload.osgeo.org does not work (neither via
password nor key)
#1667: ssh login to upload.osgeo.org not possible
---------------------------+--------------------
Reporter: jef | Owner: sac@…
Type: defect | Status: new
Priority: major | Milestone:
Component: Systems Admin | Resolution:
Keywords: |
---------------------------+--------------------
#1667: ssh login to upload.osgeo.org not possible
---------------------------+--------------------
Reporter: jef | Owner: sac@…
Type: defect | Status: new
Priority: major | Milestone:
Component: Systems Admin | Resolution:
Keywords: |
---------------------------+--------------------
Comment (by martin):
I'm working on adding new certificates to LDAP authentication.
Upload and Qgis should be fixed already, please holler if yours still
doesn't work within 12 hours from now.
#1667: ssh login to upload.osgeo.org not possible
---------------------------+--------------------
Reporter: jef | Owner: sac@…
Type: defect | Status: new
Priority: major | Milestone:
Component: Systems Admin | Resolution:
Keywords: |
---------------------------+--------------------
Comment (by strk):
I confirm upload is fixed for me.
git.osgeo.org still fails, with:
ssh_exchange_identification: read: Connection reset by peer
#1667: ssh login to upload.osgeo.org not possible
---------------------------+--------------------
Reporter: jef | Owner: sac@…
Type: defect | Status: new
Priority: major | Milestone:
Component: Systems Admin | Resolution:
Keywords: |
---------------------------+--------------------
Comment (by martin):
Worksforme. Too many failed logins ?
Please try from a different IP and report back, Martin.
#1667: ssh login to upload.osgeo.org not possible
---------------------------+--------------------
Reporter: jef | Owner: sac@…
Type: defect | Status: new
Priority: major | Milestone:
Component: Systems Admin | Resolution:
Keywords: |
---------------------------+--------------------
#1667: ssh login to upload.osgeo.org not possible
---------------------------+--------------------
Reporter: jef | Owner: sac@…
Type: defect | Status: new
Priority: major | Milestone:
Component: Systems Admin | Resolution:
Keywords: |
---------------------------+--------------------
Comment (by strk):
Works from a different IP, so I guess it is due to "too many failed
logins". (When) will this protection expire ?
#1667: ssh login to upload.osgeo.org not possible
---------------------------+--------------------
Reporter: jef | Owner: sac@…
Type: defect | Status: new
Priority: major | Milestone:
Component: Systems Admin | Resolution:
Keywords: |
---------------------------+--------------------
Comment (by strk):
sshd logs show a `refused connect` message for my IP,but I don't see which
configuration of sshd determines that.
#1667: ssh login to upload.osgeo.org not possible
---------------------------+--------------------
Reporter: jef | Owner: sac@…
Type: defect | Status: new
Priority: major | Milestone:
Component: Systems Admin | Resolution:
Keywords: |
---------------------------+--------------------
#1667: ssh login to upload.osgeo.org not possible
---------------------------+--------------------
Reporter: jef | Owner: sac@…
Type: defect | Status: new
Priority: major | Milestone:
Component: Systems Admin | Resolution:
Keywords: |
---------------------------+--------------------
Comment (by strk):
So with the help or Jurgen the forbidding line was found in
`/etc/hosts.deny`, added on May 1st.
The ssh logs show that around that time I had multiple failing login
attempts due to LDAP service being unreachable.
Now if I remove my IP from /etc/hosts.deny I can log in, but the
hosts.deny records re-appears shortly after. Looking at "denyhosts"
configuration it seems that 1 failed login (DENY_THRESHOLD_RESTRICTED)
results in 1 week of denial (PURGE_DENY).
Adding my (static) IP to /etc/hosts.allow lets me in no matter the denial
period.
I've "solved" the issue like this. The ticket can be closed, for what
concerns myself.
On Tue, May 03, 2016 at 09:28:45AM -0400, Alex M wrote:
This sounds like fail2ban, it has a time based expiration for too many
failed login attempts. I don't recall how to cycle it manually.
It's "denyhosts", configuration is in /etc/denyhosts.conf and
there doesn't seem to be a way to "cycle" unless the purge time
is reduced (as I've saw my record being re-injected on manually
purging it) or logs are cleared up.
My personal issue was solved making my IP immune from hosts.deny
by adding it to hosts.allow.
On Tue, May 03, 2016 at 03:33:10PM +0200, Sandro Santilli wrote:
My personal issue was solved making my IP immune from hosts.deny
by adding it to hosts.allow.
This smells like opening a can of worms. How are we going to deal with
'unplanned' effects originating from your IP ?
Cheers,
Martin.
--
Unix _IS_ user friendly - it's just selective about who its friends are !
--------------------------------------------------------------------------
On Tue, May 03, 2016 at 03:46:19PM +0200, Martin Spott wrote:
On Tue, May 03, 2016 at 03:33:10PM +0200, Sandro Santilli wrote:
> My personal issue was solved making my IP immune from hosts.deny
> by adding it to hosts.allow.
This smells like opening a can of worms. How are we going to deal with
'unplanned' effects originating from your IP ?
I left a comment about removing the record starting from May 10 2016.
Yes I know it won't be automatic, but locking myself out didn't really
seem a better idea to me.
Can you see another way to let me in before next week ?
On Tue, May 03, 2016 at 03:49:04PM +0200, Sandro Santilli wrote:
Can you see another way to let me in before next week ?
Yes, by removing the traces of failed logins from /var/log/auth.log as
well as /var/lib/denyhosts/*
Cheers,
Martin.
--
Unix _IS_ user friendly - it's just selective about who its friends are !
--------------------------------------------------------------------------
On Tue, May 03, 2016 at 07:34:26PM +0200, Markus Neteler wrote:
On Tue, May 3, 2016 at 3:28 PM, Alex M <tech_dev@wildintellect.com> wrote:
> This sounds like fail2ban, it has a time based expiration for too many
> failed login attempts. I don't recall how to cycle it manually.
Stop/start the fail2ban daemon. This will reset the iptables stuff.
Could you please write these instructions on a wiki page, including
the information about _which_ machines do use fail2ban ?
TracSVN [1] machine for example does _not_ use fail2ban, but
denyhosts, maybe it would be useful to standardize on a single
technology ?
On Tue, May 3, 2016 at 7:44 PM, Sandro Santilli <strk@keybit.net> wrote:
On Tue, May 03, 2016 at 07:34:26PM +0200, Markus Neteler wrote:
On Tue, May 3, 2016 at 3:28 PM, Alex M <tech_dev@wildintellect.com> wrote:
> This sounds like fail2ban, it has a time based expiration for too many
> failed login attempts. I don't recall how to cycle it manually.
Stop/start the fail2ban daemon. This will reset the iptables stuff.
Could you please write these instructions on a wiki page, including
the information about _which_ machines do use fail2ban ?
Sure. But which page contains the list of current machines? Is it