I have a script that runs ssh several times to do some manipulations on a remote system and also runs rsync to the same remote system two or three times.
Is there some way to get a single entry of the ssh password to work for all the ssh and rsync calls?
I *could* use key authentication but that has some downsides so I'd prefer to remain with using a password.
One approach is to use 'ControlMaster auto' in the .ssh/config which means all subsequent logins will re-use the first one, this however means that I need to have a 'persistent' first ssh. I've managed this by doing 'ssh -fN esprimo bash' at the start of the script but this then leaves the ssh running for ever and I'd prefer that not to happen.
Has anyone got any better ideas?
On Sat, 3 Feb 2018 09:40:53 +0000 Chris Green cl@isbd.net allegedly wrote:
I have a script that runs ssh several times to do some manipulations on a remote system and also runs rsync to the same remote system two or three times.
Is there some way to get a single entry of the ssh password to work for all the ssh and rsync calls?
I *could* use key authentication but that has some downsides so I'd prefer to remain with using a password.
What do you see as downsides? In my view ssh authentication should always be key based.
Mick
--------------------------------------------------------------------- Mick Morgan gpg fingerprint: FC23 3338 F664 5E66 876B 72C0 0A1F E60B 5BAD D312 http://baldric.net/about-trivia ---------------------------------------------------------------------
On Sat, Feb 03, 2018 at 02:20:19PM +0000, mick wrote:
On Sat, 3 Feb 2018 09:40:53 +0000 Chris Green cl@isbd.net allegedly wrote:
I have a script that runs ssh several times to do some manipulations on a remote system and also runs rsync to the same remote system two or three times.
Is there some way to get a single entry of the ssh password to work for all the ssh and rsync calls?
I *could* use key authentication but that has some downsides so I'd prefer to remain with using a password.
What do you see as downsides? In my view ssh authentication should always be key based.
So how does one use a key based ssh from 'anywhere'?
Also, if I use a key based system, I need to keep the keys safe and that is something I am quite likely *not* to do.
For example my laptop stays on nearly all the time with personal logins open, if some steals it (or simply has access) they will be able to get at my keys which may very well be unlocked. If I use password access to remote systems there is *nothing* on my laptop which will help anyone break into those remote systems.
On Sat, 3 Feb 2018 15:07:18 +0000 Chris Green cl@isbd.net allegedly wrote:
So how does one use a key based ssh from 'anywhere'?
Use a smart card. See for example https://www.linux.com/news/linux-workstation-security/2017/6/securing-privat...
Mike Cardwell also wrote about it several years ago on his grepular blog.
Also, if I use a key based system, I need to keep the keys safe and that is something I am quite likely *not* to do.
Nothing anyone can do can help you there.
Mick
--------------------------------------------------------------------- Mick Morgan gpg fingerprint: FC23 3338 F664 5E66 876B 72C0 0A1F E60B 5BAD D312 http://baldric.net/about-trivia ---------------------------------------------------------------------
On Sat, Feb 03, 2018 at 04:23:59PM +0000, mick wrote:
Also, if I use a key based system, I need to keep the keys safe and that is something I am quite likely *not* to do.
Nothing anyone can do can help you there.
I see you snipped my somewhat longer explanation! :-)
On 03/02/18 14:20, mick wrote:
On Sat, 3 Feb 2018 09:40:53 +0000 Chris Green cl@isbd.net allegedly wrote:
I have a script that runs ssh several times to do some manipulations on a remote system and also runs rsync to the same remote system two or three times.
Is there some way to get a single entry of the ssh password to work for all the ssh and rsync calls?
I *could* use key authentication but that has some downsides so I'd prefer to remain with using a password.
What do you see as downsides? In my view ssh authentication should always be key based.
I agree 100%
Cheers, Laurie.
On Sun, Feb 04, 2018 at 12:15:58PM +0000, Laurie Brown wrote:
On 03/02/18 14:20, mick wrote:
On Sat, 3 Feb 2018 09:40:53 +0000 Chris Green cl@isbd.net allegedly wrote:
I *could* use key authentication but that has some downsides so I'd prefer to remain with using a password.
What do you see as downsides? In my view ssh authentication should always be key based.
I agree 100%
I use ssh to access my desktop machine from the outside world, access is limited to three specific IP addresses which are places where I have ssh accounts: my TsoHost hosting, a virtual machine on Gandi Internet and another 'out there' system run by a friend.
So, to connect, I ssh to either TsoHost, my Gandi server or the other system and then ssh from there to my home system. This is *usually* from my laptop but is occasionally from other places such as a terminal/ssh app on a tablet or putty running on Windows or my wife's laptop.
It's non-trivial to maintain keys in this sort of multi-access scenario. I have a bad enough time keeping the outward going ones that live on my desktop machine in a reasonably sane state.
I also fail to see how using a key improves in any way on using a password. The length (and thus brute force vulnerability) of both can be made the same. If someone gets access to my laptop (which is the most likely means by which I might become vulnerable) they can use brute force on my keys for as long as they like with the power of quite a fast laptop to assist. They *can't* brute force my passwords because the remote systems will only allow three retries before disconnecting.
However you store keys they are vulnerable, they are stored. My passwords are only in my head and on the desktop machine at home (in encrypted form of course). If someone gets physical access to the machine at home then neither keys nor passwords are going to make any difference at all.
On 04/02/18 12:42, Chris Green wrote:
However you store keys they are vulnerable, they are stored. My passwords are only in my head and on the desktop machine at home (in encrypted form of course). If someone gets physical access to the machine at home then neither keys nor passwords are going to make any difference at all.
A private key created with a password is not decrypted until you enter the password. Consequently they are at least as secure as using a password - probably more secure as you need to be able to access a machine with the key on it, and also know the password.
Steve
On Sun, Feb 04, 2018 at 06:25:01PM +0000, steve-ALUG@hst.me.uk wrote:
On 04/02/18 12:42, Chris Green wrote:
However you store keys they are vulnerable, they are stored. My passwords are only in my head and on the desktop machine at home (in encrypted form of course). If someone gets physical access to the machine at home then neither keys nor passwords are going to make any difference at all.
A private key created with a password is not decrypted until you enter the password. Consequently they are at least as secure as using a password - probably more secure as you need to be able to access a machine with the key on it, and also know the password.
"... at least as secure as using a password.", yes, and?
On 04/02/18 22:28, Chris Green wrote:
On Sun, Feb 04, 2018 at 06:25:01PM +0000, steve-ALUG@hst.me.uk wrote:
On 04/02/18 12:42, Chris Green wrote:
However you store keys they are vulnerable, they are stored. My passwords are only in my head and on the desktop machine at home (in encrypted form of course). If someone gets physical access to the machine at home then neither keys nor passwords are going to make any difference at all.
A private key created with a password is not decrypted until you enter the password. Consequently they are at least as secure as using a password - probably more secure as you need to be able to access a machine with the key on it, and also know the password.
"... at least as secure as using a password.", yes, and?
Password-less key pairs and the judicious use of the sudoers file are perfectly valid and secure ways to perform the task(s) you describe.
ssh-add is also a valid way to deal with key pairs requiring a password where unattended tasks are to be performed.
Your call.
Cheers, Laurie.
On Mon, Feb 05, 2018 at 10:16:36AM +0000, Laurie Brown wrote:
On 04/02/18 22:28, Chris Green wrote:
On Sun, Feb 04, 2018 at 06:25:01PM +0000, steve-ALUG@hst.me.uk wrote:
On 04/02/18 12:42, Chris Green wrote:
However you store keys they are vulnerable, they are stored. My passwords are only in my head and on the desktop machine at home (in encrypted form of course). If someone gets physical access to the machine at home then neither keys nor passwords are going to make any difference at all.
A private key created with a password is not decrypted until you enter the password. Consequently they are at least as secure as using a password - probably more secure as you need to be able to access a machine with the key on it, and also know the password.
"... at least as secure as using a password.", yes, and?
Password-less key pairs and the judicious use of the sudoers file are perfectly valid and secure ways to perform the task(s) you describe.
ssh-add is also a valid way to deal with key pairs requiring a password where unattended tasks are to be performed.
Yes, I didn't say it wasn't possible to do with keys. I was just saying that for (some of) my ways of using ssh it's no less secure and easier to use passwords. (... and because it's easier it's more secure because you don't short-cut the security).
I use passphrase protected keys for quite of lot of ssh connections, I don't have an inherent dislike of them, but it's horses for courses.
On 05/02/18 10:26, Chris Green wrote:
[SNIP]
Password-less key pairs and the judicious use of the sudoers file are perfectly valid and secure ways to perform the task(s) you describe.
ssh-add is also a valid way to deal with key pairs requiring a password where unattended tasks are to be performed.
Yes, I didn't say it wasn't possible to do with keys. I was just saying that for (some of) my ways of using ssh it's no less secure and easier to use passwords. (... and because it's easier it's more secure because you don't short-cut the security).
I use passphrase protected keys for quite of lot of ssh connections, I don't have an inherent dislike of them, but it's horses for courses.
Chris,
Key pairs with passwords, judicious use of sudoers and ssh-add, solve the issue you raised in your original post.
Cheers, Laurie.
On Mon, Feb 05, 2018 at 10:49:44AM +0000, Laurie Brown wrote:
On 05/02/18 10:26, Chris Green wrote:
[SNIP]
Password-less key pairs and the judicious use of the sudoers file are perfectly valid and secure ways to perform the task(s) you describe.
ssh-add is also a valid way to deal with key pairs requiring a password where unattended tasks are to be performed.
Yes, I didn't say it wasn't possible to do with keys. I was just saying that for (some of) my ways of using ssh it's no less secure and easier to use passwords. (... and because it's easier it's more secure because you don't short-cut the security).
I use passphrase protected keys for quite of lot of ssh connections, I don't have an inherent dislike of them, but it's horses for courses.
Chris,
Key pairs with passwords, judicious use of sudoers and ssh-add, solve the issue you raised in your original post.
Yes, but it's still more complex (for the user, me) than using passwords directly, thus it's more error prone.
I've used a method which depends on ssh's ControlMaster option to sort my original problem.
Going back to password versus key for ssh if you do a search for it you will find it's an ongoing debate - rather like editor wars! :-)
Yes, a 2048 bit (or is it byte) key is more secure than a password and is more difficult to brute force. However I set up my systems so that brute forcing the password is virtually impossible, other ways to break in are far more likely. To brute force my password(s) an attacker needs direct access to the system where the passwords are stored, that's my home desktop machine, if they have direct access then cracking passwords is hardly relevant!
All the talk about vulnerability to brute-forcing passwords is mostly (totally) only relevant to servers 'out there' where others have some sort of access.
On 03/02/18 09:40, Chris Green wrote:
I have a script that runs ssh several times to do some manipulations on a remote system and also runs rsync to the same remote system two or three times.
Is there some way to get a single entry of the ssh password to work for all the ssh and rsync calls?
Do most of the work in a script on the remote machine, which is launched by one ssh from the local machine. If the script would require different actions depending on something, then use an initial rsync (using keys to login) to transfer the configuration data.
On Sun, Feb 04, 2018 at 09:01:04PM +0000, steve-ALUG@hst.me.uk wrote:
On 03/02/18 09:40, Chris Green wrote:
I have a script that runs ssh several times to do some manipulations on a remote system and also runs rsync to the same remote system two or three times.
Is there some way to get a single entry of the ssh password to work for all the ssh and rsync calls?
Do most of the work in a script on the remote machine, which is launched by one ssh from the local machine. If the script would require different actions depending on something, then use an initial rsync (using keys to login) to transfer the configuration data.
That's exactly what I would normally do but there are some rsync copies which can only be done from the client end unfortunately.
-
Chris Green -
Laurie Brown -
mick -
steve-ALUG＠hst.me.uk