Print

Please login or register.
1 Hour 1 Day 1 Week 1 Month Forever
Login with username, password and session length

[myzomela]

ssh newbie can't login

Hello all,

I'm a newbie to ssh and I can't login to my shiny new file server running VL 7.0 Lite. I'd be grateful for any wisdom out there.

Here's what I get trying to log in from 192.168.0.145:

Code: [Select]

dh@anthochaera:~> ssh -v root@acanthorhynchus
OpenSSH_5.4p1, OpenSSL 1.0.0 29 Mar 2010
debug1: Reading configuration data /etc/ssh/ssh_config
debug1: Applying options for *
debug1: Connecting to acanthorhynchus [192.168.0.21] port 22.
debug1: Connection established.
debug1: identity file /home/dh/.ssh/id_rsa type 1
debug1: identity file /home/dh/.ssh/id_rsa-cert type -1
debug1: identity file /home/dh/.ssh/id_dsa type -1
debug1: identity file /home/dh/.ssh/id_dsa-cert type -1
ssh_exchange_identification: Connection closed by remote host

There's a pause of a few seconds before the final line appears.  I never get challenged for a password.

I get similar responses from three other clients, so I doubt it's a client-side problem. The clients are three versions of OpenSuse (13.1 back to 10.3- soon to be retired) and Android 4.4.2 (running Juice ssh).  I can ssh into the Suse 13.1 box no trouble at all.

On the server, I know sshd is running:

Code: [Select]

acanthorhynchus:/~
root:# cat /var/run/sshd.pid
5864

even though 'service' says otherwise:

Code: [Select]

acanthorhynchus:/~
root:# service sshd status
service sshd is not active.

I doubt hosts.allow is a problem, as the same OpenSuse boxes can all access NFS shares on acanthorhynchus.  For what it's worth, here is the one active line in hosts.allow is:

Code: [Select]

ALL: 192.168.0.128/25(Yes, I know /25 is a bit odd.  Visitors using my wifi get addresses below 192.168.0.128 from DHCP, and they won't get access to the server.)

/etc/ssh/sshd_config is completely unmodified 'out-of-the-box'. Its only uncommented line is

Code: [Select]

Subsystem sftp /usr/libexec/sftp-serverwhich doesn't seem relevant.

I don't suspect a firewall problem, as acanthorhynchus is not running a firewall. (The whole LAN is behind a Smoothwall box.)

I've taken advice from an older post, "ssh login problem" (http://forum.vectorlinux.com/index.php?topic=14733)

[bigpaws]

1. Allow root may not be checked.

2. ps aux | grep ssh may show that the service is running

3. nmap localhost    (To show if port 22 is open)

4. iptables -L will list all rule set to see if there are ports blocked.

5. Compare /etc/ssh/sshd.conf with you other ssh servers.

HTH

Bigpaws

[roarde]

Code: [Select]

vsuper vsrvset
Select the runlevel (despite the fact that you're using it as a server, it's probably 2 or 4, not 3 or 5 -- I could be wrong)
Scroll to the bottom of the list and select sshd. If the config files you're using are not the ones expected by the script, new ones will be generated. If the filenames are as expected, they should be used as-is. Sshd is unselected by default on Light.
"service sshd status" should now report sshd running, and you can try again.

[myzomela]

Thanks for the suggestions, but the search continues.

1. Allow root may not be checked.

The outcome is the same for another login on the server, "dh":

Code: [Select]

dh@anthochaera:~> ssh -v dh@acanthorhynchus
OpenSSH_5.4p1, OpenSSL 1.0.0 29 Mar 2010
debug1: Reading configuration data /etc/ssh/ssh_config
debug1: Applying options for *
debug1: Connecting to acanthorhynchus [192.168.0.21] port 22.
debug1: Connection established.
debug1: identity file /home/dh/.ssh/id_rsa type 1
debug1: identity file /home/dh/.ssh/id_rsa-cert type -1
debug1: identity file /home/dh/.ssh/id_dsa type -1
debug1: identity file /home/dh/.ssh/id_dsa-cert type -1
ssh_exchange_identification: Connection closed by remote host


2. ps aux | grep ssh may show that the service is running

It certainly does:

Code: [Select]

root:# ps aux | grep ssh
root      2949  0.0  0.0   3704   448 ?        Ss   Jan01   0:00 /usr/bin/ssh-agent -- /usr/bin/startlxde
root      2971  0.0  0.3  23788  3096 ?        Sl   Jan01   0:00 /usr/bin/gnome-keyring-daemon --start --components=ssh
root     11749  0.0  0.1   4152  1040 ?        Ss   06:25   0:00 /usr/sbin/sshd
root     11812  0.0  0.0   2404   780 pts/0    S+   06:30   0:00 grep ssh

3. nmap localhost    (To show if port 22 is open)

Yep, sure is.

Code: [Select]

acanthorhynchus:/~
root:# nmap localhost | grep ssh
22/tcp   open  ssh


4. iptables -L will list all rule set to see if there are ports blocked.

Looks clear to me IMHO

Code: [Select]

root:# iptables -L
Chain INPUT (policy ACCEPT)
target     prot opt source               destination         

Chain FORWARD (policy ACCEPT)
target     prot opt source               destination         

Chain OUTPUT (policy ACCEPT)
target     prot opt source               destination 

5. Compare /etc/ssh/sshd.conf with you other ssh servers.

I'm working my way through this.  The Suse 13.1 box is running a later version of OpenSSH, so they're not directly comparable. One difference was
UsePAM yes
but VL7 tells me /etc/ssh/sshd_config line 88: Unsupported option UsePAM
 
I'll keep tinkering with the differences between the sshd config files.  Failing that, there's a Slackware 13.37 repository with a package for a later version of OpenSSH. It might be worth trying.

And lastly:

vsuper vsrvset

Thanks, yes, I did that

Code: [Select]

root:# service -a
Services level    2    3    4    5
bluetooth*        -    -    -    -   
cron*             -    -    -    on   
cups*             -    -    -    on   
firewall          -    -    -    -   
fuse*             -    -    -    -   
gpm*              -    -    -    -   
inetd*            -    -    -    on   
lm_sensors*       -    -    -    -   
nfsd*             -    -    -    on   
portmap*          -    -    -    on   
samba*            -    -    -    -   
sshd              -    -    -    on   

[bigpaws]

Have you looked at the logs from the host your are trying to connect to.

You can also try -vvv

Bigpaws

[myzomela]

Thanks bigpaws! I trawled the logs and found "connection refused by tcp wrapper". This pointed back to hosts.allow and hosts.deny. I've now discovered that the syntax of these files is very picky.  Instead of

Code: [Select]

ALL: 192.168.0.128/25
I need to put it like this:

Code: [Select]

ALL: 192.168.0.128/255.255.255.128
Now it works, and I've learnt a lot along the way.