108
why can't I connect to my ssh server UNLESS I enter eval "$(ssh-agent -s)" first?
(lemmy.dbzer0.com)
From Wikipedia, the free encyclopedia
Linux is a family of open source Unix-like operating systems based on the Linux kernel, an operating system kernel first released on September 17, 1991 by Linus Torvalds. Linux is typically packaged in a Linux distribution (or distro for short).
Distributions include the Linux kernel and supporting system software and libraries, many of which are provided by the GNU Project. Many Linux distributions use the word "Linux" in their name, but the Free Software Foundation uses the name GNU/Linux to emphasize the importance of GNU software, causing some controversy.
Community icon by Alpár-Etele Méder, licensed under CC BY 3.0
please, it's
eval "$(ssh-agent -s)"
(quotes!)well seems to work without tho
edit: made no difference, but I changed it in the post title.
Just because it works, doesn't mean it's right.
I had a similar construct in my bashrc and forgot the quotes. It didn't throw an error but also didn't work. Took quite a while to find the issue. So personally, I would recommend trying to quote correctly whenever possible.
I was unclear: I did not mean to imply that it will work with it.
It's OT, but I'll clarify since it might be useful for people who find Bash cryptic.
Thing is, roughly speaking:
eval
will evaluate its first argument as Bash codeeval "$(any_command really)"
will run runany_command really
, take its output and then use it as first argument foreval
. So the assumption is thatany_command really
must output a valid Bash code snippet.So what
eval "$(ssh-agent -s)"
really means is, "run ssh-agent -s, collect the output and run it right here, where we are callingeval
. Compare tossh-agent -s | bash
-- this would also run ssh-agent output but it would run it in a new process--a child process of the current process---so the whatever the snippet would be, it would have no way of affecting state of the parent program, which is why it's safer.Aside: The reason we need eval in this case is that we actually need to affect state of the program: that's the whole point. We need to set several environment variables to values that ssh-agent "knows". Without
eval
we would have to "ask" ssh-agent separately for each value (I'm assuming it's not even supported) and then set all these envvars using eg.export
keyword. Usingeval
we let ssh-agent dictate the whole process: which variables are going to be set to what values, with the caveat that if compromised, it could do "evil" stuff like settingPATH
to override common commands with compromised code. etc.So what's the problem with the quotes? The Shell syntax,
foo "$(bar baz)"
will make sure that the thing between quotes isNow without quotes, Bash (as well as POSIX shell) actually have several things they can do with the output (read
man bash
for full list, but keep it for a long rainy evening). Some of it involves substituting eg. values like*
with matching filenames, some of it may involve actually splitting the output to separate arguments based on spaces or other special characters (which can even be different characters depending on current state, seeIFS
and the likes).You can see the difference, if you run eg.
printf '[%s]\n'
instead ofeval
. This printf syntax will simply print all of following arguments on a separate line, adding braces before and after. You can compare(both of these commands should be safe as long as
ssh-agent
is not compromised and as long I have not made any terrible typo)