So, my manager, in zsh, can do the following: scp -i =(ssh -qnx <snip> cat /etc/ks/ks_dsa) localfile server:/whereitgoes
Does anyone have any ideas what the syntax in bash is? I've been playing with this for hours. My manager says that zsh treats the cat'd key as a file, while if you try it with bash, replacing the = with <, it asks for the passphrase of what must be a socket.
mark
On Fri, Oct 12, 2012 at 12:44 PM, m.roth@5-cent.us wrote:
So, my manager, in zsh, can do the following: scp -i =(ssh -qnx <snip> cat /etc/ks/ks_dsa) localfile server:/whereitgoes
Does anyone have any ideas what the syntax in bash is? I've been playing with this for hours. My manager says that zsh treats the cat'd key as a file, while if you try it with bash, replacing the = with <, it asks for the passphrase of what must be a socket.
In bash <(command ...) should give you /dev/fd/## - connected to the output of the command. Which seems like it should work for that.
Les Mikesell wrote:
On Fri, Oct 12, 2012 at 12:44 PM, m.roth@5-cent.us wrote:
So, my manager, in zsh, can do the following: scp -i =(ssh -qnx <snip> cat /etc/ks/ks_dsa) localfile server:/whereitgoes
Does anyone have any ideas what the syntax in bash is? I've been playing with this for hours. My manager says that zsh treats the cat'd key as a file, while if you try it with bash, replacing the = with <, it asks for the passphrase of what must be a socket.
In bash <(command ...) should give you /dev/fd/## - connected to the output of the command. Which seems like it should work for that.
Should, but doesn't. Instead, every time when I do scp -i <(ssh -q <server1> cat /etc/ks/ks_dsa) /root/.ssh/id_dsa.pub <server2:/root/.ssh/authorized_key
it asks for the passphrase for key '/dev/fd/<meaninglessnumber>
mark
On Oct 12, 2012, at 1:44 PM, <m.roth@5-cent.usmailto:m.roth@5-cent.us> <m.roth@5-cent.usmailto:m.roth@5-cent.us> wrote:
So, my manager, in zsh, can do the following: scp -i =(ssh -qnx <snip> cat /etc/ks/ks_dsa) localfile server:/whereitgoes
Does anyone have any ideas what the syntax in bash is? I've been playing with this for hours. My manager says that zsh treats the cat'd key as a file, while if you try it with bash, replacing the = with <, it asks for the passphrase of what must be a socket.
mark
The document http://zsh.sourceforge.net/Intro/intro_7.html
has some description about =(…)
Not a zsh user myself
Ton Schreiner
Tony Schreiner wrote:
On Oct 12, 2012, at 1:44 PM, <m.roth@5-cent.usmailto:m.roth@5-cent.us> <m.roth@5-cent.usmailto:m.roth@5-cent.us> wrote:
So, my manager, in zsh, can do the following: scp -i =(ssh -qnx <snip> cat /etc/ks/ks_dsa) localfile server:/whereitgoes
Does anyone have any ideas what the syntax in bash is? I've been playing with this for hours. My manager says that zsh treats the cat'd key as a file, while if you try it with bash, replacing the = with <, it asks for the passphrase of what must be a socket.
The document http://zsh.sourceforge.net/Intro/intro_7.html
has some description about =(…)
Not a zsh user myself
I think you missed what I was asking, altogether. I want to do the same thing in bash....
mark
On Fri, Oct 12, 2012 at 2:48 PM, m.roth@5-cent.us wrote:
So, my manager, in zsh, can do the following: scp -i =(ssh -qnx <snip> cat /etc/ks/ks_dsa) localfile server:/whereitgoes
I think you missed what I was asking, altogether. I want to do the same thing in bash....
I think you'll have to drop the key in a tmp file yourself. Poking around with strace a bit it looks like that is what zsh actually does while bash gives what is essentially a named pipe where scp or ssh will attempt a seek (???) and then fail to read. The subsequent prompt for a passphrase in nonsense - it has already given up and closed it by then.
Les Mikesell wrote:
On Fri, Oct 12, 2012 at 2:48 PM, m.roth@5-cent.us wrote:
So, my manager, in zsh, can do the following: scp -i =(ssh -qnx <snip> cat /etc/ks/ks_dsa) localfile server:/whereitgoes
<snip>
I think you'll have to drop the key in a tmp file yourself. Poking around with strace a bit it looks like that is what zsh actually does while bash gives what is essentially a named pipe where scp or ssh will attempt a seek (???) and then fail to read. The subsequent prompt for a passphrase in nonsense - it has already given up and closed it by then.
THANK YOU, Les. I hadn't gotten to thinking about using strace (admittedly, I'd been busy with other stuff, too).
So either I write a tiny script, do it from the server with the actually key, or run it as a zsh command.
*piffle*
Thanks again.
mark
On 12.10.2012 21:30, m.roth@5-cent.us wrote:
Les Mikesell wrote:
On Fri, Oct 12, 2012 at 2:48 PM, m.roth@5-cent.us wrote:
So, my manager, in zsh, can do the following: scp -i =(ssh -qnx <snip> cat /etc/ks/ks_dsa) localfile server:/whereitgoes
<snip> > I think you'll have to drop the key in a tmp file yourself. Poking > around with strace a bit it looks like that is what zsh actually > does > while bash gives what is essentially a named pipe where scp or ssh > will attempt a seek (???) and then fail to read. The subsequent > prompt for a passphrase in nonsense - it has already given up and > closed it by then.
Yep, exactly right. People in #openssh confirmed -i HAS to be a real path to a file.
THANK YOU, Les. I hadn't gotten to thinking about using strace (admittedly, I'd been busy with other stuff, too).
So either I write a tiny script, do it from the server with the actually key, or run it as a zsh command.
Yes. You can also look at ssh-add.
On Fri, Oct 12, 2012 at 3:44 PM, Nux! nux@li.nux.ro wrote:
Yep, exactly right. People in #openssh confirmed -i HAS to be a real path to a file.
Not very unix-like behavior...
On 10/12/2012 01:56 PM, Les Mikesell wrote:
On Fri, Oct 12, 2012 at 3:44 PM, Nux! nux@li.nux.ro wrote:
Yep, exactly right. People in #openssh confirmed -i HAS to be a real path to a file.
Not very unix-like behavior...
Yes, it is. The alternative is for -i to take a file or a key as an argument, and that leads to ambiguous behavior.
I would offer that the behavior of zsh in Mark's request is neat, but not great security. The content of the private key on a remote machine is being written to the local machine's /tmp filesystem. Read permission will be limited to the user running zsh, so it's not super horrible (and I'm guessing that zsh uses O_EXCL to prevent race conditions that would expose the key). All the same, I keep my keys in an encrypted volume because they grant me access to my customer's systems. The idea of writing them to a filesystem that's not encrypted is just creepy.
On Fri, Oct 12, 2012 at 9:02 PM, Gordon Messmer yinyang@eburg.com wrote:
On 10/12/2012 01:56 PM, Les Mikesell wrote:
On Fri, Oct 12, 2012 at 3:44 PM, Nux! nux@li.nux.ro wrote:
Yep, exactly right. People in #openssh confirmed -i HAS to be a real path to a file.
Not very unix-like behavior...
Yes, it is. The alternative is for -i to take a file or a key as an argument, and that leads to ambiguous behavior.
How so? What's wrong with what behaves like a named pipe? That is, why does scp need to seek instead of just reading the contents?
All the same, I keep my keys in an encrypted volume because they grant me access to my customer's systems. The idea of writing them to a filesystem that's not encrypted is just creepy.
Sure, but who else can open your /dev/fd/##'s?
On 10/12/2012 07:20 PM, Les Mikesell wrote:
How so? What's wrong with what behaves like a named pipe? That is, why does scp need to seek instead of just reading the contents?
Whether it seeks or not is rather irrelevant to the question of whether or not it is unix-like behavior. seek() is quite normal behavior.
All the same, I keep my keys in an encrypted volume because they grant me access to my customer's systems. The idea of writing them to a filesystem that's not encrypted is just creepy.
Sure, but who else can open your /dev/fd/##'s?
I'm not sure what you're talking about, since that's not what zsh does. When you use "=(command)", zsh will run "command" with its output directed to a file in /tmp. The path to that file will be substituted where "=()" was used in the command-line.