Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]
Groups > linux.debian.user > #212768
| 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 |
[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
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