# Securing SSH?

## Gentist

I'm planning on setting up SSH. Paranoid as I am, I don't fully trust it to be safe all of the time, so I have a few questions regarding it. Without having to read through loads of pages, how secure is SSH by default, and how can I make it more secure?

What I'm mainly worried about is the handshaking. Let's say I do the handshaking over an unencrypted WiFi connection. How probable, and possible, is a man-in-the-middle attack? The safest thing would obviously be having the keys already (on an USB flash drive, for example), so that nothing prior to the actual encrypted stuff is sent. Is it possible to do this, and if so, can I use it together with a password too (in case someone decides to steal the key)?

My second question concerns the encryption used. I prefer to use non-standard variables wherever possible, so is it possible to change the encryption used, and if so, what are the possibilities?

----------

## NeddySeagoon

Gentist,

Change its setup to not permit root logings.

If you can, don't permit any password logins - use keys.

A man in the middle attack is not possible, since even the authentication is public key encrypted.

The man in the middle would need both private keys

----------

## nephros

..and you can protect the keys with a passphrase of arbitrary length.

Consult the ssh-keygen man page.

I use Bible and Harry Potter quotes on some keys because you can jot down something like Luc2:11 or "Snape kills Dumbledore" in a text file and store that in a gringotts vault.  :Wink: 

----------

## Gentist

 *NeddySeagoon wrote:*   

> Change its setup to not permit root logings.

 

Well, naturally. Logging in as root is stupid even when it's local. I normally disable root login completely (leaving me with one account which can su to root). I'm going to have to go through the SSH config files when I do set it up...

 *NeddySeagoon wrote:*   

> If you can, don't permit any password logins - use keys.

 

Would it be possible to require both? Naturally I'd encrypt the key itself, but I'd still want to use a password for SSH.

 *NeddySeagoon wrote:*   

> A man in the middle attack is not possible, since even the authentication is public key encrypted.
> 
> The man in the middle would need both private keys

 

Theoretically, yes. I'd still feel safer if it was all encrypted on both sides before the connection is even established. Although it may not be necessary.

 *nephros wrote:*   

> ..and you can protect the keys with a passphrase of arbitrary length.
> 
> Consult the ssh-keygen man page.

 

Would this be more secure than regular encryption, or would I gain anything in using both? The advantages of encrypting the file is that you add some obscurity, plus that you'd need a system that supports the encryption implementation.

 *nephros wrote:*   

> I use Bible and Harry Potter quotes on some keys because you can jot down something like Luc2:11 or "Snape kills Dumbledore" in a text file and store that in a gringotts vault. 

 

I usually memorize some semi-random, non-personal string of at least 15 characters. Although I must admit that it's a bit hard trying to keep track of them all after a while.  :Razz: 

----------

## nephros

 *Gentist wrote:*   

>  *nephros wrote:*   ..and you can protect the keys with a passphrase of arbitrary length.
> 
> Consult the ssh-keygen man page. 
> 
> Would this be more secure than regular encryption, or would I gain anything in using both? The advantages of encrypting the file is that you add some obscurity, plus that you'd need a system that supports the encryption implementation.

 

Oh it doesn't alter the encryption of ssh connections at all. It's just that you have to enter the password for the key every time an application accesses it.

It addds additional protection should the key get stolen.

----------

## thewally

If you connect to your ssh server from the same machines, with iptables you can do something like this:

 *Quote:*   

> iptables -P INPUT DROP
> 
> iptables -A INPUT -m mac --mac-source here:the:mac:of:a:secure:machine -J ACCEPT
> 
> iptables -A INPUT -m mac --mac-source here:the:mac:of:another:secure:machine -j ACCEPT

 

----------

## sschlueter

 *Gentist wrote:*   

> 
> 
> What I'm mainly worried about is the handshaking. Let's say I do the handshaking over an unencrypted WiFi connection. How probable, and possible, is a man-in-the-middle attack? The safest thing would obviously be having the keys already (on an USB flash drive, for example), so that nothing prior to the actual encrypted stuff is sent. Is it possible to do this, and if so, can I use it together with a password too (in case someone decides to steal the key)?
> 
> 

 

The connection is encrypted before authentication takes place.

SSH2 has no known weaknesses concerning man-in-the-middle-attacks before/during the authentication phase as long as strict host key checking is enabled.

Pleae note that SSH1 is vulnerable to man-in-the-middle-attacks and should not be used any more!

----------

## Gentist

 *nephros wrote:*   

> Oh it doesn't alter the encryption of ssh connections at all. It's just that you have to enter the password for the key every time an application accesses it.
> 
> It addds additional protection should the key get stolen.

 

I'm aware of that. What I'm wondering is if it's safer to, say, use dm-crypt on a looped filesystem with the key in it, as well as the SSH solution. One benefit is that dm-crypt doesn't work everywhere, another is that it won't be obvious that the key is in that file. The question is if the SSH solution would add anything to the setup.

 *thewally wrote:*   

> If you connect to your ssh server from the same machines, with iptables you can do something like this:
> 
> iptables -P INPUT DROP
> 
> iptables -A INPUT -m mac --mac-source here:the:mac:of:a:secure:machine -J ACCEPT
> ...

 

MAC addresses can be spoofed, but yeah. It's a good idea to use as an addition to everything else.

 *sschlueter wrote:*   

> The connection is encrypted before authentication takes place.
> 
> SSH2 has no known weaknesses concerning man-in-the-middle-attacks before/during the authentication phase as long as strict host key checking is enabled.
> 
> Pleae note that SSH1 is vulnerable to man-in-the-middle-attacks and should not be used any more!

 

While that is true, I'd like to skip the whole handshaking thing, and assume that it's already established. I mean, correct me if I'm wrong, but wouldn't that prevent anyone without the appropriate key to even talk to the server? Is there a reason as to why this isn't possible, or why it shouldn't be used?

Also, if I were to switch to key-based auth. Since that won't require the password, am I right in assuming that the key is a hash of your actual login password? Isn't that more dangerous if someone is sniffing packets?

Basically, what I'd like to do is to already have a key for the encryption part, and then have a password for the login part.

----------

## think4urs11

 *Gentist wrote:*   

>  *thewally wrote:*   If you connect to your ssh server from the same machines, with iptables you can do something like this:
> 
> iptables -P INPUT DROP
> 
> iptables -A INPUT -m mac --mac-source here:the:mac:of:a:secure:machine -J ACCEPT
> ...

 

Useless for machines outside the same ip subnet than the ssh server itself resides in.

----------

## VStrider

Gentist, SSH2 cannot be MITM attacked if you configure it correctly. Read this:

 *sschlueter wrote:*   

> The connection is encrypted before authentication takes place.
> 
> SSH2 has no known weaknesses concerning man-in-the-middle-attacks before/during the authentication phase as long as strict host key checking is enabled.
> 
> Please note that SSH1 is vulnerable to man-in-the-middle-attacks and should not be used any more!

 

The only way someone could attack your SSH2 is through social engineering, which probably wouldn't work on you. If you see a different banner or if encryption is not working then you know this isn't your server and you wouldn't type your password there.

If you're really paranoid about it, you could also write a small script that checks your /proc/net/arp entries and report changes. Or you could emerge arpwatch. If your wireless router is not a linux box but a commodity router then obviously you cann't do this and you could be vulnerable to a MITM attack, though not on your SSH. If your router is a windows box, then replace it with a linux box as soon as possible. Windows have many flaws and are alot more vulnerable to arp poisoning(even a fully patched box) than a linux box.

----------

## Gentist

 *VStrider wrote:*   

> The only way someone could attack your SSH2 is through social engineering, which probably wouldn't work on you. If you see a different banner or if encryption is not working then you know this isn't your server and you wouldn't type your password there.
> 
> If you're really paranoid about it, you could also write a small script that checks your /proc/net/arp entries and report changes. Or you could emerge arpwatch. If your wireless router is not a linux box but a commodity router then obviously you cann't do this and you could be vulnerable to a MITM attack, though not on your SSH. If your router is a windows box, then replace it with a linux box as soon as possible. Windows have many flaws and are alot more vulnerable to arp poisoning(even a fully patched box) than a linux box.

 

I don't own a wireless router, for security reasons (that, and the fact that my current network works just fine). My mentioning of WiFi was in the case of public hotspots. I wouldn't have any control over the routers involved. I guess /proc/net/arp is useful though.

----------

## nobspangle

 *Gentist wrote:*   

> Also, if I were to switch to key-based auth. Since that won't require the password, am I right in assuming that the key is a hash of your actual login password? Isn't that more dangerous if someone is sniffing packets?
> 
> Basically, what I'd like to do is to already have a key for the encryption part, and then have a password for the login part.

 

The key is not a hash of your password, you generate the public and private keys, they have nothing to do with your password. When you generate the keys you also have the option of protecting your private key with a password.

Then you carry the private key around with you (the public key lives on the server). When you connect to the server, your ssh client loads the private key and prompts you for the password, if you supply the correct password the private key can be used to authenticate you with the server.

After you are authenticated, handshaking takes place for the encryption. This is much more secure than a pre shared key like you are suggesting. With your system, somebody could capture the enrypted traffic and then if they ever got hold of the key they would be able to decrypt all the previous sessions.

----------

## groovin

i second the that ssh2 is pretty secure as long as you have strong passwords (not have users named 'test' with password 'test') and that you keep track of any security advisories on ssh.

----------

## Joseph_sys

To further enhance security, over and above to what other folks have suggested (using keys etc), install on your firewall "knock" if you can.  It depend on what firewall you are using.  For example freesco firewall has a knock module.

What it does is opens and closes the 22 port for your ssh (any port can be open/close this way).  In normal condition 22 is in closed in "stealth mode",  you issue a command (example):

```
knock 25484 45877 5698 4587 
```

(Can be as many ports as you want) this will open your port 22 to allow ssh connection to go through.  The interesting part is that the port will be open ONLY to the IP address it received successful "knock" from; to all others port 22 will be "closed"

If you are finish just issue another knock (example)

```
knock 2568 2568 25445 
```

(the port 22 will close)

----------

## abaelinor

aaLast edited by abaelinor on Tue Oct 21, 2008 1:41 pm; edited 1 time in total

----------

## tgh

Then there's the additional option of putting SSH on a non-standard port if you don't want to use port-knocking.  For a home office where I have SSH forwarded through the firewall, the firewall forwards a non-standard port # to that same non-standard port # on the SSH box inside.  In addition, the SSH box can be set to also listen on the standard port.

I would imagine that you could setup iptables in a similar fashion.  Allow access to the standard port 22 from machines that you trust (the local network) and use a non-standard port for networks that you don't trust.  Easy for your local network users, but still allowing you a way to get into the box if you're coming from a non-standard address.

SSH (and telnet) are very high-value targets for attackers.  If they know you exist, they will beat on your door until they break it down.  So my preference is to hide by either using non-standard ports or port-knocking.

----------

## JohnDoe

 *Think4UrS11 wrote:*   

>  *Gentist wrote:*    *thewally wrote:*   If you connect to your ssh server from the same machines, with iptables you can do something like this:
> 
> iptables -P INPUT DROP
> 
> iptables -A INPUT -m mac --mac-source here:the:mac:of:a:secure:machine -J ACCEPT
> ...

 

But can be used the same way for IP addresses.

iptables -A INPUT -s 192.168.1.0/255.255.255.0 -p tcp -m tcp --dport 22 -j ACCEPT

for a subnet or you can add individual IP addresses if you would like.

 *Joseph_sys wrote:*   

> To further enhance security, over and above to what other folks have suggested (using keys etc), install on your firewall "knock" if you can.

 

There is a program specifically for that. Try

# emerge knock

The program is small and enables you to introduce some more security.

Check for more info on

http://gentoo-wiki.com/HOWTO_Port_Knocking

----------

## xante

Looking through that knock program, it looks very easy to use, but I have a few questions, On any remote machine you would have to download the client to do the knocking? and when closing a connection must you knock before you close a connection or say you "knocked" in for an ssh session, and instead  of running knock again from the remote machine, could you do it on the server while your logged in?

----------

## groovin

 *xante wrote:*   

> Looking through that knock program, it looks very easy to use, but I have a few questions, On any remote machine you would have to download the client to do the knocking? and when closing a connection must you knock before you close a connection or say you "knocked" in for an ssh session, and instead  of running knock again from the remote machine, could you do it on the server while your logged in?

 

on a windows machine i think you can just launch telnet a few times to hit the right port sequence.

----------

## JohnDoe

 *xante wrote:*   

> and when closing a connection must you knock before you close a connection or say you "knocked" in for an ssh session, and instead  of running knock again from the remote machine, could you do it on the server while your logged in?

 

One of the options (and the one I use most frequently) is one that uses a start command waits a few seconds and then uses a stop command (so, for opening a port it would be something like iptables -A (...) wait a few seconds iptables -D (...)). This way you'll never forget to close the door to your protected port.

All of this is explained in the link I gave in my post above.

----------

## Gentist

I never run services that aren't for public use on standard ports, even if it's local. However, what are the drawbacks of a portknocker? If it has the power to disable the firewall from within, what's keeping it from being exploited? The question is, what's better; a locked down firewall which can't be touched (even by root), or a dynamic firewall, which has the potential to be manipulated? Wouldn't a portknocker require me to open up the ports I have to knock?

Wouldn't it be better to have a "portknocker" (or similar implementation) that manipulates SSH instead of the firewall? That is, shut down/start SSH when it receives a signal.

What is the probability that someone would manage to brute force (or otherwise crack) a key instead of say, a 25 characters long password? And how is it that SSH can override the login system?

Other than that, what encryption/hash combination is recommended? I don't care too much about overhead, since I'm the only one who'll use SSH on that computer.

----------

## sschlueter

 *Gentist wrote:*   

> I never run services that aren't for public use on standard ports, even if it's local. However, what are the drawbacks of a portknocker? If it has the power to disable the firewall from within, what's keeping it from being exploited? The question is, what's better; a locked down firewall which can't be touched (even by root), or a dynamic firewall, which has the potential to be manipulated? Wouldn't a portknocker require me to open up the ports I have to knock?
> 
> 

 

I'm not quite sure if you understand the portknocking concept. There are different implementations but usually a demon runs on the target machine that watches netfilter log messages about dropped packets and checks if it has dropped

* a series of packets targeting certain destination ports

* in a specific order

* that came from the same IP address

* within a limited time frame.

If all these conditions match, it temporarily changes the netfilter rules. Usually, only a single rule is added that allows access to port 22 for the IP address that issued the correct knocking sequence.

So, there is no drawback. The worst thing that can happen is that an attacker can talk to the SSH demon - but without portknocking he could have done that anyway.

So portknocking is actually a little bit more than just "security through obscurity". It is of course obscurity as the system tries to hide the mere existance of the ssh demon. But even if the attacker knew that there is an ssh server running and that he has to issue the correct port knocking sequence in order to talk to the ssh server - it can be pretty hard to brute force the correct sequence. For each port there are 2^16 possibilities. There are only 2^8 possibilities for a character in a password. So a port knocking sequence that consists of a series of 15 ports is way harder to brute force than a password that consists of 15 characters.

And I also want to point out something that nobody has said in this thread yet: We have talked about the SSH2 protocol but not about the implementation. The SSH server is a demon that listens on a tcp port and runs with root privileges. The simple fact that an attacker can talk to the ssh server is a risk as he might be able to exploit some vulnerabilitiy in the demon itself. Of course this risk has been greatly reduced since privilege separation has been added to OpenSSH. An unauthenticated attacker can only talk to an unprivileged child process. Anyhow, with portknocking, the attacker can't even talk to the demon and therefore this risk is completely eliminated.  

Well, at least if the portknocking demon works by adding and removing netfilter rules. A possible variant of this portknocking setup could be to add and remove lines to/from /etc/hosts.allow. But I personally think that adding and removing netfilter rules is more secure when it comes to securing the ssh demon itself.

Personally, I don't use portknocking. If I wanted to secure the SSH demon itself (and I currently don't feel the need), I would make it accessible through an OpenVPN tunnel only.

 *Gentist wrote:*   

> 
> 
> Wouldn't it be better to have a "portknocker" (or similar implementation) that manipulates SSH instead of the firewall? That is, shut down/start SSH when it receives a signal.
> 
> 

 

This could be another variant. But it seems inconvenient to me. Many people want to have easy access to the ssh server from their private LAN without having to issue a portknocking sequence. I think most people would like to have their ssh server running all the time. And remember that the netfilter solution has the advantage that access to the ssh server is granted for a single (additional) IP adress. So yur suggestion would be lesss secure unless you add manipulating entries in /etc/hosts.allow or netfilter to ther setup besides starting and stopping the ssh demon.

 *Gentist wrote:*   

> 
> 
> What is the probability that someone would manage to brute force (or otherwise crack) a key instead of say, a 25 characters long password?
> 
> 

 

Mh, I'm not quite sure, but aren't  there 2^1024 different 1024 bit rsa keys?

 *Gentist wrote:*   

> 
> 
> And how is it that SSH can override the login system?
> 
> 

 

Question is unclear to me.

 *Gentist wrote:*   

> 
> 
> Other than that, what encryption/hash combination is recommended? I don't care too much about overhead, since I'm the only one who'll use SSH on that computer.

 

Well, as far as I know, there is no alternative to the diffie-hellman key agreement. You can however choose between md5 and sha1 integrity check hashes. And you can choose several symmetric ciphers to encrypt the session, namely 3des, aes, blowfish and cast. All of them are fine. There is no need to worry. At least not at the moment.

----------

## Gentist

 *sschlueter wrote:*   

> And I also want to point out something that nobody has said in this thread yet: We have talked about the SSH2 protocol but not about the implementation. The SSH server is a demon that listens on a tcp port and runs with root privileges. The simple fact that an attacker can talk to the ssh server is a risk as he might be able to exploit some vulnerabilitiy in the demon itself. Of course this risk has been greatly reduced since privilege separation has been added to OpenSSH. An unauthenticated attacker can only talk to an unprivileged child process. Anyhow, with portknocking, the attacker can't even talk to the demon and therefore this risk is completely eliminated.

 

I was actually reading up on portknocking while I posted my previous post, and it became clear to me that it could simply just check the logs (provided that there are any). However, as I mentioned, portknocking is hard for me to implement, as the server in question will run a form of BSD, which I will lock down... I don't think altering the firewall in real time will work with my security settings. I'm actually trying to set it up so that even if root is compromised, there will be little damage to the system, if any. This basically means that normally, not even root will be able to alter security related configuration files. If I still want that to work, I'm going to have to find a way around it without changing the rules of the firewall.

On that note, is it possible to make SSHd establish the connection? Because in such case, I could make a rule that would allow outgoing connections, but not incoming, unless the connection in question was initialized through that outgoing rule. If I can configure the portknocker to tell SSHd to attempt to establish a connection to the user once the user provides the correct port knocking sequence, I'd get the stealth, along with a static firewall and a working SSH connection.

As for SSH running as root, isn't it possible to tell SSH to run as another user, or does it need root privileges?

 *sschlueter wrote:*   

> 
> 
>  *Gentist wrote:*   
> 
> And how is it that SSH can override the login system?
> ...

 

Someone mentioned that the keys you use for logging in (instead of password login) are not hashed versions of your password. If they aren't hashed versions of your password, I assume they can't be checked against your password stored in /etc/passwd. If it isn't checked against that password, I'm either missing something, or SSH bypasses/overrides the normal loginprocess. If that is the case, how come it's allowed, or even able to do that?

Another thing I thought about concerning the obscurity part of security; how do I remove the version number that SSH reports? I know that VersionAddendum overrides info about the OS, but what about SSH itself? Not letting anyone know what version you are using may help to prevent some attacks. I never really did understand why server software has to report version info to the outside world in the first place...

I'd like to thank everyone who has responded to this thread thus far, for reminding me of things I might've otherwise forgotten about, and for giving me new ideas and tips.

----------

## sschlueter

 *Gentist wrote:*   

> 
> 
> On that note, is it possible to make SSHd establish the connection?
> 
> 

 

No.

 *Gentist wrote:*   

> 
> 
> As for SSH running as root, isn't it possible to tell SSH to run as another user, or does it need root privileges?
> 
> 

 

It is intended to be run as root. I haven't tried it, but I guess lots of problems would arise if sshd would be started as an ordinary user. It could not bind to port 22, it could not read its own keys in /etc/ssh, privilege separation could not work...

 *Gentist wrote:*   

> 
> 
> Someone mentioned that the keys you use for logging in (instead of password login) are not hashed versions of your password. If they aren't hashed versions of your password, I assume they can't be checked against your password stored in /etc/passwd. If it isn't checked against that password, I'm either missing something, or SSH bypasses/overrides the normal loginprocess. If that is the case, how come it's allowed, or even able to do that?
> 
> 

 

This is a strange question. sshd could skip any login procedure and provide a shell to everybody that connects to it if it was designed to do so. All it would have to do is to bind to a port, spawn a shell upon connect and make that shell available through the connection. Even netcat can do this. No process has  to call login(1).

OpenSSH provides a variety of authentication mechanisms including password authentication, public key authentication, pam authentication and kerberos authentication.

Don't get me wrong, I really don't want to sound harsh, and it definitely isn't meant that way, but it seems to me that you haven't even read the man pages for sshd(8) and sshd_config(5). While I don't mind answering such questions, you should really learn the basics if you want to achieve a security level above the average.

----------

## Gentist

I've read all of sshd_config's man page, and quite a few other man pages (I haven't read all of sshd's man page recently though). Some of the questions I've asked, I asked because they (the man pages) didn't really give me a good answer. Other questions I asked because I wanted opinions, personal preferences, more information, etc... It's faster and easier than using Google, since I don't have to read through entire documentations and manuals of several 100 pages just to figure out if option x is a good idea for my system when I have option y enabled, but not option z.

Regarding the whole login override problem... It is rather obvious that it can do that, and that was a rather stupid question. I've even used similar methods to add security by allowing myself to bypass my firewalls on specific occasions before. I guess the question spawned from the thought of possible abuse.

I know, or at least knew, quite a bit more than the basics; it's not that I lack knowledge, it's just that I haven't touched these things in years. So I'm both outdated and have forgotten half of the things I learned. This is what you get for not writing things down the first time around.

----------

## sundialsvc4

I'd say that the single most important thing that you should do to secure ssh is to require the use of digital certificates.  Do not allow the daemon to respond to anyone and just ask them for a username/password.  Unless they possess a valid certificate, they cannot get in.

From a security standpoint, ssh is "simply a shell."  Sure, it encrypts the traffic, but who cares?  If it serves as "a program which allows <anyone> <anywhere> to present a username/password to my system," as ssh does, then "it's a security hole."

When you go to work, do they simply ask you, "say the magic word?"  No, they ask to see your badge.  You have to slide it through a reader which instantly verifies that the badge is valid and that it has not been revoked.  Only then does the door unlock.  Your computers should do no less.

Digital certificates, as used for this purpose, do not cost money.  You issue them and/or "sign" them yourself.  They serve as a credential that cannot be forged, and that can be individually issued.  For protection against unauthorized use, the certificates can be password-protected.  The documentation on how to do all of this is abundant and clear, and the procedure is quite easy to do.

----------

