@Zanna answered it: askubuntu.com/q/988141

@Videonauth I'm so there

@Zanna i was knowing this somehow

lol

and back i am

and im wet sweat from all those people surrounding me

not my favorite choice

@Zanna

I'm both disappointed and relieved that my lesson was cancelled so no trip to the city today

i can totally relate, peole where shopping today as if the world will end tomorrow

and with my ptsd and anxiety disorder this was not my favorite shopping trip

:S

Do just finished the last paperwork for this year :)

the next days i will fully rely on my introverts survival kit :) only leaving my flat one time tomorrow to catch a letter from a friend thats all

then everything is sorted til the 29th

@Zanna Normally I would say that this is because your old home directory is left over from a previous release, but I remember your having said you freshly reinstall rather than upgrading. Do you manually restore the contents of your old home directory, though? I have tested this (and re-tested it now, though less extensively than I did then), and as far as I can tell, the information in that answer is correct. What's in /etc/skel/.profile on your system? On 16.04, I have:

# ~/.profile: executed by the command interpreter for login shells.
# This file is not read by bash(1), if ~/.bash_profile or ~/.bash_login
# exists.
# see /usr/share/doc/bash/examples/startup-files for examples.
# the files are located in the bash-doc package.

# the default umask is set in /etc/profile; for setting the umask
# for ssh logins, install and configure the libpam-umask package.
#umask 022

# if running bash
if [ -n "$BASH_VERSION" ]; then
    # include .bashrc if it exists
    if [ -f "$HOME/.bashrc" ]; then

hello :)

Hi! :)

$ cat /etc/skel/.profile
# ~/.profile: executed by the command interpreter for login shells.
# This file is not read by bash(1), if ~/.bash_profile or ~/.bash_login
# exists.
# see /usr/share/doc/bash/examples/startup-files for examples.
# the files are located in the bash-doc package.

# the default umask is set in /etc/profile; for setting the umask
# for ssh logins, install and configure the libpam-umask package.
#umask 022

# if running bash
if [ -n "$BASH_VERSION" ]; then
    # include .bashrc if it exists

I don't copy my $HOME when I reinstall (I've never tried doing an upgrade; I always Erase the disk and install Ubuntu) but I do copy my ~/.bashrc because I have edited it a lot (though it would be a good exercise for me to re-write it)

I wonder why the variation...

I also copy ~/.mozilla

Huh. What do you get when you run apt source bash (it will create several entries in the current directory so you might not want to run it directly in ~), then cat bash-4.4/debian/skel.profile (or cat bash-4.3/debian/skel.profile on Ubuntu 16.04 and earlier)?

zanna@toaster:~/playground/source$ cat bash-4.4/debian/skel.profile
# ~/.profile: executed by the command interpreter for login shells.
# This file is not read by bash(1), if ~/.bash_profile or ~/.bash_login
# exists.
# see /usr/share/doc/bash/examples/startup-files for examples.
# the files are located in the bash-doc package.

# the default umask is set in /etc/profile; for setting the umask
# for ssh logins, install and configure the libpam-umask package.
#umask 022

# if running bash
if [ -n "$BASH_VERSION" ]; then

Interesting. I really remember checking this on 17.10 and it being the same as on 16.04. That memory is apparently false, though. The current file is the same as what you are getting: bazaar.launchpad.net/~doko/+junk/pkg-bash-debian/view/head:/…

If you can figure out what releases have this, then you can correct my post sooner than I can:

# set PATH so it includes user's private bin directories
PATH="$HOME/bin:$HOME/.local/bin:$PATH"

I think I had the same version on 16.04 & 10, but maybe that memory is false... I will turn on my 16.04 machine to see what it tells me

Thanks.

How do I see the actual list of branches at bazaar.launchpad.net/~doko/+junk/pkg-bash-debian/changes?

Alternatively, where does the Debian project store its patches in source control?

hmm... I don't know

I forgot the password for my main user on my 16.04 system lol

(fortunately I have another sudo user for such eventualities)

on my 16.04 system, my /etc/skel/.profile is the same as yours

I am attempting to boot into my 17.10 virtual machine to verify that its /etc/skel/.bashrc is the same as yours.

haha :)

I think maybe that repo just doesn't have the earlier releases' versions and doesn't have separate branches.

(Not an explanation for what actually appears in /etc/skel/.profile, only for why I can't browse to it there for older releases.)

so there's no way to determine from that what they were?

There certainly is some way. Just maybe not through that repo.

I mean, one can download the source .debs and check them.

@EliahKagan :) how are you, heres the one from my 17.10 installation unaltered from /etc/skel

# ~/.bashrc: executed by bash(1) for non-login shells.
# see /usr/share/doc/bash/examples/startup-files (in the package bash-doc)
# for examples

# If not running interactively, don't do anything
case $- in
    *i*) ;;
      *) return;;
esac

# don't put duplicate lines or lines starting with space in the history.
# See bash(1) for more options
HISTCONTROL=ignoreboth

# append to the history file, don't overwrite it
shopt -s histappend

# for setting history length see HISTSIZE and HISTFILESIZE in bash(1)

Hi!

That's .bashrc, not .profile, right?

@EliahKagan oh moment profile incomming

# ~/.profile: executed by the command interpreter for login shells.
# This file is not read by bash(1), if ~/.bash_profile or ~/.bash_login
# exists.
# see /usr/share/doc/bash/examples/startup-files for examples.
# the files are located in the bash-doc package.

# the default umask is set in /etc/profile; for setting the umask
# for ssh logins, install and configure the libpam-umask package.
#umask 022

# if running bash
if [ -n "$BASH_VERSION" ]; then
    # include .bashrc if it exists
    if [ -f "$HOME/.bashrc" ]; then

Since 17.04 is still supported, I should probably say which of the two forms its default .profile has, when I edit my answer. Do you happen to know?

@EliahKagan erm afaik the 17.04 looked the same but i can install a VM to find out if you like

not sure if it makes sense since support for 17.04 will be dropped in janurary

I should probably be able to figure it out with less trouble than that, by checking in the source deb.

i know on 16.04 the profile didnt source the .bashrc

mine does o.O and Eliah's does ^

weird , but ok the 16.04 i have on my laptop was installed as 16.04 was in beta2

maybe that makes a difference

I think it shouldn't make a difference, since .profile sourced .bashrc back in 14.04, too. May I see your .profile from that system? (And its /etc/skel/.profile too?)

@EliahKagan sec need to start it up

ok it seems the skel was changed afterwards here is the one i got created and i altered later on:

$ cat .profile
#!/bin/bash
# ~/.profile: executed by the command interpreter for login shells.
# This file is not read by bash(1), if ~/.bash_profile or ~/.bash_login
# exists.
# see /usr/share/doc/bash/examples/startup-files for examples.
# the files are located in the bash-doc package.

# the default umask is set in /etc/profile; for setting the umask
# for ssh logins, install and configure the libpam-umask package.
#umask 022

# set PATH so it includes user's private bin if it exists
if [ -d "$HOME/bin" ] ; then

and now the one from skel

$ cat /etc/skel/.profile
# ~/.profile: executed by the command interpreter for login shells.
# This file is not read by bash(1), if ~/.bash_profile or ~/.bash_login
# exists.
# see /usr/share/doc/bash/examples/startup-files for examples.
# the files are located in the bash-doc package.

# the default umask is set in /etc/profile; for setting the umask
# for ssh logins, install and configure the libpam-umask package.
#umask 022

# if running bash
if [ -n "$BASH_VERSION" ]; then
    # include .bashrc if it exists

I've edited my post. I hope the current, corrected version still makes sense.

@Videonauth Yeah, that makes sense. That's on 16.04, right?

@EliahKagan yep

regarding your post /usr/local is afaik be mirrored in ~/.local/usr/local/

if you want to install for one user only

i know it definitively for /usr/bin which has a mirror in ~/.local/usr/bin

nvm i should have had read on before speaking :)

@EliahKagan looks good :)

@eliah are you firm with ssh settings?

I guess... somewhat? Are you trying to figure something out involving them?

askubuntu.com/a/988054 can you have a proofread of my answer here and tell me if i messed something up

I'll look at it shortly (I'm going afk).

np no rush :)

I'm back, at least momentarily.

Is the goal to add a second SSH key for the same user on the same client?

@EliahKagan for a second user on the same client

he is practically asking if it is possible to have the second user use password and/or ssh and if thats possible and if not if they all have to use the same settings

From the same user account on the client, or from a different one?

this is why i wrote the lines at the top

The OP is using WinSCP on Windows. So I don't think they can actually run the commands you've given on the client, can they?

Or am I misunderstanding your answer?

he could run ssh-keygen on the machine he logs into as root

So you're saying to run those ssh-keygen commands on the server? You may want to clarify that.

ok

Is there any reason to pass the passphrase as a command-line argument instead of entering it when prompted?

not really i looked those commands up

so just giving -p makes it interactive?

If you omit -P and its passphrase operand, then ssh-keygen prompts you. This is more secure, because the passphrase is not stored in your shell's history, and because command-line arguments are almost always visible to other running processes, even processes run by a nonprivileged user.

ok will change that, have the answer open for editing right now

Lower-case-p is for changing an old passphrase to a new one, rather than creating one. I don't think it ever affects whether or not the user is prompted. It's the presence of -P ... that causes the passphrase to be taken from the command-line instead of by prompting the user.

removed it from both commands

what im more concerned about is the lower part if the settings for sshd_config are correct as they are or if i should include the line for RSA login too

Assuming you keep -C user1_email@example.com in the command you show, you might want to mention that the comment field is optional (i.e., -C ... can be omitted unless the user wants to set it or something specific about their situation requires it). Many users may not want to bother putting an email address into the comment field.

@Videonauth It looks fine to me, though perhaps I am missing something. What was the other line you were thinking of including?

RSAAuthentication yes

but this line is not existent within the ubuntu sshd_config

but on debian

ah nvm

Sorry, maybe you do want the comment field.

it is to distrust the authorized_hosts file

I am wondering if you need the -f ... part, in the command the user would use to reset the passphrase? If it's installed in the usual place in their home directory, then that shouldn't be required. But what system would the user run ssh-keygen -p -f user1_key on? Would they run that on the client? Since the client is Windows, I think they would instead need to use whatever WinSCP-specific method exists to change the passphrase, assuming it provides that, which I would guess it does.

The passphrase is used to encrypt the private key, and the private key exists on the client.

@EliahKagan yes you should point to the file you want to change otherwise the actual used file will be changed

Oh.

i.e. if you login as root@host and you dont specify the keyfile the actual key for root would be changed

Right.

i remember that because i fell in that trap as i have set up my PI

But... you're saying:

> The user can change the passphrase himself later

Where do they do that?

What system do they run ssh-keygen -p -f user1_key on, and what user are they logged in as when they run it?

on their computer if its linux or he would have to put the pub key on the VPS for a moment to change it

I recommend making that fully clear in the answer.

ah ok i should clraify that true

I forget sometimes that there are people using windows ;)

since i switched all my computers to linux i never looked back hehehe

So, my advice that -C could be omitted is wrong in this context. ssh-keygen will write root@hostname if you omit it, which is not desired here. Sorry about that!

However, is it really necessary to generate the key pair for the user as root?

I'm not really objecting to this, but the impact of mistakes can be lessened if the user uses su or sudo to become themselves and then does it.

So, the situation is that they can only log in as root to the VPS, right?

But their non-root user account exists on the VPS. So they can already use it, by running su user1 after logging in as root.

@EliahKagan yep

should be possible if its a usual Linux

Well the server is Ubuntu, right?

they normally using all the same OpenSSH upstream source

But regardless of what system it is, every Unix-like operating system provides a way for root to act as non-root users.

@EliahKagan I not asked but assumed this yes

should not make a difference tbh

They'll still want to use -f and -C. The rest of your procedure would not change. But the risks of making a mistake are lower. They cannot accidentally change root's own SSH configuration.

at least the files and location of the setup files are same on debian, ubuntu and arch

so unless you do a unusual gentoo install or otherwise different setup this should work

One additional advantage of having them su from root to themselves on the VPS to generate the key is that this command will be run as user1:

cat user1_key.pub >> /home/user1/.ssh/authorized_keys

fedora i would have to check, but i assume its the same

If that command runs as root, and authorized_keys didn't already exist, then it is created as root, which is undesired.

@EliahKagan ah yes ownership

The OP will be creating a private key for the client, on the server, so they will still need -f so they're not creating the one for their account on the server, and they should still use -C, too (sorry about what I said about that before -- that should have something unique that is not the same as what would be generated as the default comment).

So, to reiterate, I was wrong when I said the things that led you to add this part:

> The comment (-C) can be omitted

yes i left the line in but can write something about that

-C should not be omitted in this situation.

I have cut it out

Thanks. Sorry about that. I did not realize that the default behavior when -C is omitted is unchanged by using -f (and thus it always generates a comment appropriate only for when the machine you run it on is the client). More precisely, I did not think through how passing -f would not change the default comment (there's no clear correct alternative comment, so of course it wouldn't be changed).

well im merely a novice when it comes to ssh

i only have that bit experience from when i set up my PI as a small home-run server

and i have ssh only intern, no port forwarding from the router

all my machines here at home can ssh to the server via RSA/SSH key and to each other

I recommend they use su - user1 immediately, before even the first step. The only part of this that I recommend they do as root is editing /etc/ssh/sshd_config (assuming they end up doing that).

as you asked for the .profile of my 16.04 machine i sshed into it to get the info on my main pc

edited

and the language tags to bash actually makes sense on this answer too

added a reference that you helped onto the answer tho

I'm not sure I've really helped you enough that it's necessary to mention it, but thanks!

Do you want to add something about how it's also possible to generate the keys on the Windows client system, and then upload them to the server? winscp.net/eng/docs/ui_puttygen

will read into that and might add it then to the answer too if im sure i not write gibberish :)

Well I think the main important thing to include for that would be how to upload it, where to put it, and how to ensure the file that contains it has the correct ownership and permissions.

Btw, I believe this page is a good reference source on this topic in general (though it does not answer that specific question). Some parts are specific to DigitalOcean, but the other parts are widely useful.

yeah, thats a problem when creating a key on windows, if you create the key on linux it has usually the right permissions set

but as soon you copy that key to a vFAT exFAT NTFS drive the permissions are lost

added both links with some writing, and added manpage links for ssh-keygen and ssh

Recently, I learned a couple neat things about Bash. (cc @Zanna)

@Videonauth Thanks.

@EliahKagan oh yes? :D

I wrote a Bash script in which I mistakenly used a nameref as though it were a true reference to a specific variable. I know better than this, but my misunderstanding of another feature made it seem like it worked when I simplified the script to figure out what was wrong with it.

So, this illustrates the true behavior of namerefs:

#!/bin/bash

horse_say() {   # prints the value of a variable through a nameref
    local -n utterance="$1"
    local who='The Horse'
    printf '%s says, "%s."\n' "$who" "$utterance"
}

str='NEIGH'
foo='Foo Foo Foo'
who='The Duck'

horse_say str
horse_say foo
horse_say who

Its output is:

The Horse says, "NEIGH."
The Horse says, "Foo Foo Foo."
The Horse says, "The Horse."

:) What happened to The Duck?

Because the local variable utterance in horse_say() is declared as a nameref, expanding utterance has the same effect as expanding the variable named by its value.

that is very good to know. I'm not sure what I would have expected

So horse_say who behaves this way:

local who='The Horse'
printf '%s says, "%s."\n' "$who" "$who"

This is very different from reference semantics in most languages, where you are referring to an actual variable, not to a name. The term "nameref" is quite apt.

I knew about that, though. I was just able to not recognize my mistake, because...

#!/bin/bash

my_var=foo

assign() {  # a fuction that assigns to a named paramter, using a nameref
    local -n dest="$1"
    dest="$2"
}

caller() {  # a function that calls assign() to set a "local" variable
    local my_var
    assign my_var bar
    echo "$my_var"
}

caller
echo "$my_var"

The output of that script is the same as the output one would get if namerefs were true references to variables rather than names:

bar
foo

I did not understand why that works (how does the nameref inside assign() behave as though it has been bound to a local variable of a different function, caller (), rather than the global variable of the same name?), and I realized I misunderstood how a feature of Bash that I use regularly actually works.

Do you see what's going on there?

Um... it looks like locally (only in the caller() function) dest=my_var so my_var=bar (because dest=$2). Presumably that was what was supposed to happen... but what really happened was that assign saw foo bar, assigned foo=bar, and when caller() echoed "$my_var", the shell expanded $my_var as if it were $foo?

O.o I have no idea :)

But going to sleep

wait

start=$(head -n1 logfile | grep -oP '\[\K\S+' | sed 's|/|-|g; s/:/ /') thats terdons answer

do i get this right that the sed at the end makes the whitespace inside the output?

the last bit of the sed command

Replaces colon with space

But only the first one...

yep, now my problem, untar'ing the resulting file throws me an error unless i rename the file not having colons in it

#!/bin/bash
/home/server/log/script/do-log-job
start=$(head -n1 /home/server/log/access.log.1 | grep -oP '\[\K\S+' | sed 's|/|-|g; s/:/-/')
end=$(tail -n1 /home/server/log/access.log.1 | grep -oP '\[\K\S+' | sed 's|/|-|g; s/:/-/')
tar -caf "/home/server/log/logfiles-$start-til-$end.tar.gz" /home/server/log/access.log.1 /home/server/log/error.log.1 /home/server/log/ftp.log.1
truncate -s0 /home/server/log/access.log.1
truncate -s0 /home/server/log/error.log.1
truncate -s0 /home/server/log/ftp.log.1

i changed the first colon to be a hyphen because i didn't want whitepsaces

$ tar -xf logfiles-21-Jan-2017-14\:53\:49-til-21-Dec-2017-20\:37\:44.tar.gz
tar: Cannot connect to logfiles-21-Jan-2017-14: resolve failed

interesting problem

mhmm

Oh hmm... I don't know why that is, but do you want me to change my answer to purge the colons?

i tried this:

start=$(head -n1 /home/server/log/access.log.1 | grep -oP '[\K\S+' | sed 's|/|-|g; s/:/-/') | sed 's/:/-/g'

but that didnt do what i wanted

oh i see

nvm my fault

You can just add a g in terdon's command

oh ok

i didnt include the sed not within the brackets

Before the last quote

i see

cool that then, the second pipe to sed looks awfull

So the last s command is s/:/-/g

jupp got that, thank you very much

Well that output is being assigned to a variable... there won't be anything left to pipe because the assignment won't produce any output

why tar behaves like that on the colons is another thing i will find out but for now im happy when i can simply unpack my logfiles on commandline

:)

i solved it with this first:

start=$(head -n1 /home/server/log/access.log.1 | grep -oP '[\K\S+' | sed 's|/|-|g; s/:/-/' | sed 's/:/-/g')

now removed the second sed

now i just have to perfect my tar command, i dont want the whole folder stucture saved but only the files

but that i can figure out

I don't want to edit my answer since I'd have to add another s or y command, but if tar won't accept filenames with colons, I should deal with that in my answer explicitly and fix it

yeah i will tell you my findings why tar does that then you and terdon can edit your answers accordingly

it looks like it wants to connect to some host or such

otherwise i can'T explain the resolve error

I'll test it myself too. But going to sleep now. Remind me if I forget

i will

sleep well

Oh, found it:

An  archive name that has a colon in it specifies a file or device on a remote machine.  The part before the colon is taken as the machine name or IP address, and the part after it as the file or device pathname, e.g.:

              --file=remotehost:/dev/sr0

but you can work around:

--force-local
              Archive file is local even if it has a colon.

you can find it on: man tar under Device selection and switching

@Zanna Nothing like foo=bar is happening. There's a global variable my_var whose value is foo, but that value is never passed as a positional parameter to assign(). Even if the global my_var were not shadowed in caller() by local my_var, it would still be necessary for caller() to run something like assign $my_var bar or assign "$my_var bar in order to cause assign() to assign to a variable called foo, because my_var is not itself a nameref.

Aside from positional parameters (which are not really variables, if one uses the typical shell-scripting convention that all variables are parameters but not all parameters are variables), and also excluding special variables that bash assigns to automatically like FUNCNAME, the only variables that are ever written to when that script runs are the global my_var, the local my_var in caller(), and the local dest nameref in assign().

What I learned was that the behavior of code like that is not related to namerefs -- except in the very indirect sense that it can create the (dangerous) illusion that namerefs are references to particular storage locations rather than to names -- and the same effect can be produced without namerefs:

#!/bin/bash

x=outer

f() {
    x=inner
}

g() {
    local x
    f
    echo "$x"
}

g
echo "$x"

I was thinking "I won't need to use an extra s command if everything can be a hyphen, I can use a humble character class!" haha but now I have peeked in here I am awake

That prints:

inner
outer

@Zanna Sorry, I didn't mean to keep you from sleeping! (I'm guessing you're responding to what Videonauth was saying, but that you peaked back in here after you got the ping from my previous message about the unrelated Bash topic.)

I half woke myself up by laughing at the super obvious solution :) I peeked in here to mention it and only because of that saw the ping.

@EliahKagan seems logical

i extra not pinged :)

can hardly type, ma cat abuses my arm as sleeping place

@Videonauth Sorry, I should've added a @ when I mentioned you earlier so you'd see the sed-related message I was responding to.

@Videonauth thanks!

np, tar is actually very powerful tool

@Zanna Well it is certainly not what I expected -- I had wrongly thought that "local variables" in Bash are local in the sense that people usually mean by "local variables," i.e., in the sense of being lexically scoped. I had wrongly thought that variables declared in a function with local (or in a function with declare without -g, or in a function with readonly without -g) were local to the body of the function in which they appeared.

But instead of being local "in space," they are local "in time," i.e., they are local to the lifetime during which the function is executing, and they override any previous scoping for the variable even when they are accessed from a different function that the function that declared them calls. This is to say that "local variables" in Bash are dynamically scoped rather than lexically scoped.

So... g's local x got its value from f because g called f. It's local because it remembers the value it's been given in the function, not the global value...

Yeah, it uses the first value from the scope of a caller, so if there is no local variable by that name in the function where it is used, it goes up to the function that called it, and if there's none then, it goes up to the function that called it, potentially all the way to the outer scope (which is not itself a function).

Thus, when you read or write the value of a variable in a shell function, which variable is actually being accessed depends on how the function was called.

:)

So, for example, in Python, like in most programming languages (but not like in Bash, as I've recently learned), local variables are lexically scoped. For easier comparison to Python, here's an example in Bash similar to the above, but which only reads the value of a variable:

#!/bin/bash

my_var=outer

print_my_var() {
    echo "$my_var"
}

test_function() {
    local my_var=inner
    print_my_var
}

test_function
print_my_var

That outputs:

inner
outer

Thanks for sharing!

That looks equivalent to this Python program...

#!/usr/bin/env python3

my_var = 'outer'

def print_my_var():
    print(my_var)

def test_function():
    my_var = 'inner' # variables in Python are local unless declared otherwise
    print_my_var()

test_function()
print_my_var()

But that Python program outputs:

outer
outer

The Bash way seems less surprising to me...

It was very surprising to me! :)

In the Python program, the scope of my_var in print_my_var() could be modified by declaring it ahead of time with the global or nonlocal keyword, but neither produces the behavior seen in Bash. Adding a global my_var line just above print(my_var) does not change the behavior, because Python automatically uses variables from outer lexical scopes in this situation. Adding a nonlocal my_var line causes the script to fail with SyntaxError: no binding for nonlocal 'my_var' found.

@EliahKagan im actually searching the part in the manual, there was a very good part explaining th scopes of variables

@Videonauth Arguably the behavior is actually unambiguously documented even in the output of help local. I had previously thought "its children" referred to functions defined inside that function, but really there was no good reason for me to have thought that.

local: local [option] name[=value] ...
    Define local variables.

    Create a local variable called NAME, and give it VALUE.  OPTION can
    be any option accepted by `declare'.

    Local variables can only be used within a function; they are visible
    only to the function where they are defined and its children.

    Exit Status:
    Returns success unless an invalid option is supplied, a variable
    assignment error occurs, or the shell is not executing a function.

nah i was looking for python actually there was a very nice example with explanation why python behaves like this

docs.python.org/3/tutorial/…

or at least this is what this discussion reminded me of