Jump to content

SSH connection refused nach update 62.0 -> 62.1

mikeboss

By mikeboss
in German

 Share

Recommended Posts

mikeboss Newbie

mikeboss

Posted
Posted

auf Raspberry Pi: nach update von 62.0 -> 62.1 kann man sich nicht mehr mittels SSH auf die PBX verbinden.

sh-3.2# ssh xxx.xx.xx.xxx

ssh: connect to host xxx.xx.xx.xxx port 22: Connection refused

habe das ganze zwei mal durchgespielt und beide male ging SSH nach dem update nicht mehr.

/etc/init.d/pbx stop schafft keine abhilfe.

keine ahnung ob 62.1 noch eine beta ist, habe die update URL einfach mal durch rumprobieren erraten...

 

schoene gruesse aus der schweiz,

michael

Link to comment
Share on other sites
mikeboss Newbie

mikeboss

Posted
  • Author
Posted

hm. kann mir auch nicht so recht vorstellen was da vor sich geht. aber: Raspbian image frisch auf die microSD karte gespielt, Vodia PBX (62.0) frisch gemaess anleitung auf dem Raspberry Pi installiert. update auf 62.1 via WEB GUI durchgefuehrt und unmittelbar danach ist schluss mit SSH. nicht mal ein reboot, nur SSH ausloggen und dann versuchen sich wieder einzuloggen mittels SSH -> geht nicht mehr. da draengt sich dann m.E. schon ein zusammenhang mit dem update der PBX auf...

Link to comment
Share on other sites
mikeboss Newbie

mikeboss

Posted
  • Author
Posted

also:

Raspbian (2018-11-13-raspbian-stretch-lite.img) auf die microSD karte spielen.
auf /boot/ eine leere datei "ssh" angelegt, damit SSH gestartet wird.
microSD karte im Raspberry Pi booten, filesystem wird erweitert, reboot automatisch.
login via SSH pi@raspberry
wget http://portal.vodia.com/downloads/pbx/install-mini3.sh
chmod a+x install-mini3.sh
sudo ./install-mini3.sh

login mittels webbrowser auf http://raspberry loginuser "admin"
EULA abnicken
dann mittels web GUI und http://portal.vodia.com/downloads/pbx/version-62.1.xml
auf 62.1 updaten -> OK

danach reboot oder "/etc/init.d/pbx restart" und SSH login wird von da an abgelehnt.

 

in der datei "/lib/systemd/system/ssh.service " wurde

die zeile

"ExecStartPre=/usr/sbin/sshd -t"

ohne mein zutun zu

"ExecStartPre=/bin/mkdir /var/run/sshd"

daran scheint es nicht zu liegen, zumindest nicht alleine.

/etc/ssh/sshd_config wurde offenbar durch das update nicht angefasst.

 

BTW: eine zweite PBX zum testen (virtualisiert auf ESXi, debian stretch 32Bit, release 62.0) liess sich fehlerfrei auf release 62.1 updaten und SSH funktioniert auch hinterher noch einwandfrei.

Link to comment
Share on other sites
Vodia PBX Grand Master

Vodia PBX

Posted
Posted

Das "ExecStartPre=/bin/mkdir /var/run/sshd kommt" von uns, und wir machen auch das "PermitRootLogin yes". Das IOP muss die Datei ändern wenn man vom Web-Interface aus SSH einschaltet. Ohne die Änderungen ist es uns auch nicht gelungen SSH einzuschalten. Vielleicht sollten wir das ganzer rumdrehen und mal versuchen raus zu finden was denn in den beiden Dateien richtigerweise stehen sollte?!

Link to comment
Share on other sites
mikeboss Newbie

mikeboss

Posted
  • Author
Posted

von einem frisch aufgespielten Raspbian Stretch (2018-11-13-raspbian-stretch-lite.img)

/lib/systemd/system/ssh.service

[Unit]
Description=OpenBSD Secure Shell server
After=network.target auditd.service
ConditionPathExists=!/etc/ssh/sshd_not_to_be_run

[Service]
EnvironmentFile=-/etc/default/ssh
ExecStartPre=/usr/sbin/sshd -t
ExecStart=/usr/sbin/sshd -D $SSHD_OPTS
ExecReload=/usr/sbin/sshd -t
ExecReload=/bin/kill -HUP $MAINPID
KillMode=process
Restart=on-failure
RestartPreventExitStatus=255
Type=notify

[Install]
WantedBy=multi-user.target
Alias=sshd.service
 

/etc/ssh/sshd_config wobei ich da eh ueblicherweise "PermitRootLogin yes" einstelle

 

#    $OpenBSD: sshd_config,v 1.100 2016/08/15 12:32:04 naddy Exp $

# This is the sshd server system-wide configuration file.  See
# sshd_config(5) for more information.

# This sshd was compiled with PATH=/usr/bin:/bin:/usr/sbin:/sbin

# The strategy used for options in the default sshd_config shipped with
# OpenSSH is to specify options with their default value where
# possible, but leave them commented.  Uncommented options override the
# default value.

#Port 22
#AddressFamily any
#ListenAddress 0.0.0.0
#ListenAddress ::

#HostKey /etc/ssh/ssh_host_rsa_key
#HostKey /etc/ssh/ssh_host_ecdsa_key
#HostKey /etc/ssh/ssh_host_ed25519_key

# Ciphers and keying
#RekeyLimit default none

# Logging
#SyslogFacility AUTH
#LogLevel INFO

# Authentication:

#LoginGraceTime 2m
#PermitRootLogin prohibit-password
#StrictModes yes
#MaxAuthTries 6
#MaxSessions 10

#PubkeyAuthentication yes

# Expect .ssh/authorized_keys2 to be disregarded by default in future.
#AuthorizedKeysFile    .ssh/authorized_keys .ssh/authorized_keys2

#AuthorizedPrincipalsFile none

#AuthorizedKeysCommand none
#AuthorizedKeysCommandUser nobody

# For this to work you will also need host keys in /etc/ssh/ssh_known_hosts
#HostbasedAuthentication no
# Change to yes if you don't trust ~/.ssh/known_hosts for
# HostbasedAuthentication
#IgnoreUserKnownHosts no
# Don't read the user's ~/.rhosts and ~/.shosts files
#IgnoreRhosts yes

# To disable tunneled clear text passwords, change to no here!
#PasswordAuthentication yes
#PermitEmptyPasswords no

# Change to yes to enable challenge-response passwords (beware issues with
# some PAM modules and threads)
ChallengeResponseAuthentication no

# Kerberos options
#KerberosAuthentication no
#KerberosOrLocalPasswd yes
#KerberosTicketCleanup yes
#KerberosGetAFSToken no

# GSSAPI options
#GSSAPIAuthentication no
#GSSAPICleanupCredentials yes
#GSSAPIStrictAcceptorCheck yes
#GSSAPIKeyExchange no

# Set this to 'yes' to enable PAM authentication, account processing,
# and session processing. If this is enabled, PAM authentication will
# be allowed through the ChallengeResponseAuthentication and
# PasswordAuthentication.  Depending on your PAM configuration,
# PAM authentication via ChallengeResponseAuthentication may bypass
# the setting of "PermitRootLogin without-password".
# If you just want the PAM account and session checks to run without
# PAM authentication, then enable this but set PasswordAuthentication
# and ChallengeResponseAuthentication to 'no'.
UsePAM yes

#AllowAgentForwarding yes
#AllowTcpForwarding yes
#GatewayPorts no
X11Forwarding yes
#X11DisplayOffset 10
#X11UseLocalhost yes
#PermitTTY yes
PrintMotd no
#PrintLastLog yes
#TCPKeepAlive yes
#UseLogin no
#UsePrivilegeSeparation sandbox
#PermitUserEnvironment no
#Compression delayed
#ClientAliveInterval 0
#ClientAliveCountMax 3
#UseDNS no
#PidFile /var/run/sshd.pid
#MaxStartups 10:30:100
#PermitTunnel no
#ChrootDirectory none
#VersionAddendum none

# no default banner path
#Banner none

# Allow client to pass locale environment variables
AcceptEnv LANG LC_*

# override default of no subsystems
Subsystem    sftp    /usr/lib/openssh/sftp-server

# Example of overriding settings on a per-user basis
#Match User anoncvs
#    X11Forwarding no
#    AllowTcpForwarding no
#    PermitTTY no
#    ForceCommand cvs server
 

 

 

 

 

Link to comment
Share on other sites
  • 2 weeks later...
mikeboss Newbie

mikeboss

Posted
  • Author
Posted
10 minutes ago, Support said:

Does it say this on your Admin > System > Status page:

Software-Version: 62.1 (Vodia mini PBX (Debian))

Build Date: Apr 11 2019 17:13:20

This worked for us. Just give the device some 10-20 minutes it works after that.

yes, as stated above: 62.1 (Build Date: Apr 11 2019 17:13:20)

Link to comment
Share on other sites
mikeboss Newbie

mikeboss

Posted
  • Author
Posted

switched on "SSH access" in the web GUI and rebooted the Raspberry Pi. now I can see on the Raspberry's screen:

FAILED to start OpenBSD Secure Shell server.

I mean, it's no biggie for me. since I do have a screen and a keyboard attached to the system, I can install dropbear (which works with 62.1). but for others this might be a problem...

Link to comment
Share on other sites
Vodia PBX Grand Master

Vodia PBX

Posted
Posted

Well, is there a difference on that we should have for IOP (which is Rasperian) and a Raspberry Pi 3 Model B+? Originally we did not really change the SSH files, just patch them - however the problem was obviously that the OS upgrade wiped out SSH and now we had to write the complete file to get this working. Maybe we have to do this depending on the SSH version? IMHO it is a big deal, because IOP users should have shell access when they enable it from the GUI. Actually the script even restarts sshd, so it would not even require a reboot.

Link to comment
Share on other sites

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.
Note: Your post will require moderator approval before it will be visible.

Guest
Reply to this topic...

×   Pasted as rich text.   Paste as plain text instead

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.

×
 Share
Go to topic listing


×
×
  • Create New...