bug-bash
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Login to remote server without coding passwords


From: Raphaël
Subject: Re: Login to remote server without coding passwords
Date: Tue, 14 Jan 2014 16:17:45 +0100
User-agent: Mutt/1.5.21 (2010-09-15)

probably out of scope of @bash, anyway:

On Tue, Jan 14, 2014 at 05:08:08AM -0800, janeitzey@rockingham.k12.va.us wrote:
> Is there a way to log into a server without using passwords coded into
> the script?

Does it means that access to your script isn't safe ?
Couldn't `chmod 700` do the trick in your case ?

> #!/bin/sh
[...]
> scp user@host:$copyPath/$myserial.pem $destinationPath/


At time=n:
- where will I put the passwd for user@host ?
- as a script argument ?
- or maybe as a global variable exported and setup in ~/.bashrc ?

At time=n+1:
- hum, finally I should use a ssh key

At time=n+2:
- if my script isn't "safe" for someone else access, how my key will be
?

At time=n+3:
# you connect your host through a ssh key kept in chmod 600 in your ~/.ssh 

...
# but you need password anyway (for stuff foo and bla) ?
...

At time=n+4:
- you keep ssh accesses in ~/.ssh
- you keep gpg keys in ~/.gnupg
- you keep other passwords in ~/.password-store using the `pass` utility
- you keep other passwords for non-interactive tools not allowing
  subprocess for password access in ~/.netrc

At time=n+5: you think:
"that's a whole lot of sensible important private access data".
Is my personal computer security worse storing them ?

At time=n+6:
- you encrypt these files using a loop-mounted filesystem block-device
# but what happens with root access ? and if with a physical access to
  the HD ?

At time=n+7:
- you encrypt your whole hard-drive partition including /boot and setup
  a password to your bios

At time=n+8 you think that all is secured from the root, but still if
you run an unsafe binary all your security chain is broken because once
mounted, secured data are available for any attacker reaching access to
your computer and you can't do anything about that except auditing all
your software (especially deamons and open sockets) or trusting that no
exploit will affect you.

But if, otherwise, your computer is safe in the first place, then your
script access is also safe on your hard-drive.



reply via email to

[Prev in Thread] Current Thread [Next in Thread]