Reverse ssh setup for pandora/pyra hw security.

[myNewUsername]

I just want to share a cool setup i tried out, inspired by some random youtube video. It is possibly relevant for other op/p owners who wants better odds of getting lost/stolen device back.


Experiment: So i have this laptop (think op/p) and a stationary. I can imagine that i will bring the laptop out of the house someday and loose it or get mugged. so i configured the the laptop to automagically do a reverse ssh to my stationary everytime it gets online. The result is that no matter where my laptop is, behind NATs, firewalls, under 1,83m of earth etc I can ssh into it from my stationary. In other words; whenever someone uses any random net to go online one the device, it is my power Wow omg thats really cool.


It works brilliantly for what i can tell. One downside is that my stationary is autoaccepting ssh from a potentialpy lost/stolen device, but that risk can be handled. It also relies on whoever uses your device gets acces to the desktop and dont format.


I am not sure what to do with the ssh though, if my laptop gets stolen. Maybe read browser history or use vnc? Anyways, can recommend.


Prerquisites: stationary has fixed ip/ using ddns


Steps: get ssh and sshd going. Generate keys, put portable's pub key in stationary's auth file, configure laptop to do a ssh -R at the portable when a conenction is up.

 

[rygD]

This reminds me of one of the presentations by  Zoz Brooks about a computer of his that was stolen.  I hope no one has their devices violated by unwanted naked pics of people.

 

[myNewUsername]

That is probably the "random youtube video i saw" yes. I would say he got revenge !

 

[Orbstheorem]

[Unit]
Description=Expose ssh connection to <server> via reverse SSH
After=network.target

[Service]
Type=simple
WorkingDirectory=/tmp
ExecStartPre=/bin/bash -c "rm /tmp/key{.pub}; wget <server>/keys && chmod 600 /tmp/key{,.pub}"
ExecStart=/bin/bash -c "autossh -M 0 -R *:$(curl -q <server>:2260 -d \"$(hostname)\"):localhost:22 <restricted public no shell user>@<server> -i /tmp/key -T -Y -v -N -n -o StrictHostKeyChecking=no"
ExecStartPost=/bin/bash -c "sleep 5; rm /tmp/key{,.pub}"

[Install]
WantedBy=default.target

[Service]
Restart=always
RestartSec=30

I've had this for years!

Port 2260 is a daemon that returns the port number to use given the hostname (So I can have a nice interface telling me which host is connected where)

 

[levi]

That's a systemd service file by the looks of it, so of no great use on a sysvinit system like the Pandora. Might be useful for Pyra owners though, provided they don't install devuan or something more exotic.

 

[Orbstheorem]

Hmm, I'll ask if Pyra will come with systemd instead. It's not *that* hard to convert files, but quite a few of my dotfiles assume systemd
[doublepost=1464279872,1464279658][/doublepost]https://pyra-handheld.com/boards/threads/pyra-debian-with-systemd.77488/

 

[slaeshjag]

I used to have this setup when I first got my pandora. Except it checked a webpage first to see if it was stolen. Only then would it try to open up the tunnel.

 

[Grench]

I used to have this setup when I first got my pandora. Except it checked a webpage first to see if it was stolen. Only then would it try to open up the tunnel.

Given the hardware in the Pyra, it could be programmed (at user's choice) to quite literally flip on the 4G module just long enough to check it's condition (stolen/not) then quietly post it's GPS latitude/longitude once per hour.

 

[levi]

If it isn't a SE unit, and has a SIM card installed, sure.

 

[Grench]

If it isn't a SE unit, and has a SIM card installed, sure.

Even if they stripped the SIM card from a 4G version - it could still be user-rigged to report in via any non password protected WiFi.

Of course I find it amusing that we, as users, consider setting up our own system for the units to, "call home," but celebrate that it is not a built in feature. Eventually someone will create and share an application for doing this on the Pyra depot.

 

[Orbstheorem]

For things like those, I just love open source communities!

 

[Plume]

Of course I find it amusing that we, as users, consider setting up our own system for the units to, "call home," but celebrate that it is not a built in feature. Eventually someone will create and share an application for doing this on the Pyra depot.

Well, the question is, what is "home". Is it somebody else's or my own machine ?

 

[pyrat]

Sorry if I'm a bit lost.I'm puzzled on why you don't leave the client keys in the client and verify the server keys by configuring the server public key in known_hosts.

ExecStartPre=/bin/bash -c "rm /tmp/key{.pub}; wget <server>/keys && chmod 600 /tmp/key{,.pub}"

Do you mean rm /tmp/key{,.pub} or rm /tmp/key.pub ? (just curious why you use {} for a single file)
Is /keys literal ? Is it supposed to download /tmp/key and /tmp/key.pub ?
I don't understand the purpose. Are you downloading the client keys from the server you want to verify those keys ?
It looks like you don't want the client keys to stay very long in the client (for fear of the client being stolen?)
but then you publish them in your server for the whole internet ?
Then anyone could download them and impersonate the client, if they want. Or what does <server> do to authenticate your wget
(x509 client certificates configured in .wgetrc? then there's a private key in the client for that client certificate,
not very different from the client ssh key you are downloading)

ExecStart=/bin/bash -c "autossh -M 0 -R *:$(curl -q <server>:2260 -d \"$(hostname)\"):localhost:22 <restricted public no shell user>@<server> -i /tmp/key -T -Y -v -N -n -o StrictHostKeyChecking=no"

Is "-o StrictHostKeyChecking=no" necessary ?
It will work if /etc/ssh/known_hosts or ~/.ssh/known_hosts already contains the server key , right ? That's one step at setup you have to make in the client, or just risk the first connection.
Otherwise it might allow anybody to spoof your DNS or ARP and impersonate your server, and therefore have a tunnel handy to connect to your client (they still have
to be accepted by the client sshd, but then the situation is similar to just have sshd listen to the internet and dynamic dns to locate the client, potentially vulnerable to brute force attacks
if login is by password or whatever applies). If ~/.ssh is persistent then it is a risk for the first connection, if ~/.ssh for the user running this is erased often then it is a more premanent risk.
I mean without "-o StrictHostKeyChecking=no" would require setting up /etc/ssh/known_hosts but would be more secure, wouldn't it ?

 

[Nikita Yushchenko]

Do you mean that whoever can download keys via wget and ssh using these to your server? Even with restricted no-shell user, this does not look safe

 

[pyrat]

Do you mean that whoever can download keys via wget and ssh using these to your server? Even with restricted no-shell user, this does not look safe

It depends on how the http(s?) server is set up. I just don't see the advantage of downloading client keys, because securing that download is as difficult as what the keys are securing.
It even depends on how the sshd is set up in the server, though it does not look like it's asking for passwords, I guess only client key.

The usual way is you generate the keys in the client (or offline and copy it to the client), copy the public key to the server and configure it there. The secret key stays at the client. It may be protected by a passphrase or in case it is needed for some automated process run without the user there, it may be in the clear (or ciphered and the passphrase configured somewhere). I think this and verifying the server key would be
good enough for me. It could be changed somehow by simply having the server reject the client access until you realise the device is stolen and then reconfigure the server. Or this might be worse depending
on assumptions (is it worse risking some restricted acces to the server or missing some location info from a stolen client? is it stolen or just lost ? is it lost somewhere where it can get GPS? can it itrangulate from LTE?).

If you can't trust the client (for fear of being stolen or whatever) you're basically screwed. You ethter don't allow the client to connect, or you set up some strange secure boot like thing where some secret key
offline controls what code runs and what it does, and then you only give access to the client secret key to trusted code that is not effectively under the user control but under the master key holder control. I don't know if the Pyra is good for that. I'd say fortunately not, because of the unbrickable boot, but I'm not sure. Usually the master key holder is the manufacturer and the user is the owner, and then secure boot and trusted computing is wrong. It could also be the owner is the master key holder and the thief is the user, and then it would be good, but for me it is still too complex. I think the threat model for the chromebooks does it more like that. But then many chromebooks have chips that are controlled by the manufacturer keys, so no good.

For me it is simpler trusting the client, even if stolen, with some mitigations as restricted access to the server or so. This is thinking you'll be able to recover the client or declare it unrecoverable and cut access before
the thieves can make use of the client key and break into something more. Is your client more valuable than your server, or the other way around ? Would you prefer a litlle more risk in one to gain some more protection in the other?

Another scenario is the device is not stolen, just breaken into (through some vulnerability in the client because the client has more software, less secure configurations so that it is useful, or visits networks that are less trusted (less than the internet ?), and then you're given (restricted) access to your server to whoever broke into your client...

But we don't know the whole setup and the threat model or the use cases. It may make sense somehow.
I just wouldn't blindly copy this solution without understanding it more.

 

[tarator]

I am not sure what to do with the ssh though, if my laptop gets stolen. Maybe read browser history or use vnc? Anyways, can recommend.

Awesome! I've never heard of reverse ssh before!
After ssh into the device you could get the coordinates from the GPS-Module.
I plan to install a simple webapplication on a public server and a cronjob on the pyra which pings the webservice with GPS coordinates regularly. So I always know, where my Pyra is...

 

[Orbstheorem]

Do you mean rm /tmp/key{,.pub} or rm /tmp/key.pub ? (just curious why you use {} for a single file)

"/tmp/key{,.pub}" is expanded to "/tmp/key /tmp/key.pub" by the shell

Is /keys literal ? Is it supposed to download /tmp/key and /tmp/key.pub ?

No, it downloads both keys

I don't understand the purpose. Are you downloading the client keys from the server you want to verify those keys ?
It looks like you don't want the client keys to stay very long in the client (for fear of the client being stolen?)
but then you publish them in your server for the whole internet ?
Then anyone could download them and impersonate the client, if they want. Or what does <server> do to authenticate your wget

I'm not looking too much into authenticating the client here, just to bring them online. The server strategy to restrict the download is a combination of hostname and unix timestamp. Each client gets a different key

I mean without "-o StrictHostKeyChecking=no" would require setting up /etc/ssh/known_hosts but would be more secure, wouldn't it ?

This wasn't strictly necessary, I just didn't wanted to add the server key each time. Reciently I switched to DNSSec for authenticating the server.

Do you mean that whoever can download keys via wget and ssh using these to your server? Even with restricted no-shell user, this does not look safe

Yes. Can you explain a situation in which someone being able to ssh with a user whose shell is /bin/false could do something malicious. The remote server policy is to allow only the port received by curl'ing the daemon on port 2260 to be forwarded.

 

[pyrat]

"/tmp/key{,.pub}" is expanded to "/tmp/key /tmp/key.pub" by the shell

Yes, and "/tmp/key{.pub}" (no comma in your ExecStartPre first brace) expands to /tmp/key.pub alone.
Since it would be the same if you wrote /tmp/key.pub I wondered about the braces. If you meant both files in both places (before and after wget), then there's a comma missing after the first brace.

No, it downloads both keys


I'm not looking too much into authenticating the client here, just to bring them online. The server strategy to restrict the download is a combination of hostname and unix timestamp. Each client gets a different key

Not sure I understand, but it doesn't matter so much.

Yes. Can you explain a situation in which someone being able to ssh with a user whose shell is /bin/false could do something malicious. The remote server policy is to allow only the port received by curl'ing the daemon on port 2260 to be forwarded.

Not myself. Not sure if a ssh client can specify a command instead of the default shell, but it seems it can open a tunnel to a third server and then attack it making it look like your server is the attacker, DOS your server, or this kind of things.

semicomplete.com/articles/ssh-security/
http:// http://serverfault.com/ques...difference-between-sbin-nologin-and-bin-false
http://serverfault.com/questions/519215/what-is-the-difference-between-sbin-nologin-and-bin-false

 

[Orbstheorem]

Yes, and "/tmp/key{.pub}" (no comma in your ExecStartPre first brace) expands to /tmp/key.pub alone.
Since it would be the same if you wrote /tmp/key.pub I wondered about the braces. If you meant both files in both places (before and after wget), then there's a comma missing after the first brace.

My bad, I didn't notice the missing comma. Mea culpa.

Not sure I understand, but it doesn't matter so much.

What I meant is that the URL the client uses to download the key is composed by using the client's hostname and unix timestamp. Then, the server validates the url requested and gives the key corresponding to that client.

Not myself. Not sure if a ssh client can specify a command instead of the default shell, but it seems it can open a tunnel to a third server and then attack it making it look like your server is the attacker, DOS your server, or this kind of things.

semicomplete.com/articles/ssh-security/

http://serverfault.com/questions/519215/what-is-the-difference-between-sbin-nologin-and-bin-false

Very interesting article! Thanks! I never though at such kind of attacks. I'll have to improve my current infrastructure.