[sf-lug] ANALYSYS--EXPLANATION Re: request for help re ssh -- sshd login failure
jim
jim at well.com
Mon Feb 8 18:47:45 PST 2016
Michael's latest post is rich. I believe there are
a few SF-LUG members who would like to make sense of
some of the contents. I try to explain each command
in my comments, interspersed below.
If you are skilled in using command line shells,
or uninterested, ignore this reply
On 02/08/2016 12:41 PM, Michael Paoli wrote:
> Let's see ...
> http://linuxmafia.com/pipermail/sf-lug/2016q1/011674.html
> JS: this links to my original posting requesting help
> ...
> i686 i686 i386
> Ubuntu 12.04.2 LTS
> $ ssh lerner at ...
> JS: this is opaque to me: looks like basic info about Michael's test
> set up
> ...
> https://www.wiki.balug.org/wiki/doku.php?id=balug:cds_and_images_etc
> JS: NOTE: this links to a rich page of supported and unsupported Linux
> releases. At the bottom of the page is a request for CDs and DVDs.
> I am up for buying CDs and DVDs both for Bobbie and for Michael.
> Anyone else willing to chip in?
> <-------------------------------------------------!!!
> ...
> // my comments on lines staring with //
> JS: ## this is my way of indicating comments. The old-tyme comment
> delimiting character is #. The // characters work the same way as #.
> // some of this has nothing to do with the reported ssh/sshd issue
> // I did this on virtual machine, and (mostly) with serial console
> // and also enabling login on serial ... yeah, much unrelated,
> // but convenient for me :-) ...
> # virt-install --name=ubuntu12042i386
> --cdrom=/tmp/ubuntu-12.04.2-desktop-i386.iso --nodisks --livecd
> --network=network=default --ram=1024 --wait=-1 --os-type=linux
> --os-variant=ubuntuprecise --virt-type kvm --hvm
> JS: virtual machines are administered by a set of commands specifically
> for that purpose. The virt-install command takes a set of arguments
> such as --name=ubuntu12042i386 and also
> --cdrom=/tmp/ubuntu-12.04.2-desktop-i386.iso
> The pattern is ` --<key>=<value>'
> ...
> console=tty0 console=ttyS0,9600n8
> JS: I'm guessing that the ellipse above the console line simply
> indicates more keys and values for the virt-install command
> and that in the last line Michael wants us to see how he's
> implementing the primary console session.
> ...
> // that gives serial console, but not serial login,
> JS: I'm guessing that Michael is using some terminal program
> on some other host that connects through the 9 pin D serial
> connector on the host that's supporting this virtual machine
> instance.
> // so, from graphics console:
> xterm
> JS: loads X11 or whatever GUI library that's required for the window
> manager and desktop manager.
> $ sudo su -
> JS: Michael uses sudo authority to take on root user privileges
> # /bin/login -f ubuntu </dev/ttyS0 > /dev/ttyS0 2>&1 &
> JS: /bin/login is the command
> JS: -f ubuntu are two arguments to the login command,
> see man login for -f
> the < character is the inbound redirection token, which means get
> the input from /dev/ttyS0 and give that as input to the login command
> the > character is the outbound redirection token, which meant send
> the output of the login command and send it to /dev/ttyS0
> The 2> token means send any error messages to the output stream
> (so /dev/ttyS0 gets both the standard output and any error messages.
> The final & token tells the shell to run the entire command in the
> background rather than do its job once and then terminate.
> JS: I usually write such a command like this:
> # /bin/login -f ubuntu < /dev/ttyS0 > /dev/ttyS0 2>&1 &
> The difference is the extra space characters that help readers
> make sense more quickly.
> // now we have single temporary instance of our serial login,
> // procede with that:
> $ sudo su -
> JS: Michael wants to run the su command and take on root privileges;
> The - character is an argument to su that means that Michael's root
> use will include the root user's environment, i.e. it will be as though
> Michael logged into the system as the root user.
> // set up or "permanent" serial login (well, on "live", but whatever)
> # sed -e 's/tty1/ttyS0/g' < /etc/init/tty1.conf > /etc/init/ttyS0.conf
> JS: The sed comand is the stream editor, which takes a text file as
> its input
> and does something with it and then sends the result to the
> standard output.
> The -e is a sed option that indicates a script, in this case
> the regular expression 's/tty1/ttyS0/g' which tells sed to replace
> the string tty1 with the string ttyS0 in the entire input, globally.
> The < token sends the file /etc/init/tty1.conf to sed and the
> > token sends the output of sed to the /etc/init/ttyS0.conf file.
> # chown --reference=/etc/init/tty1.conf /etc/init/ttyS0.conf
> JS: The chown command changes permissions of a file.
> The --reference argument is specific to chown and tells
> chown to make the owner and group of /etc/init/tty1.conf apply
> also to the /etc/init/ttyS0.conf file.
> # chmod --reference=/etc/init/tty1.conf /etc/init/ttyS0.conf
> JS: The chmod command changes the permissions of a file,
> and this particular use sets the /etc/init/ttyS0.conf file have
> the same permissions as the /etc/init/tty1.conf file.
> # service ttyS0 start && exit
> JS: the service command starts up ttyS0 as a service.
> The && token means logical AND; the exit command
> will run if the service command succeeds. If the service
> command fails, then the shell will not exit.
> // and login on that serial, etc.
> $ sudo su -
> # useradd -m lerner && passwd lerner
> JS: the useradd command adds a user account to the
> /etc/passwd file and the && token means if that succeeds, then run the
> passwd program so that Michael can create a password
> for the lerner user.
> # apt-get -y install openssh-server
> JS: this installs the openssh-server package, i.e. the sshd daemon.
> # echo $(lsb_release -d) $(uname -m)
> JS: The echo command dumps to the standard output
> stream whatever it gets as its arguments after the shell
> has parsed the written command line.
> The $(lsb_release -d) argument uses the initial $ token
> to tell the shell to replace (lsb_release -d) with whatever
> the command lsb_release sends to standard output; the
> () characters tell the shell to run the lsb_release -d command
> in a sub-shell, not in the current shell.
> The $(uname -m) argument works similarly.
> The result is that the echo command gets the outputs of both
> the lsb_release -d and also the uname -m commands. Try typing
> $ lsb_release -d ; uname -m to see their output on your Linux system.
> Description: Ubuntu 12.04.2 LTS i686
> JS: The above text is what those two commands wrote on
> Michael's virtual machine.
> # (cd /etc/ssh && for f in *key.pub; do ssh-keygen -l -f "$f"; done)
> 1024 04:8e:06:ae:1b:f5:46:b3:38:99:df:90:4f:49:d2:e9 root at ubuntu (DSA)
> 256 7b:cf:1f:3e:1f:95:bc:63:21:00:80:9a:44:65:04:44 root at ubuntu (ECDSA)
> 2048 42:34:7b:7b:fe:94:00:a4:de:5d:85:58:74:b4:8b:55 root at ubuntu (RSA)
> JS: Michael is running as the root user and issues what is in essence a
> shell script that runs in a sub-shell, not the current shell, thanks
> to the () characters.
> First cd /etc/ssh to make the /etc/ssh/ directory the current
> directory.
> If that succeeds && then run a for loop
> The for token starts up the for loop. The f argument tells the
> for loop
> to use f as the name of a variable in the for loop. The in token
> delimits
> the specifications for the for loop from a list of things.
> The *key.pub statement specifies a list of every file in the
> /etc/ssh/ directory
> that ends with the string key.pub and as the loop runs, the value of
> the f
> variable will be the name of each file until the list is exhausted.
> After the loop
> has finished, the value of the f variable will be the last name of
> the list of
> files that conforms to /etc/ssh/*key.pub
> The do token delimits the list of files from the body of the loop,
> which is
> ssh-keygen -l -f "$f";
> JS: run the ssh-keygen command according to the rules for the
> -l and -f options that have been designed into the ssh-keygen
> command,
> and use the value of the f variable as an argument to the
> ssh-keygen command.
> The ; token is the end-of-statement token. The body of this for
> loop has just
> the one statement.
> This for loop will repeat the ssh-keygen command for each file in
> the /etc/ssh/*key.pub
> list.
> The done keyword is a token that completes the body of the loop
> (which begins
> with the do keyword).
> The three lines (beginning 1024, 256, and 2048) are the output of the
> for loop.
> // meanwhile, elseclient/elsehost:
> JS: I cannot figure out this meaning
> $ ip -4 a s | fgrep 192.168.122.
> inet 192.168.122.1/24 brd 192.168.122.255 scope global virbr0
> # ip -4 a s | fgrep 192.
> inet 192.168.122.220/24 brd 192.168.122.255 scope global eth0
> JS: run the ip command with -4 argument, which means to dump
> information only for IPv4 and not for IPv6
> JS: I do not understand the a and the s arguments.
> JS: The | token sends the output of the ip command to the
> fgrep command, which captures every line that has the string 192
> JS: Note the difference is the last word of each line, virbr0 and eth0
>
> $ ssh -ax -l lerner 192.168.122.220
> JS: run the ssh command according to the -a and the -x options,
> of which I, jim, am unsure, having just read the man page.
> The -l argument is also a ssh option and is followed by the
> name of the user who is logging in. 192.168.122.220 is the IP address
> of the host to which lerner is logging in (the host running the sshd
> daemon).
> JS: The following lines of text are output to the user logging in.
> JS: I'm guessing that most of it is generated by the sshd daemon and
> the final line by the login command.
> The authenticity of host '192.168.122.220 (192.168.122.220)' can't be
> established.
> ECDSA key fingerprint is 7b:cf:1f:3e:1f:95:bc:63:21:00:80:9a:44:65:04:44.
> // we check that this matches before we say "yes"
> Are you sure you want to continue connecting (yes/no)? yes
> Warning: Permanently added '192.168.122.220' (ECDSA) to the list of
> known hosts.
> lerner at 192.168.122.220's password:
> ...
> // and we're in:
> JS: The following commands are issued by the lerner user on host
> 192.168.122.220
> $ ip -4 a s | fgrep 192; hostname; id; ls -ld ~ /home
> inet 192.168.122.220/24 brd 192.168.122.255 scope global eth0
> ubuntu
> uid=1000(lerner) gid=1000(lerner) groups=1000(lerner)
> drwxr-xr-x 1 root root 80 Feb 8 12:08 /home
> drwxr-xr-x 3 lerner lerner 140 Feb 8 12:15 /home/lerner
> The ip -4 a s command (I still don't get the a and the s arguments)
> issues one or more lines of text. The | token sends the output lines
> of text to the fgrep command, which captures any line that has the
> string 192
> The ; token separates the ip command from the hostname command
> and from the id command and from the ls -ld ~ /home commands.
> The subsequent lines are the output of each of the commands.
> $ echo $(lsb_release -d) $(uname -m)
> Description: Ubuntu 12.04.2 LTS i686
> JS: This command has echo presenting the output of the lsb_release -d
> and the uname -m commands.
> JS: the remaining lines (below) show how Michael dismantled the
> virtual host he used for testing.
> $
> // anyway, enough 'o that ...
>
> # virsh list --all
> Id Name State
> ----------------------------------------------------
> 8 balug running
> // ^^^^^ - that's also the VM running all SF-LUG stuff except the
> list
> 9 ubuntu12042i386 running
> - blackie shut off
> - debiansidplusexperimentalamd64 shut off
>
> # virsh destroy ubuntu12042i386
> Domain ubuntu12042i386 destroyed
>
> # virsh undefine ubuntu12042i386
> Domain ubuntu12042i386 has been undefined
>
> #
> // the virt-install command above was actually run from script, not
> // manually input like that. Here's hint how I *really* did it:
> # diff TEMPLATE ubuntu12042i386
> 11c11
> < PATHTOISO="${PATHTOISO:-$(awk '/^[ ]*#/
> {next;};{if($2=="/media/cdrom9"){print $1;exit;};}' /etc/fstab)}"
> ---
>> PATHTOISO=/tmp/ubuntu-12.04.2-desktop-i386.iso
> 27c27
> < LIVECD=
> ---
>> LIVECD=y
> 49c49
> < OS_VARIANT=debianwheezy
> ---
>> OS_VARIANT=ubuntuprecise
> 99a100
>> set -x
> #
> $
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://linuxmafia.com/pipermail/sf-lug/attachments/20160209/306689b6/attachment.html>
More information about the sf-lug
mailing list