Firewall security: Problems with simple Samba file share 3583

Yes it is. That is precisely the use of it. Man ssh ...

ssh (Secure Shell) is a program for logging into a remote machine and for executing commands on a remote machine. It provides secure encrypted communications between two untrusted hosts over an insecure network.

Because you don't seem to understand what ssh is for, given the evidence (I know you do understand at some level, but you don't seem to appreciate the design quite fully enough).

Why do you presume to tell your users what needs or abilities they have?

The aim of ssh is to allow secure logins. As soon as you read the "between .. untrusted hosts" in the description, you see that it doesn't matter from where!

Now let me tell you what scenario you try and avoid by your ruse: somebody having obtained one of your users pbuttwords (and-or secret key), but not having access to your users machine, so that they try and log in from a disallowed machine with the right pbuttword and-or key.

Spot the problem? They had access to the users machine because they got the secret key already! So they can log in from the users machine (and they can log in to the users machine, as they have the pbuttword and secret key ...).

If it's any comfort to you, I often have to do this sort of stepping-stone procedure when breaking into a secure network. First one steals a pbuttword on a local machine, then one leverages that into more and more accesses and keys. nfs locally is also helpful in that regard. And the more silly restrictions like "admin group only" you put in to sshdconf, the longer is the route round it. Once in I don't want to change your setup as you'd look there, so I might chose to add myself to the admin group, or simply leave a trojan to steal all the admin pbuttwords (and wipe itself as it gets them). I might even start my own ssh server on a specified port at a specified hour every day, and leave it running for 10mins only. Or I might randomise the hour and let it serve a dummy on a prearranged port for the ten minutes previous. That's enough for random tests to allow entry. Tcp logging might reveal it, however. Enough random and it won't.

No, I am telling yu what you ought to knw, what the design objective of SSH is. That you think

a) that it is something else, designed only for your needs and deficient otherwise, b) that your restriction closes a hole

reveals faults in thinking. There is no hole because ssh is already proof against the worst case.

There's no point. How did they GET those keys? That's right .. by logging in to one of those specific authorised IPs. They're the only places with them in the first instance.

Vaguenesses again. A local exploit only works because somebody has already managed to log in (and hence become local). They can only do that with the pbuttword (or secret key, in your case). So you are defending a situation that cannot be countered by your defense!

You have no say in the matter. You don't know where I am sitting. I can log in to an IP you do allow - in fact I must have done that in order to get the pbuttword-key in the first place.

The person with access to the design documents for the service.

Peter