Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]
Groups > linux.debian.user > #212683 > unrolled thread
| Started by | Keith Steensma <keith@airways-consulting.com> |
|---|---|
| First post | 2019-08-12 15:40 +0200 |
| Last post | 2019-08-13 15:30 +0200 |
| Articles | 7 on this page of 27 — 11 participants |
Back to article view | Back to linux.debian.user
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
Page 2 of 2 — ← Prev page 1 [2]
| From | Michael Howard <mike@dewberryfields.co.uk> |
|---|---|
| Date | 2019-08-13 20:20 +0200 |
| Message-ID | <yuJyN-5mM-11@gated-at.bofh.it> |
| In reply to | #212755 |
[Multipart message — attachments visible in raw view] — view raw
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
[toc] | [prev] | [next] | [standalone]
| From | Keith Steensma <keith@airways-consulting.com> |
|---|---|
| Date | 2019-08-14 00:30 +0200 |
| Message-ID | <yuNsJ-7PC-1@gated-at.bofh.it> |
| In reply to | #212758 |
[Multipart message — attachments visible in raw view] — view raw
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.
[toc] | [prev] | [next] | [standalone]
| From | Keith Steensma <keith@airways-consulting.com> |
|---|---|
| Date | 2019-08-14 04:20 +0200 |
| Message-ID | <yuR3j-1LF-3@gated-at.bofh.it> |
| In reply to | #212765 |
[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
[toc] | [prev] | [next] | [standalone]
| From | Bruce Halco <bruce@halcomp.com> |
|---|---|
| Date | 2019-08-14 12:30 +0200 |
| Message-ID | <yuYHv-6Cu-1@gated-at.bofh.it> |
| In reply to | #212768 |
On 8/13/19 10:18 PM, Keith Steensma wrote: > > > 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. A long time ago I settled on having to use puttygen.exe to generate the keys. You have to copy/paste from the puttygen window to create the authorized_keys file. A nuisance but it works reliably. Bruce
[toc] | [prev] | [next] | [standalone]
| From | Michael Howard <mike@dewberryfields.co.uk> |
|---|---|
| Date | 2019-08-14 13:40 +0200 |
| Message-ID | <yuZNf-7hw-1@gated-at.bofh.it> |
| In reply to | #212768 |
[Multipart message — attachments visible in raw view] — view raw
On 14/08/2019 03:18, Keith Steensma wrote: > > > 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 Not looked at your config file as yet but if it works isolated, it works. The problem now is more likely a different problem. What version of ssh do you have installed? Have you checked your log files to ensure that, when connected to the internet, you are actually trying to connect to the correct machine? If the machine you think you are connecting to really is refusing connections, what are the logs saying? -- Mike Howard
[toc] | [prev] | [next] | [standalone]
| From | Keith Steensma <keith@airways-consulting.com> |
|---|---|
| Date | 2019-08-14 00:30 +0200 |
| Message-ID | <yuNsK-7PC-3@gated-at.bofh.it> |
| In reply to | #212758 |
[Multipart message — attachments visible in raw view] — view raw
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 Apparently I was saying 'NO' because the line was still commented out (default was 'NO'?) Now it changed to 'YES' Well Sir: You get the Silver Dollar. It works Now how do I deliver it to you. By carrier pigeon. Would that be alright? Keith
[toc] | [prev] | [next] | [standalone]
| From | Keith Steensma <keith@airways-consulting.com> |
|---|---|
| Date | 2019-08-13 15:30 +0200 |
| Message-ID | <yuF2a-2qV-21@gated-at.bofh.it> |
| In reply to | #212713 |
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. But these are all in-house connections that are sitting right on my workbench. The switch and cables are less than a year old (I know that doesn't mean much). But if you think this problem is pointing toward a network condition, I can sure change out some things real fast and prove that right or wrong.
[toc] | [prev] | [standalone]
Page 2 of 2 — ← Prev page 1 [2]
Back to top | Article view | linux.debian.user
csiph-web