dslreports logo
site
 
    All Forums Hot Topics Gallery
spc

spacer




how-to block ads


Search Topic:
uniqs
1093
share rss forum feed


Tx
bronx cheers from cheap seats
Premium
join:2008-11-19
Mississauga, ON
kudos:12
Reviews:
·TekSavvy DSL
·FreePhoneLine
·Rogers Hi-Speed

ssh keys

For the linux guys, here is a question.

i will soon be removing password authentication via ssh in favor of ssh keys, something i should have done many moons ago. I've already setup Putty and my authorized keys on the servers. Login's all tested and functional

My question is, have you ever experienced any issues using ssh keys? Once i disable password auth in ssh config and anything happens my server is now rouge. I believe as long as i keep my private key safe i should be good. I should also still be able to SU in with passauth disabled correct?

My servers get hammered with attempts daily from china, russia, Taiwan and republic of anywhere. Time to tighten the holes a bit more and figured so many smart techies around here i'll ask.


X10A

join:2004-07-13
Brossard, QC

said by Tx:

My servers get hammered with attempts daily from china, russia, Taiwan and republic of anywhere.

if you change ssh port to something out of the blue you should not get hammer.... Also consider fail2ban

like you said earlier def keep a backup key somewhere safe..... like a usb key.


Tx
bronx cheers from cheap seats
Premium
join:2008-11-19
Mississauga, ON
kudos:12
Reviews:
·TekSavvy DSL
·FreePhoneLine
·Rogers Hi-Speed

said by X10A:

said by Tx:

My servers get hammered with attempts daily from china, russia, Taiwan and republic of anywhere.

if you change ssh port to something out of the blue you should not get hammer.... Also consider fail2ban

like you said earlier def keep a backup key somewhere safe..... like a usb key.

I don't think i've used default ssh port in over 6 years. So far China figures it out more often then anyone else. CSF tends to block everyone just fine and does it's job very well but i prefer added security and since i've been under a rock all this time, it's my first time using keys to be honest.

I have that fear of something happening to a key or some reason the server refusing a key for example. Man i'll blow a gasket. Purpose to this thread is probably that. Has there ever been any ssh bugs in terms of RSA keys being refused for no reason


Spike
Premium
join:2008-05-16
Toronto, ON
reply to Tx

In the years of using keys, I have never ever saw a server refuse to authenticate, unless it was for a very good reason, either someone removed you from .authorized_keys or something unrelated to the ssh key itself...



urbanriot
Premium
join:2004-10-18
Canada
kudos:3
Reviews:
·Cogeco Cable
reply to X10A

said by X10A:

if you change ssh port to something out of the blue you should not get hammer....

They're hammering other ports now too, for the past year or so. Best thing to do is configure your firewall to blackhole IP's originating multiple failed attempts or multiple requests in a minute.


EUS
Kill cancer
Premium
join:2002-09-10
canada
Reviews:
·voip.ms
reply to Tx

I've never had any problems with ssh authenticating unless I did not set it up right.
I'll second or third fail2ban, simple and effective.

said by Tx:

Once i disable password auth in ssh config and anything happens my server is now rouge.

I'm not sure what this means.
--
~ Project Hope ~


urbanriot
Premium
join:2004-10-18
Canada
kudos:3
Reviews:
·Cogeco Cable

1 recommendation

said by EUS:

said by Tx:

Once i disable password auth in ssh config and anything happens my server is now rouge.

I'm not sure what this means.

In English, his server is now red.

MaynardKrebs
Heave Steve, for the good of the country
Premium
join:2009-06-17
kudos:4
reply to Tx

said by Tx:

said by X10A:

said by Tx:

My servers get hammered with attempts daily from china, russia, Taiwan and republic of anywhere.

if you change ssh port to something out of the blue you should not get hammer.... Also consider fail2ban

like you said earlier def keep a backup key somewhere safe..... like a usb key.

I don't think i've used default ssh port in over 6 years. So far China figures it out more often then anyone else. CSF tends to block everyone just fine and does it's job very well but i prefer added security and since i've been under a rock all this time, it's my first time using keys to be honest.

I have that fear of something happening to a key or some reason the server refusing a key for example. Man i'll blow a gasket. Purpose to this thread is probably that. Has there ever been any ssh bugs in terms of RSA keys being refused for no reason

In WHM get into CSF
1. Click the "Firewall Configuration" button
2. Scroll down the page about 1/3 (or use the FIND in your browser) to the section with "CC_DENY"
These are comma separated list of 2 letter Country Codes. Here's a link to the codes - »www.worldatlas.com/aatlas/ctycodes.htm

So for every country you want to deny, you just enter those letters in the field (separated by a comma). This is great for getting rid of China altogether and not worrying about looking up the CIDR range for each Chinese IP. IP address blocks are so chopped up that trying to block Chinese CIDR ranges is a pain - you can generally block only 1MM IP's at a time if you're lucky.

Just know that if you use CC_DENY you will chew through more CPU because the firewall is always looking up lots of stuff. This might bump your VPS into a different price category with your hosting provider.

The alternate way is to use the "CC_ALLOW_FILTER" and enter only the countries you want to ALLOW access to. Don't use the CC_ALLOW option as this allows users to bypass the filtering done on the firewall when checking for spammers and hackers. If you use the CC_ALLOW_FILTER, the filtering will still work.

Once you're done, scroll to the bottom of the page and click CHANGE. This will restart the firewall, and you're now all set to go.


Tx
bronx cheers from cheap seats
Premium
join:2008-11-19
Mississauga, ON
kudos:12
Reviews:
·TekSavvy DSL
·FreePhoneLine
·Rogers Hi-Speed

said by Spike:

In the years of using keys, I have never ever saw a server refuse to authenticate, unless it was for a very good reason, either someone removed you from .authorized_keys or something unrelated to the ssh key itself...

Good to hear. It's long overdue.

said by urbanriot:

said by X10A:

if you change ssh port to something out of the blue you should not get hammer....

They're hammering other ports now too, for the past year or so. Best thing to do is configure your firewall to blackhole IP's originating multiple failed attempts or multiple requests in a minute.

It's unreal. Few of us have sat back and chuckled a little at how bored people must be. I'm sure a lot of it is probably scanners sweeping IP pools but we get an equal number of people trying to figure out email passwords, account passwords. It's entertaining i guess until we get someone who knows what they are doing.

said by EUS:

I've never had any problems with ssh authenticating unless I did not set it up right.
I'll second or third fail2ban, simple and effective.

said by Tx:

Once i disable password auth in ssh config and anything happens my server is now rouge.

I'm not sure what this means.

Exactly like urbanriot said. Once i set "PasswordAuthentication to off and disable PAM" all of my servers will now be key accessible only. Should we loose a private key as we are using different keys per server, short of hiring an able hacker our server would be rouge. No super user, no users.

said by MaynardKrebs:

In WHM get into CSF
1. Click the "Firewall Configuration" button
2. Scroll down the page about 1/3 (or use the FIND in your browser) to the section with "CC_DENY"
These are comma separated list of 2 letter Country Codes. Here's a link to the codes - »www.worldatlas.com/aatlas/ctycodes.htm

So for every country you want to deny, you just enter those letters in the field (separated by a comma). This is great for getting rid of China altogether and not worrying about looking up the CIDR range for each Chinese IP. IP address blocks are so chopped up that trying to block Chinese CIDR ranges is a pain - you can generally block only 1MM IP's at a time if you're lucky.

Just know that if you use CC_DENY you will chew through more CPU because the firewall is always looking up lots of stuff. This might bump your VPS into a different price category with your hosting provider.

The alternate way is to use the "CC_ALLOW_FILTER" and enter only the countries you want to ALLOW access to. Don't use the CC_ALLOW option as this allows users to bypass the filtering done on the firewall when checking for spammers and hackers. If you use the CC_ALLOW_FILTER, the filtering will still work.

Once you're done, scroll to the bottom of the page and click CHANGE. This will restart the firewall, and you're now all set to go.

A lot of our servers don't have cPanel. We usually play with CSF via command line. I thought of blocking out some countries but we do have some genuine customers from some of these countries.

We rent/lease our racks, so i hope these costs don't go up :P May need to pay for a few more amps lol. In all seriousness, i wouldn't run a business off VPS, i think it's silly. Great for personal medium sized blogs or forums. I don't mind allowing them access, csf does it's job very well. We flush the blacklist every 90 days. Just tightening up security a bit more. Though i think i'll try out what you suggested on our dev servers. Appreciate the suggestions.

On that note, do you use cPanel? If so, have you tried Interworx. Quite the competitor.


Steve
I know your IP address
Consultant
join:2001-03-10
Foothill Ranch, CA
kudos:5

said by Tx:

short of hiring an able hacker our server would be rouge.

Rouge - pronounced roozh; a reddish color
Rogue - pronounced rohg; owned by the bad guys


Tx
bronx cheers from cheap seats
Premium
join:2008-11-19
Mississauga, ON
kudos:12
Reviews:
·TekSavvy DSL
·FreePhoneLine
·Rogers Hi-Speed

1 edit

said by Steve:

said by Tx:

short of hiring an able hacker our server would be rouge.

Rouge - pronounced roozh; a reddish color
Rogue - pronounced rohg; owned by the bad guys

it's tough typing off a phone. Spelling was intended to be Rogue - "Operating outside normal or desirable controls"


DeHackEd
Bill Ate Tux's Rocket

join:2000-12-07
reply to Tx

Here's what I do. Obviously you may not agree with my decisions but whatever.

sshd_config
Disable PasswordAuthentication.
Enable ChallengeResponseAuthentication
Enable UsePAM

Now install a second authentication factor to SSH. I went with the Google Authenticator. The same thing you can use for 2-factor authentication to google accounts is also available as a PAM module, though without SMS. Just be careful - google authentication automatically fails if the user being set up doesn't have google auth codes enabled.

Do leave public key authentication on. If you need to get in without ssh keys, you can use your password + cellphone or scratch code authentication.

I also have these IPtables rules


iptables -N ssh
iptables -A ssh -m hashlimit --hashlimit-upto 5/hour --hashlimit-name sshhash --hashlimit- srcmask 24 -j ACCEPT
iptables -A ssh -p tcp -j REJECT --reject-with tcp-reset
# or DROP if you want

# Put this rule high enough that new SSH connections will be matched
iptables -A INPUT -p tcp --syn --dport 22 -j ssh


(in the previews the output got broken by the forum so watch for stray white space inserted)

So now I can get in by SSH key from a PC I own, or by password+30second code from any system I don't.

I'm not convinced on the 5/hour metric though. Probably a sign of how much I use ssh myself.

--
That's odd...


nwrickert
sand groper
Premium,MVM
join:2004-09-04
Geneva, IL
kudos:7
Reviews:
·AT&T U-Verse
reply to Tx

said by Tx:

My question is, have you ever experienced any issues using ssh keys?

I have never had a problem. I disabled password authentication years ago.

Occasionally, I forget to add a key to ssh-agent, and then a login fails. But it's easy to recognize what went wrong.

Oops! My mistake. I did have a problem. The problem was called "Fedora 18". The stupidity is hard to believe. By default, the SELinux configuration did not allow the sshd daemon access to the user "$HOME/.ssh/authorized_keys" file.
--
AT&T Uverse; Buffalo WHR-300HP router (behind the 2wire gateway); openSuSE 12.3; firefox 20.0


Tx
bronx cheers from cheap seats
Premium
join:2008-11-19
Mississauga, ON
kudos:12
Reviews:
·TekSavvy DSL
·FreePhoneLine
·Rogers Hi-Speed

said by DeHackEd:

Here's what I do. Obviously you may not agree with my decisions but whatever.

sshd_config
Disable PasswordAuthentication.
Enable ChallengeResponseAuthentication
Enable UsePAM

Now install a second authentication factor to SSH. I went with the Google Authenticator. The same thing you can use for 2-factor authentication to google accounts is also available as a PAM module, though without SMS. Just be careful - google authentication automatically fails if the user being set up doesn't have google auth codes enabled.

Do leave public key authentication on. If you need to get in without ssh keys, you can use your password + cellphone or scratch code authentication.

I also have these IPtables rules


iptables -N ssh
iptables -A ssh -m hashlimit --hashlimit-upto 5/hour --hashlimit-name sshhash --hashlimit- srcmask 24 -j ACCEPT
iptables -A ssh -p tcp -j REJECT --reject-with tcp-reset
# or DROP if you want

# Put this rule high enough that new SSH connections will be matched
iptables -A INPUT -p tcp --syn --dport 22 -j ssh


(in the previews the output got broken by the forum so watch for stray white space inserted)

So now I can get in by SSH key from a PC I own, or by password+30second code from any system I don't.

I'm not convinced on the 5/hour metric though. Probably a sign of how much I use ssh myself.

Thanks for the info, i'll give that a try on one of the test servers. Never heard of it to be completely honest. Worth playing around with anything.

said by nwrickert:

said by Tx:

My question is, have you ever experienced any issues using ssh keys?

I have never had a problem. I disabled password authentication years ago.

Occasionally, I forget to add a key to ssh-agent, and then a login fails. But it's easy to recognize what went wrong.

Oops! My mistake. I did have a problem. The problem was called "Fedora 18". The stupidity is hard to believe. By default, the SELinux configuration did not allow the sshd daemon access to the user "$HOME/.ssh/authorized_keys" file.

Guess the fact everyone is saying this says something. At least it's reliable other then Fedora :P


koitsu
Premium,MVM
join:2002-07-16
Mountain View, CA
kudos:23

3 edits

1 recommendation

reply to X10A

said by X10A:

said by Tx:

My servers get hammered with attempts daily from china, russia, Taiwan and republic of anywhere.

if you change ssh port to something out of the blue you should not get hammer.... Also consider fail2ban

This is false. Changing the SSH port does not solve the problem. Telling people it does is a lie.

More and more people with botnets are doing portscanning looking for non-port-22 SSH daemons these days (telnet to port 22 sometime, note the banner).

The only solutions are to implement a inbound-deny-all-allow-some firewall model, or start blocking CIDRs which are offensive. I tend to use the latter method and maintain a list manually/by hand.

Back to the topic at hand:

I still leave password authentication enabled in sshd, even though m primary authentication method is though a key. I cannot tell you how many times during major remote systems maintenances where I was doing things like backing up/restoring /home where I needed to SSH in but didn't have /home/myusername/.ssh/authorized_keys available or easily accessible and time was of the essence, or, where I was working via a remote KVM (i.e. no copy-paste capability) and I wasn't going to type in a 400 byte authorized_keys file by hand (if you ever have to do this, you will understand why keeping password auth enabled is a godsend).

It's for this reason I strongly recommend people be EXTREMELY careful about disabling password authentication. For system maintenances, you may just want to re-enable password authentication temporarily as a "just in case" precaution, then disable it once again when you're done. It's your system, it's your choice, not mine.

For people wondering about people SSH'ing in and brute-forcing passwords: look into MaxAuthTries, MaxSessions, and MaxStartups (read the sshd_config man page, do not skim it). Do not use TCP wrappers, as these will make the situation worse. I also tend to recommend using UseDNS no (I don't care about DNS resolution in sshd, IP addresses are all I care about). Otherwise use iptables via whatever model/method you feel works for you (YMMV).
--
Making life hard for others since 1977.
I speak for myself and not my employer/affiliates of my employer.