# 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?

----------

## szatox

alienjon: no, but you could do something like

```
ssh myserver cat file_with_commands | bash
```

ssh will execute command (cat) on the remote machine, collect the output, and then your shell will pass it to bash process spawned locally.

Other handy things ssh offers are reverse port forwarding and vpn. Good stuff if the machine you want to reach is behind a firewall and you are not.

----------

## alienjon

 *eccerr0r wrote:*   

> 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?

 

I was thinking that the connection request by the client would be sufficient.  As in, the client wants to connect, provides appropriate credentials (however they're setup to be) and then performs the action.

 *szatox wrote:*   

> alienjon: no, but you could do something like
> 
> ```
> ssh myserver cat file_with_commands | bash   
> ```
> ...

 

That's an interesting thought.  I'll try toying around with that.  Does this need the -t option to work?  I've seen that in other posts, but not sure if it's required.

----------

## 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.

----------

## 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 sequencesTo 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

 *eccerr0r wrote:*   

> The server trusts that you are who you are, but your client machine does not necessarily trust the server.

 

This was something I had wondered about, in that would it be assumed that the client should automatically trust the server as it is the one who wants to make the connection in the first place (ie: if I walk into a store it would be safe to assume I have some purpose to walk into the store).

 *Hu wrote:*   

> 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.

 

This is getting to what had triggered this thought in the first place.  {Please keep in mind that I have little experience with networking security or the like}.  I wondered if, pending any standard security measures (such as passcodes or ssh keys) this kind of action could be used as a kind of secondary security policy.  Lets say that an unwanted user somehow bypasses my SSH security and gains terminal access to the machine.  I wondered if some code could be run - or a file placed - to better track down who it was who made the connection (while the IP could be through a proxy or spoofed, having access to a machine would allow better diagnostics of an IP).  A clever coder could even write a retribution script of sorts.

----------

## 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

 *alienjon wrote:*   

> [...] Lets say that an unwanted user somehow bypasses my SSH security and gains terminal access to the machine.  I wondered if some code could be run - or a file placed - to better track down who it was who made the connection (while the IP could be through a proxy or spoofed, having access to a machine would allow better diagnostics of an IP).  A clever coder could even write a retribution script of sorts.

 

alienjon ... firstly, that would have to target non-maleficent users similarly, and it would be something of a violation (of trust, etc) for you to install tracking software (on compliant users) with the rational that it is to protect against abuse by persons unknown. Secondly, what sort of 'code' would this be, are you going to expect /bin/bash (or some other interpreter, environment, machine-type, ssh client, etc, etc). It seems like a highly impracticable solution to a problem which should/could be addressed at source (ie, with the use of AllowUsers, PermitRootLogin, PasswordAuthentication, kerberos, fail2ban, etc).

best ... khay

----------

## eccerr0r

 *alienjon wrote:*   

> 
> 
> This was something I had wondered about, in that would it be assumed that the client should automatically trust the server as it is the one who wants to make the connection in the first place (ie: if I walk into a store it would be safe to assume I have some purpose to walk into the store).
> 
> 

 

Right, the thing is you indeed are somewhat trusting the server - as it is a ssh connection, the thing you trust is the PTY that you used to connect to it.  The server is indeed allowed to put characters on your pty anywhere it feels like.  But it does not give it the right to edit your /etc/passwd or ~/.bash_login - unless you open a hole for it.

Ssh does have more features than just allow drawing on your pty, it also allows network port forwarding and file transfer - but the client end knows exactly where the file will be placed and the server has no control whatsoever.

If it's not too secretive it would be interesting what use plan do you have for this.  It would be pretty nasty if, say, your employer has a sshd server and you connect with your client, and because you connected, your employer now can run spyware on your home machine, download your whole hard drive, or more...  That just seems wrong.  If you had that worry before, well, don't be, ssh does not have that "feature" (which I'd consider a bug!)

----------

## alienjon

 *eccerr0r wrote:*   

> If it's not too secretive it would be interesting what use plan do you have for this.  It would be pretty nasty if, say, your employer has a sshd server and you connect with your client, and because you connected, your employer now can run spyware on your home machine, download your whole hard drive, or more...  That just seems wrong.  If you had that worry before, well, don't be, ssh does not have that "feature" (which I'd consider a bug!)

 

As I said, I'm far from an expert with this stuff, so it was mostly out of curiosity.  What prompted the idea was my setting up a home server with external SSH access and my installing fail2ban.  I've started seeing bans for random attackers (bots looking for vulnerabilities, basically) and I had a random thought for whether, should they somehow bypass the security measures I've setup, if I could place a file or run a script that would reveal more information about the attacker or, as you mentioned, maybe have some more fun with them  :Wink: 

----------

## 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.Last edited by 1clue on Mon Feb 06, 2017 2:19 am; edited 1 time in total

----------

## alienjon

 *1clue wrote:*   

> 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.

 

In practicality system assessment for the purpose of reporting would be the farthest I'd go.  The rest was really more of capabilities.

 *1clue wrote:*   

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

 

Thanks for the advice.  I'll have to look into these.

----------

## 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.

----------

