Securing a server with remote SSH access

[Makoto]

As I see it, every security in the world (not just servers) is only a matter of degree of deterrence. Greater the deterrence, greater the dissuasion to stop the offense.

Why do you get a bike lock? So, you deter someone from stealing it. If they had a bolt cutter, your cheap bike locks wouldn't do crap. Why get an expensive lock? So it requires a more expensive bolt cutter...

I'm sure if someone really had the means and desire, they could just barge into the data center flaring with guns and forcefully take your server. If someone really wanted to ddos you, they could nuke the datacenter. Then you'll be down for good. Deter the offenders by reducing the means to, making it more hard to and reducing the motive to. That's really all I see security as.

This is cyber security though, which is independent to physical threats. In regards to someone being able to "barge in guns flaring" and forcefully take my server though, my server operates in a datacenter that has pretty good defenses against any kind of physical threat, though I don't imagine they'd survive a nuclear blast. But in the event that a nuclear bomb is set off anywhere in the United States, I think my servers uptime should be one of the least of my concerns at that moment.

As I've stated, the only point I'm making here is that just changing your SSH port is not acceptable security in and of itself. If you still use an insecure root password and allow remote authentication via the root account, you are still significantly vulnerable to attack. Changing your SSH port and trying to block common port scans only offers you an illusion of security, and should you make any specific powerful enough enemies that decide to target you, your server will surely suffer an inevitable compromise, and really, you'd deserve it.

While in contrast, a server that does not allow password authentication and requires the use of 2048-bit keys to authenticate, the odds of someone being able to brute force your servers SSH key becomes approximately 1 in 2,387,501,381,526,942,244,559,694,309,096,218,872,017,944,350,991,552,659,971,900,165,199,893,824,055,488,839,160,977,105,687,030,458,670,487,085,618,617,078,833,889,209,892,766,113,671,673,280,348,849,630,511,458,362,569,296,174,953,897,789,727,344,999,641,759,249,104,837,115,691,247,788,463,937,093,086,068,896,921,709,677,986,502,379,632,243,927,491,833,994,293,455,673,874,163,899,294,190,446,395,028,246,041,958,044,564,198,726,327,034,664,179,988,521,319,212,066,048,849,101,286,635,068,859,231,848,982,054,391,972,560,202,405,580,687,154,564,951,567,958,907,886,088,683,074,212,353,382,995,198,022,998,602,933,851,333,457,821,012,860,874,340,472,903,107,265,870,848,947,639,303,975,781,506,320,747,099,907,472,168,278,187,331,825,244,610,792,828,026,955,223,782,428,076,221,901,852,400,711,306,059,753,263,273,274,361,040,959,662,409,651,159,425,655,958,726,103,858,682,557,032,682,176,418,273,768,964,257,399,301,110,723,632,111,061,273,457,007,295,028,788,768,040,035,375,698,842,416,321,999,444,646,989,688,911,359,569,093,424,123,169,704,757,335,997,876,390,109,765,596,559,156,538,774,447,694,871,490,582,177,491,638,021,418,632,523,833,493,217,705,950,368,035,863,555,983,152,049,959,767,800,643,780,550,383,234,733,354,513,196,547,421,614,063,134,185,344,155,970,704,959,297,625,089,248,691,362,836,983,908,673,572,922,095,030,983,343,517,604,114,288,463,927,573,753,456,486,231,136,190,218,890,186,616,394,167,800,484,547,348,811,667,968,909,134,452,587,001,918,607,568,758,813,650,290,882,655,778,552,130,175,081,497,953,984,002,400,307,481,574,894,513,081,509,911,397,040,934,813,570,040,044,381,580,028,617,922,050,082,794,114,222,639,464,415,508,230,111,130,751,629,456,097,421,507,785,264,345,939,460,683,402,078,896,139,015,223,771,892,515,936,719,535,687,612,573,791,991,386,083,679,045,669,686,629,579,350,376,126,279,882,655,705,961,680,047,121,108,806,913,217,157,730,876,583,230,118,831,305,343,046,382,857,150,477,198,327,325,083,670,059,106,422,539,079,535,887,582,970,772,814,367,855,785,639,377,310,281,854,770,197,056,299,575,718,863,641,041,764,408,786,119,046,326,919,349,576,123,079,245,837,706,022,452,034,202,110,026,141,194,660,478,694,324,543,747,496,870,260,540,152,600,156,998,000,777,355,736,974,673,067,761,726,474,061,118,886,340,322,530,684,593,350,411,313,126,100,192,004,834,356,671,543,077,766,270,327,340,714,781,956,450,512,141,814,980,947,293,578,329,240,541,444,470,773,966,769,353,809,066,448,261,875,028,531,113,492,809,275,972,022,419,402,533,297,646,539,544,798,272,008,653,367,921,337,155,290,793,038,292,269,909,198,898,063,302,781,728,252,767,959,753,726,445,656,123,413,317,729,411,061,761,510,003,411,861,715,901,339,048,962,582,453,345,178,836,948,173,826,144,547,251,551,986,385,121,113,085,588,930,290,457,894,363,937,975,493,395,249,942,768,773,984,848,450,741,852,884,742,829,218,651,687,287,852,156,010,604,779,406,456,877,133,569,333,613,709,613,272,306,706,105,494,120,118,039,543,976,717,545,728,348,473,343,340,995,462,069,919,886,747,757,022,756,146,233,213,667,041,537,900,285,395,928,792,490,248,675,173,115,830,528,138,107,634,911,470,217,366,678,704,202,858,529,738,589,714,279,056,553,185,537,752,753,770,288,109,644,856,087,129,089,281,143,888,777,191,656,774,886,738,659,863,954,208,859,213,990,617,051,748,408,421,935,788,795,668,702,950,263,818,893,614,320,077,606,688,680,140,600,535,220,895,823,995,393,818,570,434,634,738,118,205,324,479,457,691,896,821,657,887,958,033,621,067,373,262,841,919,891,187,606,650,549,976,327,930,473,557,036,326,181,670,765,523,324,883,882,821,289,671,927,815,803,731,756,748,385,313,323,322,315,972,726,038,823,532,551,180,576,366,670,587,903,934,992,555,252,393,437,791,196,515,962,895,012,961,640,602,541,378,376,207,096,228,109,110,995,420,284,027,579,341,097,993,633,542,373,265,450,947,719,152,751,638,194,034,142,765,395,501,333,436,537,061,816,880,337,334,719,884,007,656,471,081,803,734,319,978,411,930,226,804,962,357,322,841,794,328,105,870,260,252,909,479,518,460,732,172,700,320,504,156,563,074,587,772,293,578,751,258,588,655,794,461,463,015,317,498,322,465,251,619,443,404,389,443,523,492,852,088,803,741,234,344,949,524,916,313,931,278,507,533,785,539,151,934,858,590,757,283,055,076,300,308,587,708,808,326,587,990,727,603,157,595,969,328,244,093,852,169,709,536,841,880,465,182,292,053,209,180,689,594,042,448,201,447,844,941,542,878,741,807,078,502,176,767,410,640,644,400,196,147,989,082,168,514,150,366,333,371,373,515,919,969,681,490,516,296,398,489,976,921,219,918,968,063,560,865,935,604,295,850,167,785,926,796,703,833,448,673,513,071,886,068,544,934,960,353,305,278,343,249,266,351,950,447,042,142,128,437,978,110,092,720,792,162,226,848,692,553,566,810,830,740,363,260,781,351,396,122,053,288,201,349,040,503,756,599,819,508,841,830,465,194,269,031,367,499,350,612,689,511,214,535,782,687,725,869,975,971,233,059,321,284,125,654,189,842,807,472,342,354,823,110,692,065,800,999,747,519,886,846,389,864,735,939,016,141,650,231,361,543,860,656,754,168,044,691,976,587,585,448,999,103,619,439,475,767,210,353,898,945,563,349,989,046,199,674,041,722,518,094,997,414,214,958,510,917,340,656,225,175,802,760,460,329,972,345,801,012,949,473,573,165,001,300,033,053,127,349,811,504,424,771,399,383,903,671,451,436,092,963,960,619,071,670,163,090,087,855,781,834,638,305,126,365,891,580,278,416,715,098,184,359,132,062,193,342,704,858,878,278,173,506,259,918,212,890,625. (Or the simpler version, 95^2048).

Which means, pragmatically, it's impossible.

Even if you don't want to force the use of SSH keys on your server, using a secure password is an absolute must. Changing your SSH port and throwing up a simple software firewall does not in any way make this requirement moot.

That's the only thing I'm really trying to get through here. At the very minimum, you should be using a strong password on all of your publicly accessible shell accounts. There is no acceptable reason not to be. No reason whatsoever.

[Grumpy]

But, what if the private key gets stolen? Possibly due to a virus on the sys admin's computer. Possibly due to bugs like heartbleed. What if they just do a middle man attack and fake a key authentication for a self signed? We rarely hack accounts by brute forcing passwords anyway, they're usually stolen id/pass combos.

What I'm saying is that no matter how well you try to secure something, it's still going to be possible to be compromised, one way or another. There is no absolute security, just relative security which increases the deterrence against the attacker.

Changing SSH port is not an illusion of security, it's just more security. By itself, is likely insufficient, but still more security in a world where absolute security is not attainable. I've had servers that would get like 20 perm bans a day by csf/lfd from failed logins when ssh port was 22. After changing to some obscure number, it became zero for like a year (also had port scan blocker). That's a pretty good decrease of probability, right? Even if they did already have the correct id/pass combo or stolen key, they wouldn't have made it in because they'll need to port scan first. ... at least not from a single IP.

P.S. Wikileaks server is nuke proof. Their datacenter is a ex-cold war bunker. (or at least was at one point in time)

[Makoto]

But, what if the private key gets stolen? Possibly due to a virus on the sys admin's computer.

That's why it's generally recommended you keep your private keys encrypted. So even if they are stolen, they will be useless to the attacker unless they can crack them. Which how fast your keys can be cracked all depends on how secure the passkey you used to encrypt it is.

But naturally, if you discover reason to believe your key has been compromised, you should regenerate a new one as soon as possible.

You might think that brute force attacks are ancient history, but it's still an extremely common type of automated attack for a reason. They are generally limited dictionary attacks, using dictionaries based on the previous years top 100/1000/10000/.... used passwords, taken from various sources. Some of them use dictionaries from large scale database compromises, which contain all the passwords used by thousands/hundreds of thousands/millions of users.

So if your password isn't unique, or is something stupidly common, you're just begging to eventually have your server compromised and turned into a botnet or worse. This is why I keep going on about how simply changing your SSH port can give you a false sense of security, because I do know countless people with ridiculously insecure passwords who naively believe because they have CSF set up to try and detect and ban port scans along with brute force attacks, that they're invincible to these attackers and so they don't need to bother keeping up with any of these security standards. Because it's "too much trouble" or they can't be bothered to remember a password that can't be taken right out of the English dictionary.

Using SSH keys can actually make life easier on you in this sense, they offer significantly better security and offer a convenience.

What I'm saying is that no matter how well you try to secure something, it's still going to be possible to be compromised, one way or another. There is no absolute security, just relative security which increases the deterrence against the attacker.

I do see what you're saying, but I still do consider real world security and security through obscurity two different things.

Take changing your ACP's directories name, for example. This itself is security through obscurity, but that doesn't make it a bad or pointless practice, I actually encourage people to do this. It doesn't actually improve the actual security of your ACP, but it prevents easy access to it. Firewalling your ACP to only allow access to your specific IP or IP range, on the other hand, is an example of "security security", or whatever you'd like to call it. I'm sure there are more proper terms for this.

Both are good practices, but there are key differences between the two.

In general though, you are absolutely right. There is no absolute security in the world, and this is an important reality to be aware of. Eventually, the encryption algorithms we use today will be broken. It's not a matter of if, it's a matter of when. Security is basically an endless game of cat and mouse. Many security practices used decades ago are now considered completely obsolete today, and the same will likely be true of the security practices we use today decades in the future. WEP, BEAST and RC4 are good examples of this.

tl;dr I do agree with you, I think there's just a bit of miscommunication here. I do think changing your SSH port and even using software firewalls like csf and fail2ban are all good security practices to consider, and changing your SSH port does increase your servers security, it just bewilders me how some people say the steps that I recommend are unnecessary in comparison to this, because some people believe simply changing your SSH port and using IDS' to ban common port scan attempts makes it impossible for anyone to even attempt attacks on their SSH server, which is ridiculously naive and untrue.

For the same reasons you've said, there is no such thing as absolute security, and it's naive to think otherwise. Many of the steps I recommend are a bit more "extreme," but they do offer a much higher level of security, and regardless of what you do, using secure passwords on all of your accounts is an essential security practice.

P.S. Wikileaks server is nuke proof. Their datacenter is a ex-cold war bunker. (or at least was at one point in time)

Hah, yeah, I think I've read about that before.

(Sorry for the extremely wordy responses also. If it's not obvious, these are subjects I love discussing in general. I'm not meaning to come off rambly. :tongue:)