Geen SSH connectie mogelijk na reboot

[WoBBeL]

Ik heb een raar probleem met mijn Ubuntu server 12.10. Tijdens de installatie heb ik openssh-server geinstalleerd en dit werkte tot gister zonder problemen. Na installatie van sickbeard, couchpotato, sabnzbd en git heb ik ineens een raar probleem, na een reboot van de server kan ik niet meer verbinden via SSH en krijg ik de foutmelding "Server Unexpectedly closed network connection" (met PuTTY maar ook met een app op m'n telefoon).

Als ik vervolgens "sudo service ssh start" doe krijg ik de melding dat SSH wel loopt. Als ik deze service stop en weer opnieuw start dan werkt m'n SSH verbinding weer zonder problemen tot de volgende reboot erg vervelend want het gebakje hangt in de meterkast zonder monitor

[ Voor 5% gewijzigd door WoBBeL op 10-03-2013 17:57 ]

[Verwijderd]

De vraag is of SSH écht wel draaide. Contoleer zelf of er een sshd proces draait, en vertrouw niet blind op wat "service ssh status" of "service ssh start" meldt. Het kan heel goed zijn dat die in eerste instantie kijken naar de aanwezigheid van een pidfile of een lockfile, en dat ze daarom melden dat de SSH daemon al draaide. Dit zou een gevolg kunnen zijn van niet goed opgeruimde files.

Ga dus even na of er echt wel iets draait en waarop die melding wordt gebaseerd.

[WoBBeL]

Als ik ps -A | grep ssh doe krijg ik het volgende:

951 ? 00:00:00 sshd
Bij ps aux | grep ssh

root 951 0.0 0.0 49968 2840 ? Ss 18:06 0:00 /usr/sbin/sshd -D

Hij zou dus gewoon moeten draaien? (ik ben een antiheld qua linux kennis )

[ Voor 22% gewijzigd door WoBBeL op 10-03-2013 18:16 ]

[Wolfboy]

Dit klinkt als een ssh server die draait maar op een of andere reden (bijvoorbeeld volle disk) niet goed kan werken.

Kijk eens in de logs van je server, i.e. /var/log/auth.log en /var/log/syslog
En controleer ook even of je voldoende schijfruimte hebt, dat wil nog weleens dit soort vreemde problemen veroorzaken

[WoBBeL]

Wolfboy schreef op zondag 10 maart 2013 @ 19:12:
Dit klinkt als een ssh server die draait maar op een of andere reden (bijvoorbeeld volle disk) niet goed kan werken.

Kijk eens in de logs van je server, i.e. /var/log/auth.log en /var/log/syslog
En controleer ook even of je voldoende schijfruimte hebt, dat wil nog weleens dit soort vreemde problemen veroorzaken

Schijfruimte kan het niet zijn, nog +400GB vrij. Het volgende staat in de log auth.log (heb log even leeg gegooid en gereboot)

Mar 10 20:36:59 server sshd[743]: Received signal 15; terminating.
Mar 10 20:36:59 server sshd[893]: Server listening on 0.0.0.0 port 22.
Mar 10 20:36:59 server sshd[893]: Server listening on :: port 22.
Mar 10 20:36:59 server sudo: root : TTY=unknown ; PWD=/home/roy/.sickbeard ; USER=roy ; COMMAND=/usr/bin/nohup python /home/roy/.sickbeard/SickBeard.py -q
Mar 10 20:36:59 server sudo: pam_unix(sudo:session): session opened for user roy by (uid=0)
Mar 10 20:37:22 server login[1321]: pam_unix(login:session): session opened for user roy by (uid=0)
Mar 10 20:38:03 server sshd[1662]: fatal: Missing privilege separation directory: /var/run/sshd
Mar 10 20:39:47 server sshd[1668]: fatal: Missing privilege separation directory: /var/run/sshd
Mar 10 20:39:52 server sshd[1669]: fatal: Missing privilege separation directory: /var/run/sshd
Mar 10 20:39:55 server sudo: roy : TTY=tty1 ; PWD=/home/roy ; USER=root ; COMMAND=/usr/sbin/service ssh stop
Mar 10 20:39:55 server sudo: pam_unix(sudo:session): session opened for user root by (uid=0)
Mar 10 20:39:55 server sshd[893]: Received signal 15; terminating.
Mar 10 20:39:55 server sudo: pam_unix(sudo:session): session closed for user root
Mar 10 20:39:57 server sudo: roy : TTY=tty1 ; PWD=/home/roy ; USER=root ; COMMAND=/usr/sbin/service ssh start
Mar 10 20:39:57 server sudo: pam_unix(sudo:session): session opened for user root by (uid=0)
Mar 10 20:39:57 server sudo: pam_unix(sudo:session): session closed for user root
Mar 10 20:39:57 server sshd[1680]: Server listening on 0.0.0.0 port 22.
Mar 10 20:39:57 server sshd[1680]: Server listening on :: port 22.
Mar 10 20:40:02 server sshd[1681]: Accepted password for roy from 10.0.0.12 port 59340 ssh2
Mar 10 20:40:02 server sshd[1681]: pam_unix(sshd:session): session opened for user roy by (uid=0)
Mar 10 20:40:02 server sshd[1807]: subsystem request for sftp by user roy

Wel vreemd (ik zie het nu ook tijdens het opstarten) dat SSH eerst geterminated wordt, en daarna opgestart
Ik zie tijdens het booten dit:
* Stopping openSSH server [OK]
* Starting openSSH server [OK]

In de syslog vind ik niks met "SSH" erin, zou ik daar op iets anders specifieks moeten zoeken?

[thunder7]

Ik heb een werkende sshd, geen melding 'Mar 10 20:38:03 server sshd[1662]: fatal: Missing privilege separation directory: /var/run/sshd' en wel een directory /var/run/sshd:

drwxr-xr-x 2 root root 40 Mar 10 18:52 sshd

is die directory er op jouw server? Zonee, hoe gaat het als je die wel aanmaakt met de juiste eigenaar en permissies? Als er 'fatal' in logfiles staat, dan loont het over het algemeen wel de moeite om even goed te kijken!

[ Voor 12% gewijzigd door thunder7 op 10-03-2013 21:28 ]

[WoBBeL]

thunder7 schreef op zondag 10 maart 2013 @ 21:27:
Ik heb een werkende sshd, geen melding 'Mar 10 20:38:03 server sshd\[1662]: fatal: Missing privilege separation directory: /var/run/sshd' en wel een directory /var/run/sshd:

drwxr-xr-x 2 root root 40 Mar 10 18:52 sshd

is die directory er op jouw server? Zonee, hoe gaat het als je die wel aanmaakt met de juiste eigenaar en permissies? Als er 'fatal' in logfiles staat, dan loont het over het algemeen wel de moeite om even goed te kijken!

Ah, dat was wel heel erg stupide om over het hoofd te zien ik ga dit meteen checken

[Wolfboy]

Dit lijkt me wel een probleem ja

Mar 10 20:39:52 server sshd[1669]: fatal: Missing privilege separation directory: /var/run/sshd

Volgens mij kan je het zo fixen:

mkdir -p /var/run/sshd
chown root:root /var/run/sshd
chmod 0755 /var/run/sshd

[Verwijderd]

install -d -m 0755 -o root -g root /var/run/sshd

Voor degenen die alles gewoon in één keer willen doen

[Wolfboy]

offtopic:
Is install gestandaardiseerd bij elke unix/linux distro tegenwoordig? Of zijn de flags nog steeds verschillend per OS?

edit:
De versie onder OS X is iig anders als de Ubuntu versie, maar de belangrijkste flags zijn iig hetzelfde. Het werkt dus iig voor n=2
Nu de vraag of het bij obscure (HP-UX, AIX, etc..) unices ook gaat werken

[ Voor 47% gewijzigd door Wolfboy op 11-03-2013 14:14 ]

[Rainmaker]

Hmm. Dat verklaart het, maar niet volledig. Dit omdat de SSH daemon anders ook niet zou werken na een restart van de services.

Ik gok dat de TS /var/ of /var/run op een filesystem heeft staan, anders dan het root fs. Hierdoor is die dir niet bereikbaar tijdens het booten, maar wel na het volledig opstarten.

Slechte init prioriteit?

probeer eens:

code:

sudo apt-get --reinstall openssh-server
sudo update-rc.d ssh disable
sudo update-rc.d ssh enable

[WoBBeL]

Wolfboy schreef op maandag 11 maart 2013 @ 13:16:
Dit lijkt me wel een probleem ja

Mar 10 20:39:52 server sshd[1669]: fatal: Missing privilege separation directory: /var/run/sshd

Volgens mij kan je het zo fixen:

mkdir -p /var/run/sshd
chown root:root /var/run/sshd
chmod 0755 /var/run/sshd

Verwijderd schreef op maandag 11 maart 2013 @ 13:22:

install -d -m 0755 -o root -g root /var/run/sshd

Voor degenen die alles gewoon in één keer willen doen

Dit werkt allebei helaas niet.

Rainmaker schreef op maandag 11 maart 2013 @ 14:13:
Hmm. Dat verklaart het, maar niet volledig. Dit omdat de SSH daemon anders ook niet zou werken na een restart van de services.

Ik gok dat de TS /var/ of /var/run op een filesystem heeft staan, anders dan het root fs. Hierdoor is die dir niet bereikbaar tijdens het booten, maar wel na het volledig opstarten.

Slechte init prioriteit?

probeer eens:

code:

sudo apt-get [b]install[/b] --reinstall openssh-server
sudo update-rc.d ssh disable
sudo update-rc.d ssh enable

1e commando klopte volgens mij niet helemaal, bij het 2e commando krijg ik
"update-rc.d: /etc/init.d/ssh: file does not exist" dat is toch vreemd, anders zou er toch geen proces mogen zijn bij het (opnieuw) opstarten?

Filesystem is helemaal standaard. 1x500 GB schijf die door de ubuntu install gewoon standaard is gemaakt voor de volledige 500GB

[Rainmaker]

Nee, ik bedoelde echt reinstall.

Deze kan ook:

code:

sudo aptitude reinstall openssh-server

Op Ubuntu blijkt het init script blijkbaar geen "ssh" te heten, zoals op Debian. Probeer even iets van:

code:

sudo update-rc.d sshd disable
sudo update-rc.d sshd enable
sudo update-rc.d open-ssh disable
sudo update-rc.d open-ssh enable
sudo update-rc.d openssh disable
sudo update-rc.d openssh enable

De juiste naam kun je waarschijnlijk vinden met

code:

ls /etc/init.d/*ssh*

[Kaspers]

xost schreef op maandag 11 maart 2013 @ 14:33:
Dit werkt allebei helaas niet.

Waarom kun je die dir niet aanmaken eigenlijk?

[WoBBeL]

Kaspers schreef op maandag 11 maart 2013 @ 14:55:
[...]


Waarom kun je die dir niet aanmaken eigenlijk?

Dir is wel aangemaakt, permissies kloppen na de chown / chmod maar na een reboot draait SSH nog niet. Ik zal even in de log kijken, was onder werktijd heel even thuis om het te testen

Rainmaker schreef op maandag 11 maart 2013 @ 14:42:
Nee, ik bedoelde echt reinstall.

Deze kan ook:

code:

sudo aptitude reinstall openssh-server

Op Ubuntu blijkt het init script blijkbaar geen "ssh" te heten, zoals op Debian. Probeer even iets van:

code:

sudo update-rc.d sshd disable
sudo update-rc.d sshd enable
sudo update-rc.d open-ssh disable
sudo update-rc.d open-ssh enable
sudo update-rc.d openssh disable
sudo update-rc.d openssh enable

De juiste naam kun je waarschijnlijk vinden met

code:

ls /etc/init.d/*ssh*

openssh in ieder geval ook niet, en sshd ook niet ik ga eens kijken vanavond. jullei horen van mij

[WoBBeL]

Ik heb de oorzaak gevonden, maar nog niet opgelost. Ik heb Ubuntu server 12.10 opnieuw geinstalleerd, en na de installatie heb ik de volgende commando's uitgevoerd om Couchpotato v2 te installeren (vanuit een kale Ubuntu server 12.10 met openssh en samba vanuit de installatie, ik heb dus geen enkel ander commando ingeklopt na deze schone installatie!!):

sudo apt-get install git-core python python-cheetah
cd ~
git clone git://github.com/RuudBurger/CouchPotatoServer.git .couchpotato
cd ~/.couchpotato/init
sudo cp ubuntu /etc/init.d/couchpotato
sudo nano /etc/init.d/couchpotato [Zie config hieronder]
sudo chmod +x /etc/init.d/couchpotato
sudo update-rc.d couchpotato defaults

Als ik daarna reboot start openssh-server niet meer automatisch op!

Config /etc/init.d/couchpotato

code:

#! /bin/sh

### BEGIN INIT INFO
# Provides:          couchpotato
# Required-Start:    $local_fs $network $remote_fs
# Required-Stop:     $local_fs $network $remote_fs
# Should-Start:      $NetworkManager
# Should-Stop:       $NetworkManager
# Default-Start:     2 3 4 5
# Default-Stop:      0 1 6
# Short-Description: starts instance of CouchPotato
# Description:       starts instance of CouchPotato using start-stop-daemon
### END INIT INFO

############### EDIT ME ##################
# path to app
APP_PATH=/home/roy/.couchpotato/

# user
RUN_AS=roy
# path to python bin
DAEMON=/usr/bin/python

# Path to store PID file
PID_FILE=/var/run/couchpotato.pid
PID_PATH=$(dirname $PID_FILE)

# script name
NAME=couchpotato

# app name
DESC=CouchPotato

# startup args
DAEMON_OPTS=" CouchPotato.py --daemon --pid_file=${PID_FILE}"

############### END EDIT ME ##################

test -x $DAEMON || exit 0

set -e

case "$1" in
  start)
        echo "Starting $DESC"
        rm -rf $PID_PATH || return 1
        install -d --mode=0755 -o $RUN_AS $PID_PATH || return 1
        start-stop-daemon -d $APP_PATH -c $RUN_AS --start --background --pidfile $PID_FILE --exec $DAEMON -- $DAEMON_OPTS
        ;;
  stop)
        echo "Stopping $DESC"
        start-stop-daemon --stop --pidfile $PID_FILE --retry 15
        ;;

  restart|force-reload)
        echo "Restarting $DESC"
        start-stop-daemon --stop --pidfile $PID_FILE --retry 15
        start-stop-daemon -d $APP_PATH -c $RUN_AS --start --background --pidfile $PID_FILE --exec $DAEMON -- $DAEMON_OPTS
        ;;
  *)
        N=/etc/init.d/$NAME
        echo "Usage: $N {start|stop|restart|force-reload}" >&2
        exit 1
        ;;
esac

exit 0

Na het uitvoeren van "sudo update-rc.d couchpotato remove" start openssh-server weer netjes op.

[ Voor 3% gewijzigd door WoBBeL op 11-03-2013 17:50 ]

[Hero of Time]

Vind je 't gek? Als CP start, gebeurt er dit:

code:

tart)
        echo "Starting $DESC"
        rm -rf $PID_PATH || return 1

Ehm, hoe verstandig is het om /var/run te wissen als er al daemons draaien? Zouden die dat fijn vinden? Denk 't niet. Daarbij wordt de owner ook nog eens roy, niet root. Bijkomend punt is bij mij, op Debian, is /var/run een symlink naar /run. Kan bij Ubuntu ook zo zijn, dus dan is de pid file er nog wel, maar de symlink is weg en dan kan de daemon z'n pid file ook niet meer vinden, terwijl die er nog wel is (in /run).

[Verwijderd]

Sja, wat kun je hier nu nog voor zinnigs op zeggen?

[Hero of Time]

Niets, dus waarom je reageert is mij een raadsel. Enige wat 't aantoont is dat de devs van couchpotato, of wie het script dan ook heeft geschreven, niet bijster intelligent is als het al zo stond. Mocht de TS het hebben aangepast naar /var/run, tja, onwetendheid en onervaren? Dat laatste heeft-ie al aangegeven

[Verwijderd]

Het blijkt dat het ubuntu-script dit als standaardconfiguratie heeft (net gecontroleerd):

code:

# Path to store PID file
PID_FILE=/var/run/couchpotato.pid
PID_PATH=$(dirname $PID_FILE)

Ik houd het er dus op dat de ontwikkelaar die dat bedacht heeft een idioot is. Ze hebben wel een standaard gebruikersnaam die duidelijk moet worden bewerkt:

code:

# user
RUN_AS=YOUR_USERNAME_HERE

Maar waarom ze een standaard directory compleet verwijderen zonder meldingen en vervolgens deze opnieuw aanmaken, is mij een raadsel. Ik neem het de topicstarter dan ook niet kwalijk dat dit fout gaat. Ik neem het zulke developers wel heel erg kwalijk.

[WoBBeL]

Hero of Time schreef op maandag 11 maart 2013 @ 22:22:
Niets, dus waarom je reageert is mij een raadsel. Enige wat 't aantoont is dat de devs van couchpotato, of wie het script dan ook heeft geschreven, niet bijster intelligent is als het al zo stond. Mocht de TS het hebben aangepast naar /var/run, tja, onwetendheid en onervaren? Dat laatste heeft-ie al aangegeven

Ik heb alleen de username gewijzigd ik moet hem dus maar even aanpassen en zorgen dat niet heel /var/run/ leeggegooid wordt toch? Alleen een eventuele pid file van couchpotato wegduvelen

Zo??

code:

#! /bin/sh

### BEGIN INIT INFO
# Provides:          couchpotato
# Required-Start:    $local_fs $network $remote_fs
# Required-Stop:     $local_fs $network $remote_fs
# Should-Start:      $NetworkManager
# Should-Stop:       $NetworkManager
# Default-Start:     2 3 4 5
# Default-Stop:      0 1 6
# Short-Description: starts instance of CouchPotato
# Description:       starts instance of CouchPotato using start-stop-daemon
### END INIT INFO

############### EDIT ME ##################
# path to app
APP_PATH=/home/roy/.couchpotato/

# user
RUN_AS=roy
# path to python bin
DAEMON=/usr/bin/python

# Path to store PID file
PID_FILE=/var/run/couchpotato.pid
PID_PATH=$(dirname $PID_FILE)

# script name
NAME=couchpotato

# app name
DESC=CouchPotato

# startup args
DAEMON_OPTS=" CouchPotato.py --daemon --pid_file=${PID_FILE}"

############### END EDIT ME ##################

test -x $DAEMON || exit 0

set -e

case "$1" in
  start)
        echo "Starting $DESC"
        rm -rf $PID_FILE || return 1
        install -d --mode=0755 -o $RUN_AS $PID_PATH || return 1
        start-stop-daemon -d $APP_PATH -c $RUN_AS --start --background --pidfile $PID_FILE --exec $DAEMON -- $DAEMON_OPTS
        ;;
  stop)
        echo "Stopping $DESC"
        start-stop-daemon --stop --pidfile $PID_FILE --retry 15
        ;;

  restart|force-reload)
        echo "Restarting $DESC"
        start-stop-daemon --stop --pidfile $PID_FILE --retry 15
        start-stop-daemon -d $APP_PATH -c $RUN_AS --start --background --pidfile $PID_FILE --exec $DAEMON -- $DAEMON_OPTS
        ;;
  *)
        N=/etc/init.d/$NAME
        echo "Usage: $N {start|stop|restart|force-reload}" >&2
        exit 1
        ;;
esac

exit 0

Verwijderd schreef op maandag 11 maart 2013 @ 23:16:
Het blijkt dat het ubuntu-script dit als standaardconfiguratie heeft (net gecontroleerd):

code:

# Path to store PID file
PID_FILE=/var/run/couchpotato.pid
PID_PATH=$(dirname $PID_FILE)

Ik houd het er dus op dat de ontwikkelaar die dat bedacht heeft een idioot is. Ze hebben wel een standaard gebruikersnaam die duidelijk moet worden bewerkt:

code:

# user
RUN_AS=YOUR_USERNAME_HERE

Maar waarom ze een standaard directory compleet verwijderen zonder meldingen en vervolgens deze opnieuw aanmaken, is mij een raadsel. Ik neem het de topicstarter dan ook niet kwalijk dat dit fout gaat. Ik neem het zulke developers wel heel erg kwalijk.

Misschien kan je mij het wel een beetje kwalijk nemen, ik ben immers zo achterlijk om gewoon dit script meteen uit te voeren bij het opstarten. Aan de andere kant, als ik zulke oplossingen voor mijn websites ging schrijven dan was ik ik denk ik snel klaar

[ Voor 79% gewijzigd door WoBBeL op 12-03-2013 08:01 ]

[Rainmaker]

Nog 1 ding; ik zou het "start" stanza even aanpassen naar:

code:

 start)
        echo "Starting $DESC"
        rm -rf $PID_FILE || return 1
        touch $PID_FILE
        chown $RUNAS $PID_FILE
        start-stop-daemon -d $APP_PATH -c $RUN_AS --start --background --pidfile $PID_FILE --exec $DAEMON -- $DAEMON_OPTS
        ;;

Dus ook die "install" regel eruit. Dit om te voorkomen dat /var/run ge'chown'ed wordt naar een verkeerde user.

Verder; even netjes een bug report indienen.

[ Voor 6% gewijzigd door Rainmaker op 12-03-2013 10:36 . Reden: I was wrong O-) Er moet een pidfile gemaakt worden van de RUNAS user. ]

[Wolfboy]

Het is zo te zien bij een vrij recente wijziging gesloopt:
https://github.com/RuudBu...4a99a1b0fad43#init/ubuntu

Ik heb geen idee wat de rationale van deze wijziging was maar dit is wel vrij stom ja...
De bug is hierbij gereport iig: https://github.com/RuudBurger/CouchPotatoServer/issues/1488

@TS: misschien nog een idee om couchpotato (e.d.) gewoon te starten/beheren via supervisord. Een stuk veiliger imho

[edit]En het is gefixt
https://github.com/RuudBu...7279f9a4c81e68f37806e9caf

[ Voor 11% gewijzigd door Wolfboy op 12-03-2013 09:48 ]

[Hero of Time]

Ik had het, buiten de fix in GIT, anders opgelost. Namelijk een map maken in /var/run waar het PID bestand in wordt gezet. Wordt vaker gedaan.

code:

PID_FILE=/var/run/couchpotato/couchpotato.pid

Dan is er niets aan de hand.

Ik vraag mij dan ook af of dit nog steeds goed gaat, en niet de rechten alsnog om zeep helpt:

code:

+        install -d --mode=0755 -o $RUN_AS $PID_PATH || return 1

Dat is de 'fix' die ze hebben doorgevoerd. Geen nette als je 't mij vraagt (ze doen nu ook $PID_FILE, ipv $PID_PATH, maar dat terzijde). Doe ik liever apart mapje, weet je zeker dat er niets stuk gaat in /var/run of /run.

[WoBBeL]

Rainmaker schreef op dinsdag 12 maart 2013 @ 09:38:
Nog 1 ding; ik zou het "start" stanza even aanpassen naar:

code:

 start)
        echo "Starting $DESC"
        rm -rf $PID_FILE || return 1
        touch $PID_FILE
        chown $RUNAS $PID_FILE
        start-stop-daemon -d $APP_PATH -c $RUN_AS --start --background --pidfile $PID_FILE --exec $DAEMON -- $DAEMON_OPTS
        ;;

Dus ook die "install" regel eruit. Dit om te voorkomen dat /var/run ge'chown'ed wordt naar een verkeerde user.

Verder; even netjes een bug report indienen.

ipv $RUNAS even $RUN_AS gedaan en het werkt bedankt allen voor het meedenken