On or about Sun, 2010-01-17 at 16:43, give or take -0600, Yarin wrote:
> Hello all,
> Here I try to log into user "fmain": (with debugging view enabled)
>
>
> # ssh 109.107.120.17 -l fmain -v
> OpenSSH_5.2p1, OpenSSL 0.9.8k-fips 25 Mar 2009
> debug1: Reading configuration data /etc/ssh/ssh_config
> debug1: Applying options for *
> debug1: Connecting to 109.107.120.17 [109.107.120.17] port 22.
> debug1: Connection established.
> debug1: identity file /home/yarin/.ssh/identity type -1
> debug1: identity file /home/yarin/.ssh/id_rsa type -1
> debug1: identity file /home/yarin/.ssh/id_dsa type -1
> debug1: Remote protocol version 2.0, remote software version OpenSSH_4.3
> debug1: match: OpenSSH_4.3 pat OpenSSH_4*
> debug1: Enabling compatibility mode for protocol 2.0
> debug1: Local version string SSH-2.0-OpenSSH_5.2
snipped..
> I even tried adding "AllowUsers root fmain" to it, and restarting the SSH Daemon, but was no help.
>
> From my googling, there are plenty of people with the opposite problem (can log in, just not through root). And I tried everything that the few who seemed to have this same problem had done.
> I've exhausted my searching options and don't know where to go from here. Anyone have any ideas?
>
> Thanks for any help that you may be able to provide,
> Yarin
>
Are you sure you're connecting to the correct machine? To prove it,
sudo/su/login-as-root locally (if you can) confirm the hostname, then
touch a file in the /root directory called "this_is_the_CentOS_VPS.0"
Next, when you login "as root over SSH", run ls -ltr and look for that
file - if you don't see it, then maybe you are into the wrong machine :)
eg:
$ssh root@xxxxxxxxxxxxxx
password:
[login banner and motd stuff here]
#hostname
centos-VPS <---presumably, if not, read on below*****
# touch this_is_the_CentOS_VPS.0
this produces the foillowing file
#ls -ltr
-rw-r--r-- 1 root root 0 2010-01-18 20:04 this_is_the_centos-vps.0
this file proves what machine you are actually SSH-ed into.
If not, read on:
***** A common SSH gotcha occurs when the machine you are trying to
login to (the CentOS VPS one) is actually behind a firewall (or host
NAT, maybe for virtualization) that serves (and answers instead) SSH on
port 22 ( it answers instead, not knowing who root is - root login
disallowed usually - or who user1@, user2@ is )
What happens is, you attempt to ssh in with
$ssh user@xxxxxxx
but the machine that replies is the firewall protecting that IP, usually
the perimiter firewall.
It may, or may not, have a user called "root", and may, or may not,
allow the user root to login via SSH.
With the firewall scenario , the easiest way around this is to do PAT,
portforward TCP port 44422 on the firewall to port 22 at the destination
(internal) IP.
then the ssh client line you require is:
$ ssh user@xxxxxxx -p44422
the f/w NATP translates 44422 to 22 and NATting it to the VPS on it's
internal IP target.
In YOUR case, maybe the virtual host machine is running
linux/BSD/OpenSolaris also? and has SSHd listening on port 22?
$ ssh root@xxxxxxxxxxxxxxx = rootlogin disallowed and authentication
bombs out
One way to quickly check this, is to first check the debug output:-
{debugsnip} debug1: Remote protocol version 2.0, remote software
version OpenSSH_4.3
debug1: match: OpenSSH_4.3 pat OpenSSH_4*
{/debugsnip}
This tells you that the SSH server (that's actually responding to your
connect request; not necessarily the one you want to connect to)
is running _OpenSSH4.3_. To me, this smells a little old? OpenSSH 4.3
smells very old, in fact, even my old IPCOP boxes in remote locations
are up to v4.7. everything else here is 5.1
Check the VPS machine's SSHd version, if it's not 4.3, then you're
actually connecting to something else accidentally at that IP, usually
the virtualisation host (on it's port 22) or the perimiter firewall at
that site (on port 22)
While SSH does a very, very good job at handling multiple concurrent
connections tunneled to disparate ports and onwards to many consecutive
machines, you have to ensure that your are connecting to the correct
machine to let it do that in the first place.
You see, if the virtualisation host is running SSHd on port 22, it sees
the virtualised guest as a seperate machine, usually behind NAT, not
"behind" the.ho.st.ip:22. The virtual networking (+headache) of the
virtualisation host is what determines what conects to what, maybe
NATed or bridged.
Within one machine, sure, SSH will sort out many connections and
tunnels to many places (confounding CCNAs/MCSAs that are usually taught
one service=one port. The key word here is "within" It's a "unix-y
thing" you see. sockets/pipes and stuff haha) but that assumes your
connection to the SSH server is on the correct __machine__ in the first
place.
So, things to check: is there a firewall or unix/linux/IOS router
answering instead of your intended destination? No? Well, how about the
virtual host machine's SSHd, is that it? I've been there a thousand
times, nested several times deep in it :)
I hope that's all clear :)
The main problem is, after about 20 failed attepts and frustrated edits
of sshd.conf s you get in such a mess with your known_hosts being
populated with inaccurate entries that you mistakenly, said "yes" to.
(You really need to keep careful control of fingerprints or the pretty
pictures they use nowadays).
The debugging then tends to tell you all is OK, when in fact your
known_hosts are full of certs from perimiter firewalls and in-between
routers. You could compare the fingerprints, but in fact, I find it
easier to touch a file in my home and root's home on each destination
machine, AFTER having confirmed the hostname is correct. Touching a file
also helps subsequent SSHFS/SFTP sessions too, it's easy to get lost
with 20 or 30 open across 10+ virtual desktops.
### granny-sux-eggs-mode-is-ON. I have replied in full and at length to
#help other people browsing the archives in the future. Future traffic
#offlist unless relevant to all.
###
{caution: my home ISP mail queues (F2S/UK are in total disarray, may be
a day or two before they get straightened out, if ever}
de Gord
--
$whoami;pwd
gord
/home/gord
$./morecoffee.sh
