Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]


Groups > linux.debian.user > #212768

Re: Secure Shell refuses to accept connections from anyone

From Keith Steensma <keith@airways-consulting.com>
Newsgroups linux.debian.user
Subject Re: Secure Shell refuses to accept connections from anyone
Date 2019-08-14 04:20 +0200
Message-ID <yuR3j-1LF-3@gated-at.bofh.it> (permalink)
References (4 earlier) <yuH3Y-3Ht-1@gated-at.bofh.it> <yuI9H-4lA-3@gated-at.bofh.it> <yuJ5L-4Wj-3@gated-at.bofh.it> <yuJyN-5mM-11@gated-at.bofh.it> <yuNsJ-7PC-1@gated-at.bofh.it>
Organization linux.* mail to news gateway

Show all headers | View raw


[Multipart message — attachments visible in raw view] - view raw

On 8/13/2019 5:29 PM, Keith Steensma wrote:
>
>
> On 8/13/2019 1:16 PM, Michael Howard wrote:
>> On 13/08/2019 18:40, Keith Steensma wrote:
>>>
>>>
>>> On 8/13/2019 11:35 AM, Michael Howard wrote:
>>>> On 13/08/2019 16:31, Joe wrote:
>>>>> On Tue, 13 Aug 2019 15:28:04 +0200
>>>>> <tomas@tuxteam.de> wrote:
>>>>>
>>>>>> On Tue, Aug 13, 2019 at 08:23:35AM -0500, Keith Steensma wrote:
>>>>>>>
>>>>>>> On 8/12/2019 4:00 PM, elvis wrote:
>>>>>>>> On 12/8/19 11:23 pm, Keith Steensma wrote:
>>>>>>>>> The same thing happens if I fill in 'root' as the login even
>>>>>>>>> though a 'root' login is not permitted in the default
>>>>>>>>> 'sshd_config' configuration.  Even when I change the
>>>>>>>>> configuration to allow for 'root' login, 'root' can never login.
>>>>>>>>>
>>>>>>>>
>>>>>>>> Try a local ssh login to see if it rules out network problems. As
>>>>>>>> in ssh localhost.  or ssh -l <user> localhost. If it is your
>>>>>>>> network getting in the way it may
>>>>>>>> rule that out.
>>>>>>> Yes that works ( ssh -l <user> localhost ).  So that means it 
>>>>>>> has to
>>>>>>> do with the network connections.
>>>>>> Not necessarily. It can be the client, too (your PuTTY). You didn't
>>>>>> describe the error message in detail (perhaps it is too unspecific,
>>>>>> GUI clients tend to be like that), but perhaps PuTTY has some
>>>>>> "verbose" option you can activate. Then you may infer whether 
>>>>>> there's
>>>>>> a hole in the net or whether just client and server don't get along
>>>>>> with each other.
>>>>>>
>>>>> It is some years since I used PuTTY regularly, but I seem to recall
>>>>> that it didn't use OpenSSH-type keys and insisted on generating 
>>>>> its own
>>>>> and providing a conversion to an OpenSSH key, which then had to be
>>>>> placed on the server. Is it possible this procedure may have gone 
>>>>> amiss
>>>>
>>>> This has happened to me a couple of times. Regenerating and 
>>>> converting solved the problem.
>>> It may be wrong, but I'm using putty where putty does not supply a 
>>> username or a 'key'.  I'm using it just as
>>> a terminal (does someone have an alternate suggestion).  I agree, 
>>> putty gets along with OpenSSH is a
>>>  'almost' fashion.  If you convert your 'key' in the right way.  I 
>>> have been using mine a long time just because
>>> it takes a while to get it to work correctly.
>>>
>> What is your 'PasswordAuthentication' setting? If this is 'No', you 
>> must use keys and so will see errors similar to yours.
>> -- 
>> Mike Howard
> I'm going to keep your name in my  book of experts.
Well, it turns out that all is not solved.  As long as the linux machine 
and and a Windows machine are isolated and each is running a static IP, 
everything works (no internet connection) and a normal user and 'root' 
can log in just fine.  But the minute I add a internet connection (and 
gateway IP) everything goes back the way it was with the normal user  
getting a "Access denied" error and another request for a password and 
root (with a good putty configured 'key') getting a 'Server refused our 
key' and a "Access denied' error' followed by a 'request for a new 
password.
You asked for a copy of my sshd_config file, so here it is (below my name)
I sure do hope that you can find a error in there that will explain things.
The auth.log has nothing in it and the putty log has nothing other than 
the authentication and the password both failed.  I suppose that may 
mean that the putty key pair is bad (and I guess I will have to generate 
a new pair and proof it again my one and only working machine just to 
make sure).
Hope you come up with something.

Thanks for your help so far.  Keith

Keith
===============================
#       $OpenBSD: sshd_config,v 1.103 2018/04/09 20:41:22 tj Exp $

# This is the sshd server system-wide configuration file.  See
# sshd_config(5) for more information.

# This sshd was compiled with PATH=/usr/bin:/bin:/usr/sbin:/sbin

# The strategy used for options in the default sshd_config shipped with
# OpenSSH is to specify options with their default value where
# possible, but leave them commented.  Uncommented options override the
# default value.

#Port 22
#AddressFamily any
#ListenAddress 0.0.0.0
#ListenAddress ::

#HostKey /etc/ssh/ssh_host_rsa_key
#HostKey /etc/ssh/ssh_host_ecdsa_key
#HostKey /etc/ssh/ssh_host_ed25519_key

# Ciphers and keying
#RekeyLimit default none

# Logging
#SyslogFacility AUTH
#LogLevel INFO
LogLevel VERBOSE

# Authentication:

#LoginGraceTime 2m
PermitRootLogin yes
#StrictModes yes
#MaxAuthTries 6
#MaxSessions 10

#PubkeyAuthentication yes

# Expect .ssh/authorized_keys2 to be disregarded by default in future.
#AuthorizedKeysFile     .ssh/authorized_keys .ssh/authorized_keys2

#AuthorizedPrincipalsFile none

#AuthorizedKeysCommand none
#AuthorizedKeysCommandUser nobody

# For this to work you will also need host keys in /etc/ssh/ssh_known_hosts
#HostbasedAuthentication no
# Change to yes if you don't trust ~/.ssh/known_hosts for
# HostbasedAuthentication
#IgnoreUserKnownHosts no
# Don't read the user's ~/.rhosts and ~/.shosts files
#IgnoreRhosts yes

# To disable tunneled clear text passwords, change to no here!
PasswordAuthentication yes
#PermitEmptyPasswords no


# Change to yes to enable challenge-response passwords (beware issues with
# some PAM modules and threads)
ChallengeResponseAuthentication no

# Kerberos options
#KerberosAuthentication no
#KerberosOrLocalPasswd yes
#KerberosTicketCleanup yes
#KerberosGetAFSToken no

# GSSAPI options
#GSSAPIAuthentication no
#GSSAPICleanupCredentials yes
#GSSAPIStrictAcceptorCheck yes
#GSSAPIKeyExchange no

# Change to yes to enable challenge-response passwords (beware issues with
# some PAM modules and threads)
ChallengeResponseAuthentication no

# Kerberos options
#KerberosAuthentication no
#KerberosOrLocalPasswd yes
#KerberosTicketCleanup yes
#KerberosGetAFSToken no

# GSSAPI options
#GSSAPIAuthentication no
#GSSAPICleanupCredentials yes
#GSSAPIStrictAcceptorCheck yes
#GSSAPIKeyExchange no

# Set this to 'yes' to enable PAM authentication, account processing,
# and session processing. If this is enabled, PAM authentication will
# be allowed through the ChallengeResponseAuthentication and
# PasswordAuthentication.  Depending on your PAM configuration,
# PAM authentication via ChallengeResponseAuthentication may bypass
# the setting of "PermitRootLogin without-password".
# If you just want the PAM account and session checks to run without
# PAM authentication, then enable this but set PasswordAuthentication
# and ChallengeResponseAuthentication to 'no'.
UsePAM yes

#AllowAgentForwarding yes
#AllowTcpForwarding yes
#GatewayPorts no
X11Forwarding yes
#X11DisplayOffset 10
#X11UseLocalhost yes
#PermitTTY yes
PrintMotd no
#PrintLastLog yes
#TCPKeepAlive yes
#PermitUserEnvironment no
#Compression delayed
#ClientAliveInterval 0
#ClientAliveCountMax 3
#UseDNS no
#PidFile /var/run/sshd.pid
#MaxStartups 10:30:100
#PermitTunnel no
#ChrootDirectory none
#VersionAddendum none

# no default banner path
#Banner none

# Allow client to pass locale environment variables
AcceptEnv LANG LC_*

# override default of no subsystems
Subsystem       sftp    /usr/lib/openssh/sftp-server

# Example of overriding settings on a per-user basis
#Match User anoncvs
#       X11Forwarding no
#       AllowTcpForwarding no
#       PermitTTY no
#       ForceCommand cvs server


Back to linux.debian.user | Previous | Next — Previous in thread | Next in thread | Find similar | Unroll thread


Thread

Secure Shell refuses to accept connections from anyone Keith Steensma <keith@airways-consulting.com> - 2019-08-12 15:40 +0200
  Re: Secure Shell refuses to accept connections from anyone john doe <johndoe65534@mail.com> - 2019-08-12 16:20 +0200
    Re: Secure Shell refuses to accept connections from anyone Keith Steensma <keith@airways-consulting.com> - 2019-08-12 16:50 +0200
      Re: Secure Shell refuses to accept connections from anyone john doe <johndoe65534@mail.com> - 2019-08-12 17:00 +0200
  Re: Secure Shell refuses to accept connections from anyone Roberto C. Sánchez <roberto@debian.org> - 2019-08-12 16:30 +0200
    Re: Secure Shell refuses to accept connections from anyone Roberto C. Sánchez <roberto@debian.org> - 2019-08-12 16:40 +0200
    Re: Secure Shell refuses to accept connections from anyone Dan Ritter <dsr@randomstring.org> - 2019-08-12 16:40 +0200
      Re: Secure Shell refuses to accept connections from anyone john doe <johndoe65534@mail.com> - 2019-08-12 16:50 +0200
      Re: Secure Shell refuses to accept connections from anyone Keith Steensma <keith@airways-consulting.com> - 2019-08-12 16:50 +0200
        Re: Secure Shell refuses to accept connections from anyone mick crane <mick.crane@gmail.com> - 2019-08-12 22:00 +0200
    Re: Secure Shell refuses to accept connections from anyone Keith Steensma <keith@airways-consulting.com> - 2019-08-12 16:40 +0200
  Re: Secure Shell refuses to accept connections from anyone mick crane <mick.crane@gmail.com> - 2019-08-12 16:40 +0200
  Re: Secure Shell refuses to accept connections from anyone Bruce Halco <bruce@halcomp.com> - 2019-08-12 16:50 +0200
  Re: Secure Shell refuses to accept connections from anyone Andrei POPESCU <andreimpopescu@gmail.com> - 2019-08-12 21:10 +0200
  Re: Secure Shell refuses to accept connections from anyone elvis <elvis@dogonfire.com> - 2019-08-12 23:10 +0200
    Re: Secure Shell refuses to accept connections from anyone <tomas@tuxteam.de> - 2019-08-13 15:30 +0200
      Re: Secure Shell refuses to accept connections from anyone Joe <joe@jretrading.com> - 2019-08-13 17:40 +0200
        Re: Secure Shell refuses to accept connections from anyone Michael Howard <mike@dewberryfields.co.uk> - 2019-08-13 18:50 +0200
          Re: Secure Shell refuses to accept connections from anyone Keith Steensma <keith@airways-consulting.com> - 2019-08-13 19:50 +0200
            Re: Secure Shell refuses to accept connections from anyone john doe <johndoe65534@mail.com> - 2019-08-13 20:10 +0200
            Re: Secure Shell refuses to accept connections from anyone Michael Howard <mike@dewberryfields.co.uk> - 2019-08-13 20:20 +0200
              Re: Secure Shell refuses to accept connections from anyone Keith Steensma <keith@airways-consulting.com> - 2019-08-14 00:30 +0200
                Re: Secure Shell refuses to accept connections from anyone Keith Steensma <keith@airways-consulting.com> - 2019-08-14 04:20 +0200
                Re: Secure Shell refuses to accept connections from anyone Bruce Halco <bruce@halcomp.com> - 2019-08-14 12:30 +0200
                Re: Secure Shell refuses to accept connections from anyone Michael Howard <mike@dewberryfields.co.uk> - 2019-08-14 13:40 +0200
              Re: Secure Shell refuses to accept connections from anyone Keith Steensma <keith@airways-consulting.com> - 2019-08-14 00:30 +0200
    Re: Secure Shell refuses to accept connections from anyone Keith Steensma <keith@airways-consulting.com> - 2019-08-13 15:30 +0200

csiph-web