# Questions about securing SSH and port 22

## Jimini

Greetings.

I want to secure my SSH-access. The preferred way would be, to permit access to port 22 for a number of pcs (my network, my pc at work and so on), every other pc would have to use a non-standard port. For example, every foreign pc would have to connect to port 9981, but "my" pcs could connect to port 22. How do I implement that into an iptables-script and/or my SSHD-config?

```
iptables -A INPUT -p tcp --dport 10101 -m state --state NEW -j ACCEPT

iptables -t nat -A PREROUTING -p tcp --dport 10101 -j REDIRECT --to-ports 22
```

and SSHD listening on port 22 did not permit any connections.

Another way would be, to permit acces to port 22 only to a few machines in different networks - how can get something like "192.0.0.0/24,10.0.2.15-20" into an iptables-rule?

Of course I could simply let SSHD listen only on a different port than 22 ("security by obscurity"), but this would include more circumstances for me. 

Best regards,

Jimini

----------

## Hu

 *Jimini wrote:*   

> 
> 
> ```
> iptables -A INPUT -p tcp --dport 10101 -m state --state NEW -j ACCEPT
> 
> ...

 Rules in INPUT are processed after NAT rewriting is done, so you need to use the same value for the INPUT --dport as the PREROUTING --to-ports.  Of course, if you just make that change and no other, then anyone can connect to 10101 or 22 and it will work.

 *Jimini wrote:*   

> Another way would be, to permit acces to port 22 only to a few machines in different networks - how can get something like "192.0.0.0/24,10.0.2.15-20" into an iptables-rule?

 Write two rules: one to cover the 192 network and another to cover the 10 network.

```
iptables -A INPUT -s 192.168.0.0/16 -p tcp --dport 22 -j ACCEPT

iptables -A INPUT -s 10.0.2.0/24 -p tcp --dport 22 -j ACCEPT
```

Adjust accordingly.  I changed your first rule because it is not clear whether you really meant to use a class A 192, which includes addresses that are not part of the RFC1918 reserved block.  You can use the iprange match module instead of the -s match if you need to match a group of IP addresses that cannot be represented in netmask notation.  You could also break it into more rules, such as using one for the .15 address, another to cover .16-.19, and a third to cover .20.

----------

## Jimini

Thank you for your helpful reply.

I modified my rules:

iptables -t nat -A PREROUTING -p tcp --dport 10101 -j REDIRECT --to-ports 22

iptables -A INPUT -p tcp --dport 22 -m state --state NEW -j ACCEPT

iptables -A INPUT -s 10.0.0.0/24 -p tcp --dport 22 -m state --state NEW -j ACCEPT

iptables -A INPUT -s 123.45.67.89 -p tcp --dport 22 -m state --state NEW -j ACCEPT

SSHD keeps listening on port 22. The IP in the last line is my pc at work - if i comment that line out (and try to connect from there, as if it was a "foreign" machine), it can still connect to 22 and 10101 - I just can't find my mistake.

I've abandoned the option "iprange", because "-s" fulfills my demands absolutely.

Best regards,

Jimini

----------

## Hu

 *Jimini wrote:*   

> it can still connect to 22 and 10101 - I just can't find my mistake.

 Your mistake is that you did not read my prior post closely enough.  I warned you that exactly this would happen.  :Smile: 

On top of that, your first INPUT rule grants everyone the ability to connect to ssh on the default port.  I think you might be better served by moving sshd to an unusual port.  You can either use an inverted DNAT rule to fix this for known good clients or configure the clients to always use the alternate port, via a change in ssh_config.  For the inverted DNAT approach, switch it so that an incoming connection from a known good system destined for port 22 is redirected to the unusual port.  Unknown systems will not be so redirected, and will need to explicitly request the unusual port.

----------

## NeddySeagoon

Jimini,

You could just use key based log in and put up with the noise of username/password guessing bots.

----------

## Jimini

 *Hu wrote:*   

>  *Jimini wrote:*   it can still connect to 22 and 10101 - I just can't find my mistake. Your mistake is that you did not read my prior post closely enough.  I warned you that exactly this would happen. :)

 

I did, I just didn't understand it completely :|

 *Quote:*   

> On top of that, your first INPUT rule grants everyone the ability to connect to ssh on the default port.  I think you might be better served by moving sshd to an unusual port.  You can either use an inverted DNAT rule to fix this for known good clients or configure the clients to always use the alternate port, via a change in ssh_config.  For the inverted DNAT approach, switch it so that an incoming connection from a known good system destined for port 22 is redirected to the unusual port.  Unknown systems will not be so redirected, and will need to explicitly request the unusual port.

 

iptables -t nat -A PREROUTING -s $clients -p tcp --dport 22 -j DNAT --to 10.0.0.1:10101

Works fine, thanks! After some hours of sleep this problem had lost its complexity ;)

@ NeddySeagoon:

I've thought about key-based login, too. I'm a fan of solutions, that come with minimal client-circumstances, so that I set - if possible - all options on the server and can connect from my "friendly" pcs with minimal effort. I connect from at least 4 (friendly = controlled by me) machines and thought that a simple rule in my iptables-configuration would be enough. But I guess, that I'll setup keys, too - two question: how does this method work with pcs, that do not have the correct keyfile? Is a password-based generally not permitted, so that I have to set up the access on all clients first and setup key-based login afterwards?

Thank you for your help!

Best regards,

Jimini

----------

## NeddySeagoon

Jimini,

You can allow both key based and password based logins.

If you go key based only, you must have the key files in place before your turn off password based logins.

You can use a password based login to put the key file in place, test the key based login then turn off password based login.

Of course, if you mess up there, you need physical access to fix it.

----------

## Jimini

Hm, that sounds nice, it could be worth a try! Thanks for the explanation.

Best regards,

Jimini

----------

## Hu

To be sure you understand the consequences: once you switch to only allowing key based authentication, you can only get on from those machines which have an allowed private key.  This is great for security, but may be undesirable if you have a habit of sitting down at arbitrary machines and connecting to your server.  The current configuration allows for such an action, provided you remember to handle the alternate port requirement when using an unrecognized machine.  A keys-only configuration would require you to keep the private key available, which you could do through a USB stick (but then be sure to password protect the key!).

All that said, I like running servers as keys-only whenever usage requirements permit it.

----------

## Jimini

Yep, in almost all cases I connect either from my local network or my notebook or my pc at work. If I would use a foreign pc, I would use a server at work (where I would put my keyfile) as a gateway to my own server. Thank you for your warnings :)

Best regards,

Jimini

----------

## Kasumi_Ninja

I recommend disabling PasswordAuthentication and using a key based (with password) setup. Furthermore you should install fail2ban and close inactive connections. Having a banner is also a good idea. Before disabling PasswordAuthentication make sure you can login with a your key. See also the links below.

Timeout inactive connections

```
# nano -w /etc/ssh/sshd_config

ClientAliveInterval 300

ClientAliveCountMax 0
```

Banner

```
# nano -w /etc/motd 
```

```
* * * * * * * * * * * * W A R N I N G * * * * * * * * * * * * *

THIS SYSTEM IS RESTRICTED TO AUTHORIZED USERS FOR AUTHORIZED USE

ONLY. UNAUTHORIZED ACCESS IS STRICTLY PROHIBITED AND MAY BE

PUNISHABLE UNDER THE COMPUTER FRAUD AND ABUSE ACT OF 1986 OR

OTHER APPLICABLE LAWS. IF NOT AUTHORIZED TO ACCESS THIS SYSTEM,

DISCONNECT NOW. BY CONTINUING, YOU CONSENT TO YOUR KEYSTROKES

AND DATA CONTENT BEING MONITORED. ALL PERSONS ARE HEREBY

NOTIFIED THAT THE USE OF THIS SYSTEM CONSTITUTES CONSENT TO

MONITORING AND AUDITING.

* * * * * * * * * * * * W A R N I N G * * * * * * * * * * * * *
```

```
# nano -w /etc/ssh/sshd_config

PrintMotd yes
```

Sources

Top 20 OpenSSH Server Best Security Practices

Howto Linux / UNIX setup SSH with DSA public key authentication (password less login)

Putty public key authentication on Windows

----------

## Jimini

I've got a few things to add - I have set up everything as follows:

- My router can be reached via SSH from the outside. The daemon listens on a non-standard port. I have set up a few iptables-rules, that direct ssh connections from a few "friendly" machines to port 22 to this non-standard port, so I only have to pay attention to this port when I want to connect from an "arbitrary" machine.

- Although the number of connection attempts from bots has heavily decreased, fail2ban is running.

- All my machines accept only keyfile-based logins now. My router and my fileserver also require a password, the other machines do not require a password anymore, I only need the public key. I guess keyfile + password is more secure than just the keyfile.

Is there anything that I can still do to secure the SSH-daemon(s) and my network?

Best regards,

Jimini

P.S.: here is my sshd_config:

```
Port 12345

Protocol 2

SyslogFacility AUTH

LogLevel INFO

LoginGraceTime 1m

PermitRootLogin no

StrictModes yes

MaxAuthTries 3

MaxSessions 5

PasswordAuthentication no

PermitEmptyPasswords no

ChallengeResponseAuthentication no

UsePAM yes

PrintMotd no

PrintLastLog no

Subsystem       sftp    /usr/lib/misc/sftp-server
```

----------

## deanpence

Considering the number of automated attacks out there going after port 22, I always recommend people run ssh on a non-standard port (> 1024, of course). It's only mitigation, and other methods (above) should also be used to secure ssh.

(In my case, I just got sick of seeing a few thousand automated login attempts in my logs every day.)

----------

