Ping not respond, SSh not login,

Dear all,

after installing 13.1, I really sorry, lot of things not working. Too complex now.

Can not login from local subnet using ssh, even after modify /etc/ssh/sshd_config

Pings from pcs in local subnet not responding too.

And more, but I need this two basic things to continue.

From 13.1 to other computers not problems at all. I can login into others linux using ssh.

Thanks in advance.

Probably the Firewall is blocking.
Try to disable/stop it temporarily in YaST->Security and Users->Firewall.

And make sure that the sshd is running. See YaST->System->Services Manager.

On 04/04/2014 11:56 AM, sergioszy wrote:
>
> Dear all,
>
> after installing 13.1, I really sorry, lot of things not working. Too
> complex now.
>
> Can not login from local subnet using ssh, even after modify
> /etc/ssh/sshd_config

First, be sure SSH is running, as a default install will not have it
running. You can use Yast to start the service, and set it to auto-start
in the future.

After that, you should make sure that the firewall is not blocking TCP 22,
which you also do via Yast: Security: Firewall. Add ‘Secure Shell’ from
the list of allowed services, save and that should be it. To load this
from the command line:

Code:

sudo /sbin/yats firewall

> Pings from pcs in local subnet not responding too.

The default firewall does not block ICMP echo requests, so this isn’t the
firewall unless you’ve customized it to block somehow.

> And more, but I need this two basic things to continue.
>
> From 13.1 to other computers not problems at all. I can login into
> others linux using ssh.

Ask the 13.1 box a bit about itself and post back the results:

Code:

#IP information
ip addr

#Route information
ip route

#listening services
/usr/sbin/ss -planeto | grep LISTEN

#Firewall configuration
/usr/sbin/iptables-save


Good luck.

If you find this post helpful and are logged into the web interface,
show your appreciation and click on the star below…

A newbie might not have recognized the typo

Code:

sudo /sbin/yats firewall

should be

Code:
 --------------------
 sudo /sbin/yast firewall
 --------------------

Agree with previous posts.
Verify ssh service is running.
Verify firewall has been configured to allow incoming ssh connections.

The YAST methods described should work.

TSU

yast is TUI and yast2 is GUI so it should be.

/sbin/yast2

To check if the firewall is up

rcSuSEfirewall2 status

To disable the firewall

rcSuSEfirewall2 stop

To check if sshd is running

rcsshd status

Of course if you want to use a gui tool then

yast2 firewall

is what you want as it was suggested above :wink:

To check which port is open

nmap {remotehost|remote-ip}

replace remotehost and remote-ip accordingly and you don’t need both just pick one :wink:

On 04/05/2014 10:56 PM, jetchisel pecked at the keyboard and wrote:
> To check if the firewall is up
>
> Code:
> --------------------
> rcSuSEfirewall2 status
> --------------------

Unless you are using systemd in which case it would be:



systemctl status SuSEfirewall2


Change the status with start, stop, enable for the function you are
looking for. Systemctl is <tab><tab> friendly.

Ken

On 2014-04-06 13:44, Ken Schneider wrote:
> On 04/05/2014 10:56 PM, jetchisel pecked at the keyboard and wrote:
>> To check if the firewall is up
>>
>> Code:
>> --------------------
>> rcSuSEfirewall2 status
>> --------------------
>
> Unless you are using systemd in which case it would be:

Nope. Even in that case, the rc… syntax works. There was a decision to
keep in openSUSE the rc… links, and even more, make sure that
services that don’t have it create it or the package will not build in OBS.


Cheers / Saludos,

Carlos E. R.
(from 13.1 x86_64 “Bottle” at Telcontar)

On 04/06/2014 09:18 AM, Carlos E. R. pecked at the keyboard and wrote:
> On 2014-04-06 13:44, Ken Schneider wrote:
>> On 04/05/2014 10:56 PM, jetchisel pecked at the keyboard and wrote:
>>> To check if the firewall is up
>>>
>>> Code:
>>> --------------------
>>> rcSuSEfirewall2 status
>>> --------------------
>> Unless you are using systemd in which case it would be:
> Nope. Even in that case, the rc… syntax works. There was a decision to
> keep in openSUSE the rc… links, and even more, make sure that
> services that don’t have it create it or the package will not build in OBS.
>

That is true, for now. At some point they will go away.

Once you get used to using systemctl and it’s <tab><tab> capabilities it
becomes easier to use. You can even use ‘systemctl start <tab><tab>’ and
it will (I believe) only show services that are not started. Therefore I
find it to actually more intuitive.

Ken

On 2014-04-06 21:52, Ken Schneider wrote:

>>> Unless you are using systemd in which case it would be:
>> Nope. Even in that case, the rc… syntax works. There was a decision to
>> keep in openSUSE the rc… links, and even more, make sure that
>> services that don’t have it create it or the package will not build in
>> OBS.
>>
>
> That is true, for now. At some point they will go away.

No, they will not. It is official openSUSE policy to keep them, and
enforce adding them with an automated check in OBS.

See:

+++···························
Date: Wed, 29 Jan 2014 13:48:05 +0100
From: Ludwig Nussel <...@suse.de>
To: openSUSE Factory list <opensuse-factory@opensuse.org>
Subject: [opensuse-factory] rc* symlinks and systemd

Hi,

openSUSE has a packing policy of requiring rc* symlinks for each
init script. So for e.g. /etc/init.d/foo there must be a symlink
/usb/sbin/rcfoo → /etc/init.d/foo. There is an rpmlint check for this
policy (suse-missing-rclink).

···························+±

And it was accepted, none refused.


Cheers / Saludos,

Carlos E. R.
(from 13.1 x86_64 “Bottle” at Telcontar)

I was just want to clear things up :wink:

The rc has a tab completion too and as what ludwig said all init scripts in /etc/init.d should have an rc which is just a symlink from /etc/init.d

A good example of this is the openssh package.

# rpm -ql openssh
/etc/init.d/sshd
/etc/pam.d/sshd
/etc/slp.reg.d
/etc/slp.reg.d/ssh.reg
/etc/ssh
/etc/ssh/moduli
/etc/ssh/ssh_config
/etc/ssh/sshd_config
/etc/sysconfig/SuSEfirewall2.d/services/sshd
/usr/bin/scp
/usr/bin/sftp
/usr/bin/slogin
/usr/bin/ssh
/usr/bin/ssh-add
/usr/bin/ssh-agent
/usr/bin/ssh-copy-id
/usr/bin/ssh-keyconverter
/usr/bin/ssh-keygen
/usr/bin/ssh-keyscan
/usr/lib/ssh
/usr/lib/ssh/sftp-server
/usr/lib/ssh/ssh-askpass
/usr/lib/ssh/ssh-keysign
/usr/lib/ssh/ssh-pkcs11-helper
/usr/lib/systemd/system/sshd.service
/usr/sbin/rcsshd
/usr/sbin/sshd
/usr/sbin/sshd-gen-keys-start
/usr/share/doc/packages/openssh
/usr/share/doc/packages/openssh/CREDITS
/usr/share/doc/packages/openssh/ChangeLog
/usr/share/doc/packages/openssh/LICENCE
/usr/share/doc/packages/openssh/OVERVIEW
/usr/share/doc/packages/openssh/README
/usr/share/doc/packages/openssh/README.SuSE
/usr/share/doc/packages/openssh/README.kerberos
/usr/share/doc/packages/openssh/TODO
/usr/share/man/man1/scp.1.gz
/usr/share/man/man1/sftp.1.gz
/usr/share/man/man1/slogin.1.gz
/usr/share/man/man1/ssh-add.1.gz
/usr/share/man/man1/ssh-agent.1.gz
/usr/share/man/man1/ssh-copy-id.1.gz
/usr/share/man/man1/ssh-keyconverter.1.gz
/usr/share/man/man1/ssh-keygen.1.gz
/usr/share/man/man1/ssh-keyscan.1.gz
/usr/share/man/man1/ssh.1.gz
/usr/share/man/man5/moduli.5.gz
/usr/share/man/man5/ssh_config.5.gz
/usr/share/man/man5/sshd_config.5.gz
/usr/share/man/man8/sftp-server.8.gz
/usr/share/man/man8/ssh-keysign.8.gz
/usr/share/man/man8/ssh-pkcs11-helper.8.gz
/usr/share/man/man8/sshd.8.gz
/var/adm/fillup-templates/sysconfig.ssh
/var/lib/sshd

As you can see there are two start-up scripts one in /etc/init.d/ssh and /usr/lib/systemd/system/sshd.service

And if you run

file /usr/sbin/rcsshd 
/usr/sbin/rcsshd: symbolic link to `/etc/init.d/sshd'

You will see that rcsshd points to /usr/sbin/sshd

head /etc/init.d/sshd
#! /bin/sh
# Copyright (c) 1995-2000 SuSE GmbH Nuernberg, Germany.
#
# Author: Jiri Smid <feedback@suse.de>
#
# /etc/init.d/sshd
#
#   and symbolic its link
#
# /usr/sbin/rcsshd

So if you have a package that do not have a startup script in /etc/init.d and you have it in /usr/lib/systemd or /etc/systemd then it is not required for you to create an rc ;), which will build just fine either locally or on the OBS server itself.

Some checking :slight_smile:

find /sbin -type l -name 'rc*' -printf '%p points to %l
'