Language modules for Visual Studio Code

[Richard Gaskin]

Sannyasin Brahmanathaswami wrote:

 > On 4/21/16, 4:16 AM, Richard Gaskin wrote:
 >
 >> put "scp "&quote& tGZFile &quote& \
 >> " 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
  ____________________________________________________________________
  Ambassador at FourthWorld.com                http://www.FourthWorld.com