doublecheck my sshd config

y7dk9 · 2020-03-12 10:51:09

Since on my server I get many errors of the form

sshd[639]: error: kex_exchange_identification: read: Connection reset by peer
sshd[782]: error: kex_exchange_identification: Connection closed by remote host

I wanted to doublecheck my

cat /etc/ssh/sshd_config
Protocol 2
HostKey /etc/ssh/ssh_host_ed25519_key
HostKey /etc/ssh/ssh_host_rsa_key
KexAlgorithms curve25519-sha256@libssh.org
Ciphers chacha20-poly1305@openssh.com
MACs hmac-sha2-512-etm@openssh.com
PermitRootLogin no
PasswordAuthentication no
ChallengeResponseAuthentication no
PubkeyAuthentication yes
AuthorizedKeysFile .ssh/authorized_keys
AllowUsers y7dk9

Is there anything I could improve on the sshd side?
Is there anything I could remove, e.g. PubkeyAuthentication defautls to yes, so it should be safe to remove it?

Zod · 2020-03-12 13:06:33

y7dk9 wrote:

Is there anything I could improve on the sshd side?

Yes there is.

Assuming your trying to use openssh you could go to openssh.com
and learn how to use it.

Last edited by Zod (2020-03-12 13:08:52)

eschwartz · 2020-03-12 13:27:41

Zod wrote:

y7dk9 wrote:
Is there anything I could improve on the sshd side?
Yes there is.
Assuming your trying to use openssh you could go to openssh.com
and learn how to use it.

Is this some version of "I have literally no idea what your problem is, but I'm sure it is your fault for not RTFM, so go RTFM at the upstream website"? Because I don't understand how anything you said is expected to answer the OP's question.

y7dk9 wrote:

Since on my server I get many errors of the form

sshd[639]: error: kex_exchange_identification: read: Connection reset by peer
sshd[782]: error: kex_exchange_identification: Connection closed by remote host

So I'm going to guess that this used to work, and suddenly stopped. Have you read this news post, and did/does it help you successfully log in? https://www.archlinux.org/news/sshd-nee … nssh-82p1/

Zod · 2020-03-12 13:37:29

Acshully I do know what the problem is.

This person has installed openssh and has no idea how to get logged in. Unfortunately the default installation won't let you you just login, that's why it's important that some effort go into learning how it works.

I also know that this person doesn't just want someone to double check the config, what's expected is for someone to give it on a platter.

While that might be the merciful thing to do, this person will have learned nothing except that it's easy to come here because you will tell him/her how to do it.

eschwartz · 2020-03-12 14:29:48

And you know this because why?

I haven't given anything on a platter, I have however pointed out an alternative explanation that does, in fact, require learning how to read the Arch Linux News. And furthermore, I backed up my assumption by explicitly stating that my advice is advice which is suitable for the case of someone who *used* to be able to login via ssh, and cannot anymore. It is now up to the OP to confirm whether that assumption holds true, if not, we can ask where the sshd_config in question came from and/or ask whether it still works with the stock one, etc.

It doesn't take rocket science to use openssh, and I find it strange that you think it does. It's sufficient to start the sshd.service and use the default-enabled password-based authentication, so "Unfortunately the default installation won't let you you just login" is totally incorrect. (This OP's sshd_config may have issues with it, but if so, then you can darn well say so rather than blaming it on "the default installation".)

Last edited by eschwartz (2020-03-12 14:31:05)

seth · 2020-03-12 14:41:29

There's an explicit AllowUsers entry with the OPs name in the config, so it's probably not the stock config.
The client canceled the login, so either it's due to the required server restart, or a buggy client or the connection is open to the WAN …

@y7dk9 the errors indicate a broken connection, thus failed login.
But this is due to action on the other side.
=> Do you have actual trouble w/ the ssh login or are you just curious about the log entries?

In the latter case, you've probably opened port 22 to the internet and get a lot of chatter.
You could post the entire sshd log (not only the error strings) or look at it yourself, there're likely invalid user/password entries and shady IPs

Zod · 2020-03-12 15:26:57

eschwartz wrote:

And you know this because why?

Primarily because I can read what is posted and see why it's not working.

eschwartz wrote:

I haven't given anything on a platter,

Good deal.

eschwartz wrote:

I have however pointed out an alternative explanation that does, in fact, require learning how to read the Arch Linux News. And furthermore, I backed up my assumption by explicitly stating that my advice is advice which is suitable for the case of someone who *used* to be able to login via ssh, and cannot anymore.

No, you are just guessing, if you read what is posted it is obvious what the problem is. My advise, to go to the source and RTFM is at least as relevant as what was offered by you. You backed up nothing, you assumed it was working and now it's not, there is nothing in the OP that would suggest that.

eshwartz wrote:

It is now up to the OP to confirm whether that assumption holds true, if not, we can ask where the sshd_config in question came from and/or ask whether it still works with the stock one, etc.

That's right, the OP can go read a news item, OR the OP can go RTFM and learn how ssh authentication works.

eschwartz wrote:

It doesn't take rocket science to use openssh, and I find it strange that you think it does. It's sufficient to start the sshd.service and use the default-enabled password-based authentication, so "Unfortunately the default installation won't let you you just login" is totally incorrect. (This OP's sshd_config may have issues with it, but if so, then you can darn well say so rather than blaming it on "the default installation".)

Well, I'll leave that with what we know. It's right there in in the OP. As to whether its "Rocket Science" or not, I'll leave the assumptions to you. Again, it is what it is, it's right there in the OP.

eschwartz wrote:

It doesn't take rocket science to use openssh, and I find it strange that you think it does. It's sufficient to start the sshd.service and use the default-enabled password-based authentication, so "Unfortunately the default installation won't let you you just login" is totally incorrect.

Fine, I won't argue the point.

eschwartz wrote:

(This OP's sshd_config may have issues with it, but if so, then you can darn well say so rather than blaming it on "the default installation".)

I didn't *blame* it on anything, I suggested that the OP go to the source and RTFM and *learn* how to use openssh. Learning how to setup authentication is part of that.

eschwartz wrote:

Is this some version of "I have literally no idea what your problem is, but I'm sure it is your fault for not RTFM, so go RTFM at the upstream website"? Because I don't understand how anything you said is expected to answer the OP's question.

See, this is where the problem lies, it's you making assumptions. And what, exactly, is wrong with RTFM when you(?) and I both can see the problem right there in black and white? It's a simple configuration error, you suggested reading a news article, I suggested RTFM and learning how to use the software.

But you didn't stop there, did you, you felt it necessary to attack me. Fine, I can live with that. But in the long run, who gave the better advise, you or me?

Last edited by Zod (2020-03-12 15:28:52)

schard · 2020-03-12 16:11:02

@y7dk9:
Please also post the output of

ssh -vvv <your_target_host>

So we can see what's actually going on on the client side.

seth · 2020-03-12 16:13:02

My eyes have probably taken a covid-19 hit, but I didn't see the OP mentioning that *his* login fails at all.
He only concerns failed login attempts in the sshd log.

The sshd config is rather restrictive, but *can* very much work (but for limited clients) so I suggest to wait for the OP to clarify on his actual concern - as far as I'm concerned, everybody is assuming stuff so far.

Until then, I suggest everybody to dial down - this thread currently reminds me of the ugly mess that made Trilby quit (temporarily ;-)

Zod wrote:

I also know that this person doesn't just want someone to double check the config, what's expected is for someone to give it on a platter.

If anybody has side-channel information on the OP (eg. from IRC) it would be fair and helpful to share that information, rather than making vague accusations.

eschwartz · 2020-03-12 16:29:51

Zod wrote:

But you didn't stop there, did you, you felt it necessary to attack me. Fine, I can live with that. But in the long run, who gave the better advise, you or me?

My sole problem with what you said has been explained much better by seth:

seth wrote:

The sshd config is rather restrictive, but *can* very much work (but for limited clients) [...]

and

seth wrote:

Zod wrote:
I also know that this person doesn't just want someone to double check the config, what's expected is for someone to give it on a platter.
If anybody has side-channel information on the OP (eg. from IRC) it would be fair and helpful to share that information, rather than making vague accusations.

So I think it would be great if the OP can clarify whether they are having personal problems getting access (and if so, whether the news helps) or are simply curious what the logs mean, or what all else may have sparked their initial post. Because yeah, @y7dk9 has been fairly confusing on that matter.

And if anyone is going to make theories about what may have sparked their initial post, then it would be nice if that is clearly marked as a theory, rather than a fact.

Arch Linux

#1 2020-03-12 10:51:09

doublecheck my sshd config

#2 2020-03-12 13:06:33

Re: doublecheck my sshd config

#3 2020-03-12 13:27:41

Re: doublecheck my sshd config

#4 2020-03-12 13:37:29

Re: doublecheck my sshd config

#5 2020-03-12 14:29:48

Re: doublecheck my sshd config

#6 2020-03-12 14:41:29

Re: doublecheck my sshd config

#7 2020-03-12 15:26:57

Re: doublecheck my sshd config

#8 2020-03-12 16:11:02

Re: doublecheck my sshd config

#9 2020-03-12 16:13:02

Re: doublecheck my sshd config

#10 2020-03-12 16:29:51

Re: doublecheck my sshd config

Board footer