SSH server place file on connection

[alienjon]

I know that there are a few ways that if you are connecting as a client to an SSH server you can run a script or command upon connection. Is there a way to do this in reverse? As in, when you successfully connect to an SSH server that server could run a script? In particular, I was wondering if a file could be created, copied, updated, or removed automatically on the client machine upon connection as directed by the server?

[eccerr0r]

That server would need authentication to the connecting machine to make sure it itself has rights to do so...
Does the client machine allow the server to ssh in, or perhaps they have the same shared authentication method like LDAP, yp, or perhaps share the same .ssh/ directory?
_________________
Intel Core i7 2700K/Radeon R7 250/24GB DDR3/256GB SSD
What am I supposed watching?

[szatox]

alienjon: no, but you could do something like

[alienjon]

[eccerr0r]

That's the thing, normal ssh using one set of credentials is only 1 way authentication - you need two way authentication. The server trusts that you are who you are, but your client machine does not necessarily trust the server.

And no, if you don't have anything interactive running on the server, you don't need to allocate a pty for getting results on the server and then processing the results locally. Depends on the command that's run on the server, however, some will insist on a pty.

Another option is to scp a file over.
_________________
Intel Core i7 2700K/Radeon R7 250/24GB DDR3/256GB SSD
What am I supposed watching?

[Hu]

Most people rely on Trust On First Use (TOFU) key validation for ssh. The first time you contact an sshd you have never seen before, your client asks you if this fingerprint is the expected one. If a MITM happens to be interfering here, and injects his own key, and you whitelist it anyway, then he can (and indeed, must) continue to MITM all your subsequent connections. If a MITM is not interfering on the first time, then he cannot interfere later because he will not be able to present the real server's key correctly. Most users expect that using ssh to talk to a peer should, at worst:

• Disclose to the peer anything you type
  
• Allow the peer to use any configured forwardings. (This can actually be very dangerous if the peer is malicious and abuses certain types of forwardings.)
  
• Misconfigure your terminal if the peer sends you bad control sequences

To elaborate on eccerr0r's point: most users do not expect that the server can run code on the client or manipulate the client's filesystem. In the general case, OP's feature would permit exactly that. Therefore, such a feature, if it existed, would need to be tightly guarded so that connecting to a malicious peer cannot do more harm than in those bullet points. The guard should, at minimum, require the user to enable via ssh_config an option that defaults to disabled. Ideally, it would run a program specified in ssh_config and allow that program to read some data from the server (perhaps via pipe, or perhaps passed as arguments). It would not allow the server to take any action not explicitly whitelisted in advance by the client.

[alienjon]

[Hu]

Running code on the client requires either a security exploit or the cooperation of the client. I am not aware of any such security exploits, and any that became known would likely be patched quickly. I am not aware of any way for an unmodified client to cooperate in that manner. Even if such a mechanism existed, I expect that any intruder worth worrying about would configure his client not to cooperate.

[khayyam]

[eccerr0r]

[alienjon]

[szatox]

Having some fun with them would most likely be illegal and pointless. There are a lot of zombies scanning the internet, so while doing some noticable damage to them would inform the owners that they have some disobedient stuff around them, the actual culprit would not be affected in any way.

[1clue]

IMO you'd need to have cooperation from the client in order to do a callback of any sort, and frankly the only people you'd get are the dumb ones anyway. Aside of the obvious illegal nature of attacking hardware which is not yours, the smart attackers almost certainly won't own the hardware you think they're coming from anyway, so you'd be attacking an innocent third party.

It seems like you'd be interested in penetration testing, but keep in mind that there's a very fine line between being a white hat (beefing up your own security and learning how attacks work) and being a black hat (attacking systems which are not yours).

You might want to search on pentest, ids (intrusion detection systems) and ips (intrusion prevention systems).

While you can't legally (in the USA anyway) attack systems which are not yours without explicit written consent of the system owner, you CAN go a long ways toward finding out who the black hat is and reporting them to the authorities if appropriate.

[alienjon]

[eccerr0r]

Ah okay, now it makes sense. It is indeed impossible to do the "fun," as the hackers know this and will not let anyone attack their own machines (or their zombies). For the most part there's nothing you can do short of manually hacking them themselves.

The best you could do is fake a login success with a honeypot and then set up a MOTD that infinitely spams their tty when they invariably login manually... but even this really this doesn't do much and they'll probably take revenge and DDoS your box. Sick sad world no?

Not much you can do unfortunately.
_________________
Intel Core i7 2700K/Radeon R7 250/24GB DDR3/256GB SSD
What am I supposed watching?