Sannyasin Brahmanathaswami wrote:
> On 4/21/16, 4:16 AM, Richard Gaskin wrote:
>
>> put "scp ""e& tGZFile "e& \
>> " user at domain.com:~/public_html/livenet" &
>> "/LiveNet.livecode.gz" into tCmd
>> put shell(tCmd) into tResult
>> if tResult is not empty then
>
> This assumes you have your SSH keys on the server, right?
I had tried to anticipate that question in the line just above the code
portion you quoted:
- note that scp is able to securely transfer the file
without stopping for a password prompt because I have
my local machine's public SSH key shared with that
server, something we're all doing with our servers
anyway for both security and convenience, aren't we?:
Server admin requires SSH, and SSH benefits from shared keys. Whether
we also automate admin tasks, it's good practice to use SSH keys anyway.
Few of us will ever use a password as long as an RSA key, and using
keys exclusively allows us to do something very useful: prohibit
password logins altogether. Once we turn off password logins in a
one-line to sshd_config, suddenly our auth.log files are small and
meaningful, and our system is impervious to brute force password attacks
because no passwords are ever accepted at all.
This talk by Kyle Rankin at the SoCal Linux Expo (SCaLE) in February on
server hardening is an especially useful one (and when his new book on
this comes out in a couple months I would strongly recommend getting a
copy):
<https://www.youtube.com/watch?v=YmACTULbY1A>
Maybe you can join us at the next SCaLE, March 2-5, 2017. Mark Wieder
may be there (really enjoyed spending time with him at the last one),
and I'll certainly be there. Great sessions on server management, DBs,
community building, and so much more.
> I have done scp also from terminal when migrating one site to another
> server… giant tarball, in those scenarios we were putting the
> user-password in the scp command string… I wonder how secure that is?
Ideally a password would only ever exist in two places: RAM and an
admin's head.
But automation requires us to write passwords down somewhere, and the
ways to do that securely vary and are the subject of many Reddit debates.
For myself, I store server passwords in an file encrypted with RSA256*.
My LC tool uses "ask password" to open the file, and then the
passwords are merged into bash/Expect templates in RAM executed with the
shell function.
This limits automation to sessions where I'm running them, but avoids
the risk of having passwords in plain text on disk, or having a plain
text password on disk for the vault file that contains the other passwords.
Fortunately, the only thing I need fully automated without human
intervention is monitoring, but there are many ways to handle that
without needing privileged access on the host.
> Of course you don’t want to hard wire passwords into stacks, but you
> *could* offer users the option to enter it and store as a preference
> locally on their HD.
Unless you truly need automated privilege escalation, there should be no
need to write a password to disk.
SCP allows you to copy data anywhere the host account allows, so it's
best limited to use by admins. And since admins already have shared SSH
keys for all their other admin tasks, using SCP will not require an
account password.
Uploads from any non-admin team members are probably better handled
through a REST API, where the admin can control what comes in and where
it goes. Safer, simpler for the user, and once you get into the habit
providing services via REST APIs so many other things become ever easier
to deploy.
There are other tasks that can be useful to automate which will require
privilege escalation (like creating a batch of new users on a remote
host, or deploying packages or updating them, etc.) and normally sudo
prompts for a password.
In those cases Expect can be a useful tool - this post from Thierry
Douez gives an example of using Expect from within LiveCode:
<http://runtime-revolution.278305.n4.nabble.com/running-SCP-as-a-process-tp4674418p4674486.html>
You could use "ask password" to enter the password for the server, or a
password for a vault file that contains the server passwords, and from
that point on everything can be automated with template scripts using a
mix of bash and Expect, fed with LC's merge function.
But if you do a lot of that you may find it helpful to consider Ansible,
Juju, or other tools designed for server orchestration.
* About that vault file: I store mine on a thumb drive, along with my
SSH private key, email password file, Filezilla bookmarks, and other
info that might provide access to servers I manage. The file system on
the thumb drive is encrypted (OS X and Linux provide tools for that, and
perhaps Windows does as well).
By keeping sensitive info on a volume that's both encrypted and
removable, stealing the computer I use will not grant access to my
servers. They would also need to find me and take my thumb drive, and
then they would need to extract the password to the thumb drive from my
head. That's more effort than anything I work on is worth.
There are many systems available for two-factor security of sensitive
files, but an encrypted removable drive is nearly free (how many of us
don't have some 1GB thumb drive lying around that we picked up at a
conference?), and takes no more time to set up than a few minutes to
read the OS instructions on encrypting a volume, copy a few files, and
replace them with symlinks. Done once, it's comforting forever.
But of course do make backups of that thumb drive, and store them in
secure locations. Thumb drives are cheap, but a good night's rest is
priceless. :)
--
Richard Gaskin
Fourth World Systems
Software Design and Development for the Desktop, Mobile, and the Web
____________________________________________________________________
ambassa...@fourthworld.com http://www.FourthWorld.com
_______________________________________________
use-livecode mailing list
use-livecode@lists.runrev.com
Please visit this url to subscribe, unsubscribe and manage your subscription
preferences:
http://lists.runrev.com/mailman/listinfo/use-livecode
