On Saturday 08 September 2007 16:40:34 Grant wrote:
I just upgraded ssh and when I try to restart I get:
* Stopping sshd ... [ !! ]
I don't see anything about it in '/var/log/sshd/current'. How can I
figure out what is wrong? I'm a little nervous because I don't want
to shut myself out of
On Tue, 11 Sep 2007 12:30:56 -0700
Grant [EMAIL PROTECTED] wrote:
How does my host get root access like that?
- Grant
Auto-logged in console, perhaps? Or access to the filesystem on a
locally administered fileserver or something?
--
[EMAIL PROTECTED] mailing list
On Mon, 10 Sep 2007 13:14:20 -0700
Grant [EMAIL PROTECTED] wrote:
Thank you but doesn't it look like there must be a problem that is
preventing my sshd from starting? Won't '/usr/bin/sshd -p 3' just
fail, or is that more likely to work than '/etc/init.d/sshd start'?
It seems to me that the
On Mon, 10 Sep 2007 13:48:12 -0700
Grant [EMAIL PROTECTED] wrote:
What about just having them reboot and start my manual daemon? Would
that accomplish the same thing?
That would probably work too, but I don't think rebooting is likely to
help. At the very best it's an additional waiting
Thank you but doesn't it look like there must be a problem that is
preventing my sshd from starting? Won't '/usr/bin/sshd -p 3' just
fail, or is that more likely to work than '/etc/init.d/sshd start'?
It seems to me that the problem is probably the initscript is confused,
and not that the
Hi,
On Tue, 11 Sep 2007 12:30:56 -0700
Grant [EMAIL PROTECTED] wrote:
How does my host get root access like that?
Different possibilities, but hardware access in most cases means root
access (although maybe only to encrypted partitions...).
Easiest: Reboot (CTRL-ALT-DEL, no password needed),
On Tuesday 11 September 2007, Grant [EMAIL PROTECTED] wrote about 'Re:
[gentoo-user] SSH won't restart':
How does my host get root access like that?
Physical access to the box = root in many cases.
Also, if it's some vserver type setup, root on the host can get root access
on the guest machines
How does my host get root access like that?
Physical access to the box = root in many cases.
Also, if it's some vserver type setup, root on the host can get root access
on the guest machines.
Ok, thanks again everyone.
- Grant
--
[EMAIL PROTECTED] mailing list
I just upgraded ssh and when I try to restart I get:
* Stopping sshd ... [ !! ]
I don't see anything about it in '/var/log/sshd/current'. How can I
figure out what is wrong? I'm a little nervous because I don't want
to shut myself out of this remote server.
I had a similar issue after
On Mon, 10 Sep 2007 09:58:53 -0700
Grant [EMAIL PROTECTED] wrote:
OK, I've got to be really careful here. I see the following processes
in 'ps -ef':
root 2988 1 0 Sep04 ?00:00:00 /usr/sbin/sshd
root 7573 2988 0 07:28 ?00:00:00 sshd: [EMAIL PROTECTED]/0
This process is the ssh daemon:
root 2988 1 0 Sep04 ?00:00:00 /usr/sbin/sshd
Two things: before killing the process with the KILL signal, I would
try killing it with TERM
kill -TERM 2988
If that doesn't work then kill the process with the KILL signal.
I would also use:
This process is the ssh daemon:
root 2988 1 0 Sep04 ?00:00:00 /usr/sbin/sshd
Two things: before killing the process with the KILL signal, I would
try killing it with TERM
kill -TERM 2988
If that doesn't work then kill the process with the KILL signal.
I would also use:
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512
Grant wrote:
Should I:
kill -9 2988 /etc/init.d/sshd start
Are you sure? :)
Sounds scary to kill sshd remotely, specially over ssh :P
That's why I usually have a telnet server up during ssh upgrade times.
- --
Arturo Buanzo Busleiman -
Yes. As a personal preference I don't usually chain commands together
when trouble shooting something, but there is technically nothing
wrong with doing so.
-Stephen
On 9/10/07, Grant [EMAIL PROTECTED] wrote:
This process is the ssh daemon:
root 2988 1 0 Sep04 ?00:00:00
Killing the ssh daemon does not effect any of the existing
connections. The ssh daemon is used to listen for new connections and
create a process to handle communications with that request. That is
why when you update configuration parameters for sshd, they do not
take effect until the next
Yes. As a personal preference I don't usually chain commands together
when trouble shooting something, but there is technically nothing
wrong with doing so.
And now I'm locked out. What do you think guys?
- Grant
This process is the ssh daemon:
root 2988 1 0 Sep04 ?
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512
Stephen Wittig wrote:
Killing the ssh daemon does not effect any of the existing
connections. The ssh daemon is used to listen for new connections and
create a process to handle communications with that request. That is
why when you update
On Mon, 10 Sep 2007 12:12:13 -0700
Grant [EMAIL PROTECTED] wrote:
Yes. As a personal preference I don't usually chain commands
together when trouble shooting something, but there is technically
nothing wrong with doing so.
And now I'm locked out. What do you think guys?
- Grant
Is
On Mon, 10 Sep 2007 13:39:35 -0500
Stephen Wittig [EMAIL PROTECTED] wrote:
That's why I usually have a telnet server up during ssh upgrade
times.
The problem with connecting to the server via telnet is that your
password can be easily intercepted - which is one of the major reasons
telnet
On Mon, 10 Sep 2007 12:23:37 -0700
Grant [EMAIL PROTECTED] wrote:
My host is pretty good about issuing commands for me. Any ideas
there?
- Grant
start sshd manually to get back in. something like '/usr/bin/sshd -p 3'
(that would listen on port 3 for ssh connections)
(absolute path is
Yes. As a personal preference I don't usually chain commands
together when trouble shooting something, but there is technically
nothing wrong with doing so.
And now I'm locked out. What do you think guys?
- Grant
Is your ssh session still open?
I wish. :) 100% locked out.
My host is pretty good about issuing commands for me. Any ideas
there?
- Grant
start sshd manually to get back in. something like '/usr/bin/sshd -p 3'
(that would listen on port 3 for ssh connections)
(absolute path is necessary for re-exec)
I still don't know what happened; here's
If there's a problem with ssh, then you're pretty much stuck with
using other remote terminal tool to fix it, else, you can simply kill
the process, delete the PID file, then /etc/init.d/sshd zap and
/etc/init.d/sshd restart, or start, anyway... (I guess your host
could easily issue this commands
If there's a problem with ssh, then you're pretty much stuck with
using other remote terminal tool to fix it, else, you can simply kill
the process, delete the PID file, then /etc/init.d/sshd zap and
/etc/init.d/sshd restart, or start, anyway... (I guess your host
could easily issue this
Hi,
On Mon, 10 Sep 2007 14:28:41 -0500
Dan Farrell [EMAIL PROTECTED] wrote:
You can always start a seperate ssh server on a different port, to test
the new server and the config files.
Then you can get in on a different port and fix it if your upgrade of
the usual ssh server gets borked.
On 9/10/07, Grant [EMAIL PROTECTED] wrote:
If there's a problem with ssh, then you're pretty much stuck with
using other remote terminal tool to fix it, else, you can simply kill
the process, delete the PID file, then /etc/init.d/sshd zap and
/etc/init.d/sshd restart, or start, anyway...
I think that there may be something significantly wrong with your box
(or configuration of sshd). I have never had a server disconnect an
active connection when killing the ssh daemon.
If there is someone that you can contact in the data center I would ask them to:
1) Backup your current
Yes, accessing the machine via telnet over an encrypted VPN connection
is a safe way to access the box, but given the setup that Grant was
describing it did not sound like he had a encrypted VPN setup to
telnet over.
I also agree that having a secondary way of accessing the box, that is
secure,
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512
Stephen Wittig wrote:
I also agree that having a secondary way of accessing the box, that is
secure, is an important factor when updating a remote server (whether
that be another encrypted connection or people you can contact locally
in the data
For Grant:
I reread the init script for sshd, and I know see what was most likely
the problem. The init script, now, tries to kill all instances with
the process name of sshd, not just the daemon (as specified by the pid
file). This is why you were locked out when trying to restart the
The current init script will not try to restart the daemon if
everything does not exit cleanly. We already know that the main
process won't exit cleanly since it was manually killed.
Unless you are comfortable editing the init script I would suggest:
1) Type:
ps auxww |grep /usr/sbin/sshd |grep
Complete Side Note:
Does anyone know where to issue a bug report to try to have this
behavior changed. The correct (and more widely) seen behavior of
http://bugzilla.gentoo.org I guess.
Now, I know why I have never tried to submit a bug report before :)
--
[EMAIL PROTECTED] mailing list
I just upgraded ssh and when I try to restart I get:
* Stopping sshd ... [ !! ]
I don't see anything about it in '/var/log/sshd/current'. How can I
figure out what is wrong? I'm a little nervous because I don't want
to shut myself out of this remote server.
I also noticed many POSSIBLE
Grant writes:
I just upgraded ssh and when I try to restart I get:
* Stopping sshd ... [ !! ]
I don't see anything about it in '/var/log/sshd/current'. How can I
figure out what is wrong? I'm a little nervous because I don't want
to shut myself out of this remote server.
Uh-oh! I know
Grant wrote:
I just upgraded ssh and when I try to restart I get:
* Stopping sshd ... [ !! ]
I don't see anything about it in '/var/log/sshd/current'. How can I
figure out what is wrong? I'm a little nervous because I don't want
to shut myself out of this remote server.
I had a
Josh Cepek writes:
I had a similar issue after a previous update to ssh when I went to
restart it to get it to use the new binaries. One of the nice features
of sshd is that your current session will say active even if you kill
the sshd daemon process. Of course, if you get disconnected
On Sat, 8 Sep 2007 22:50:20 +0200
Alex Schuster [EMAIL PROTECTED] wrote:
Josh Cepek writes:
I had a similar issue after a previous update to ssh when I went to
restart it to get it to use the new binaries. One of the nice
features of sshd is that your current session will say active
37 matches
Mail list logo
