hello chaps,

I have a server that has sshd open to the world. As you might have imagined, I am getting all kinds of login attempts on the server. I am using denyhosts (I love it) to deal with these people. There is one thing that I am interested in however, is there a way to see what password they are using to try and authenticate? The strings look like this:

I wanted to make a list of all the passwords that are attempted against my machine. Also, I have not permitted root to be able to login (sshd_config) but I still see root attempts to login. Does it allow them to try to authenticate with that user and even if they get the password right, they cannot login?

Thanks for reading,

tark

Not really.

Why?..


Please ensure you don't use tcp_wrappers but iptables (or better: ipset).


Not with the default OpenSSH-portable version of the software, no.


What's the purpose? Just curious, OK?


First of all you shouldn't be using passwords but pubkey auth.
Second if root isn't allowed to log in in sshd_config then they can't (something you could have tried yourself BTW).

Thank you for your responses!

1. I have it open to the world so that I can access it from anywhere. I suppose I could lock it down to just a few IP addresses, need to figure out how to do that.

2. How do I do that? Is that in the denyhosts.conf?

3. I was just curious that was all. I think it would be quite interesting.

4. The reason I have not tried it yet is because I have been remote for a little while and I did not want to accidentally ban my IP, then have a hard time getting back to the box.

Might I suggest putting the sshd on another port so that you don't get quite so many hits? It's not a security thing (since it's just obscurity) but it cuts down on log file entries to check.
As unSpawn states, you should be using public keys (google it, it's easy to do).

Also search for "port knocking", there's clients for Linux (obviously), Mac and also Teh Other OS as far as I know.


Yes. Please check documentation, then ask detailed questions if necessary.


It sure is. If you want to know more search for "honeypot". There's people who publish yearly lists of common passwords used and there's people who export data from their Honeypot to their own web sites, github and other such sites for you to peruse.


Nah, just [I]add[/] pubkey auth as a method, then configure your client to first try that and fall back to password auth. Then enable ssh-agent so you only have to type your pass phrase once as you enter your account, test it and before you know you're ready for removing password auth.

Never expose to the public any server which can easily be found and which presents the dreaded word, login:.

It is much too easy for sshd to present that prompt, since, perversely, it will fall back to the least restrictive authentication-option that it is permitted to use. Furthermore, it always reveals itself to the public.

As I have described both on this forum and in this post on my blog, you should use OpenVPN, with digital certificates and tls-auth, to create a "Dwarvish Door" to your server, and put all mechanisms such as sshd exclusively behind that.

(In The Lord of the Rings, the Dwarves hid their mountain kingdoms behind concealed magical gates that could become lost if their rightful owners forgot where they are. These particular Dwarves did not choose a particularly good password, but ...)

tls-auth is a feature which requires any supplicant to present a credential (based on a digital certificate) on its initial communication with the OpenVPN host, without which said host will simply drop the packet, as though the host did not exist at all. The only way to detect the OpenVPN is to possess the necessary certificate, and to know which protocol and port-number you actually used. Unless you possess two digital certificates, (discovery and) entry is not possible.

Then, once you do pass this first gantlet, you should be obliged to use ssh to go farther. And this, too, should require you to possess a third digital certificate: "username/password" authentication is not allowed. Only those who possess what is needed to pass through both gates may enter.

(Either or both of the necessary certificates may be encrypted with a password to make them useless to someone who steals your laptop, and, since the certificates you bear are unique, they can be instantly revoked without affecting any other authorized user's access.)

The use of OpenVPN also eliminates the problem of traffic passing through the Internet unencrypted, since OpenVPN acts as a secure router (or switch), transparently encrypting everything. Clients don't have to do anything special, nor remember to do the right thing.

And, basically, the entire problem of "attempts to break through ssh" are completely eliminated. Except for the nuisance attempts by script-kiddies to discover "MysqlAdmin" on your web server , your access-logs are eerily quiet. Your authorized users pass through without impediment. No one else can even find you. There are no "failed" login attempts.

I have enabled public key authentication. I have turned off password authentication as an option. I am able to login now with my keys and it works perfectly. However, I am still noticing entries in the auth.log like this one "input_userauth_request: invalid user admin [preauth]
Sep 1 07:20:05 ubuntu sshd[31655]: error: Received disconnect from 14.185.211.124 port 61811:3: com.jcraft.jsch.JSchException: Auth fail [preauth]
"

I am guessing that since it says "preauth" that means that they are not even getting a chance to authenticate and that is working properly. Is that correct?

1 members found this post helpful.

Thank you for that information Sundial. I am not sure I would even know how to begin to set all that up. Would I have to purchase certificates or could I just generate them on the server? What is the downside to doing it that way? Is it just more work to setup but after that it is better in every way?

That is correct.

1 members found this post helpful.

You do not have to purchase certificates.

In this case, it is normal to use "self-signed" certificates, because the way that OpenSSL checks them is to see if they are signed by a ca.crt (Certificate-Authority certificate) which it has. You want to be (or, for your corporation to be ...) that "root authority." You (very tightly!) control access to the corresponding ca.key which is used to issue every certificate that your server will recognize.

Certificates are easily issued using the "EasyRSA" tool that accompanies OpenVPN ... which simply makes the process of issuing keys a heck of a lot easier to do.

Quite frankly, once you get the hang of it, it is extremely easy to set up OpenVPN, and I flatly state that it is: "better in every way." There are two crucial advantages:

1. The "Dwarvish Door" effect of tls-auth. No one comes pestering my servers trying to get into them, because they cannot find where to begin. For them, there is no place to begin.
2. OpenVPN is completely transparent to its users. "There's a subnet over there, and this is the router that is the gateway to it." It so happens that this router is cryptographically secure, but the clients thereof neither know nor care.
3. When certificates are used properly, OpenVPN can positively and uniquely identify its peers, by the one-of-a-kind certificates that they possess.

The only critical consideration is this: you must use unique digital certificates. Not "PSKs = Passwords." (Password-protect the certificates if you so desire, e.g. if you are using them with a laptop that might be stolen.)

You must also arrange for all services (such as sshd) to "listen" only on the secure subnet provided by the tunx virtual interface, not to "all ports," and you must use firewall rules to make damn sure of this. (Always and routinely "port-scan" your own system to make sure that it is as opaque and featureless as you wish for it to be.)

1 members found this post helpful.