[sf-lug] ANALYSYS--EXPLANATION Re: request for help re ssh -- sshd login failure
Michael Paoli
Michael.Paoli at cal.berkeley.edu
Wed Feb 10 17:16:47 PST 2016
Good analysis! :-)
Anyway, I'll give a wee bit more comments.
But mostly other than the technical (which
I may leave as an exercise ;-)).
> From: jim <jim at well.com>
> Subject: ANALYSYS--EXPLANATION Re: [sf-lug] request for help re ssh
> -- sshd login failure
> Date: Tue, 9 Feb 2016 02:47:45 +0000
> 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
No and yes ... that was mostly just bits excerpted from your original
posting, so I was going to create and target as similar as reasonably
conveniently feasible.
>> ...
>> 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?
>> <-------------------------------------------------!!!
Thanks, but I probably have enough DVDs (and even CDs) for a
while. About year and a half ago, or so, I picked up a 100
pack of DVD-R (or +R - whatever) for pretty cheap - well under
$0.20 USD per disc - I forget, but think it was $17.9x or $16.9x
for the 100 pack - so far only seen similar once for a lower
price (at or right around $2.00 less ... somewhere). Maestro also gave
me some more discs a while back too.
>> ...
>> // 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.
Very virtual, no physical serial. But much easier to copy/paste
text that way (e.g. for showing examples, output, etc.)
The console= bits were parameters passed to the kernel in the boot
loader when I was about to boot. Kernel can output to multiple consoles
simultaneously, but it only uses one for input - the last one specified
(or default, if none specified as arguments).
>> // so, from graphics console:
>> xterm
>> JS: loads X11 or whatever GUI library that's required for the window
>> manager and desktop manager.
Just fired up xterm ... could've also switched, on the (virtual) console
from a graphics virtual terminal to non-graphics virtual terminal -
either way would suffice ... but until I got to serial, I didn't yet
have convenient copy/paste of text.
>> $ 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.
I just took the command from /etc/init/tty1.conf but changing
from tty1 to ttyS0 for the (virtual) serial.
>> // 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)
Ah, typo there, should've been "set up our " ...
>> # 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.
Yup, ... did that to examine the server host's fingerprints for its
public ssh keys - so when I later connected from the client, I could
confirm that I got an expected key (and not something from a
Man-In-The-Middle attack).
>> // meanwhile, elseclient/elsehost:
>> JS: I cannot figure out this meaning
basically that's jumping over to the host to be used as client
>> $ 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.
a s - address show - shortest unique abbreviations for the ip command
>> 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
Key bits I was checking there, looking for the IP(v4) address and mask
of the client, and also the server (which I failed to mention jumping
back to for the one command), to ensure they were both on same subnet,
distinct IPs, and to (re)confirm the server IP(v4) address.
>> $ 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.
Off-the-top-of-my-head:
-a disable Authentication forwarding (generally what one wants, unless
one really needs/wants to forward authentication data, knows the
risks, and suitably trusts the server with that data)
-x disable X11 forwarding - generally what one wants to do unless
there's need/reason to be forwarding X11 on that connection/session.
I tend to include the above as habit for security, and only enabling
then when I quite explicitly intend to do so, and full knowing the
reason and risks. There's also newer:
-Y option for X11 forwarding, ... if there's something like a -y option
to disable that, I probably ought also get in habit of using that
too.
>> 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.
Yes, sshd server and/or ssh client (which may be passing it along,
and/or usefully interpreting and providing the relevant information).
>> 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
And where does my earlier email/output/comment(s) end, and yours start?
;-) - yes, I see where that (also) might confuse folks or make
reading/following it a bit harder (not that I claim to be perfect at
such ... or even anywhere close to perfect at it).
>> 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.
And yes, part of that showing the relative matching of hosts -
same OS, version, release, and architecture (i386/i686) as what was
shown in the email that started the whole thread.
And perhaps also to (overall) show that I'd done very little
beyond booting the ISO, creating a matching named account to
ssh to, installing the sshd software, and using ssh to successfully
connect to, authenticate to, and login as that user on the target
server I'd rather quickly set up.
>> JS: the remaining lines (below) show how Michael dismantled the
>> virtual host he used for testing.
>> $
Yep, time to rip 'er down ...
>> // 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
I also called out the VM upon which is running all of SF-LUG's non-list
stuff.
>> # virsh destroy ubuntu12042i386
>> Domain ubuntu12042i386 destroyed
>>
>> # virsh undefine ubuntu12042i386
>> Domain ubuntu12042i386 has been undefined
>>
>> #
I also showed in a wee bit more detail, at least retrospectively, how
I'd configured and fired up the virtual machine (notably not typing out
that rather long complex virt-install command, but by copying a TEMPLATE
script I wrote, making some minor modifications on that copy, and then
executing that).
>> // 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
>> #
More information about the sf-lug
mailing list