Re: [gentoo-user] SSH hosed, only rubble remains
Tuesday 30 May 2006 07:51 skrev Iain Buchanan: Ah, I was looking in /etc/init.d wondering why I couldn't find it :) I have bad RAM in my head. I guess sh scripts can be run by sh and bash, and probably other --sh variants. Not that that helps with this topic, I was just thinking aloud :) $ ls -l /bin/sh lrwxrwxrwx 1 root root 4 15 maj 17:46 /bin/sh - bash From 'man bash': Bash is an sh-compatible command language interpreter that executes commands read from the standard input or from a file. Bash also incorporates useful features from the Korn and C shells (ksh and csh). --norc Do not read and execute the personal initialization file ~/.bashrc if the shell is interactive. This option is on by default if the shell is invoked as sh If bash is invoked with the name sh, it tries to mimic the startup behavior of historical versions of sh as closely as possible, while conforming to the POSIX standard as well. -- Bo Andresen pgpw92UZF0yXN.pgp Description: PGP signature
Re: [gentoo-user] SSH hosed, only rubble remains
On Tue, 30 May 2006 06:35:39 +0200, Bo Ørsted Andresen wrote: That of course should have been negated... if [ -n $PS1 ] Or even if [ -n $PS1 ] or you'll get an error if PS1 is undefined. -- Neil Bothwick If the pen is mightier than the sword, and a picture is worth a thousand words, how dangerous is a fax? signature.asc Description: PGP signature
Re: [gentoo-user] SSH hosed, only rubble remains
Tuesday 30 May 2006 16:19 skrev Neil Bothwick: Or even if [ -n $PS1 ] or you'll get an error if PS1 is undefined. That explains a LOT! ;) Didn't quite understand why the statement was true even when the variable was not set... -- Bo Andresen pgpDLPBh4Hu7J.pgp Description: PGP signature
Re: [gentoo-user] SSH hosed, only rubble remains
On 5/29/06, Bo Ørsted Andresen [EMAIL PROTECTED] wrote: Tuesday 30 May 2006 06:48 skrev Iain Buchanan: I see this [ x != x$BLAH ] test all over the place, especially in the /etc/init.d scripts.Maybe -z is not standardised or something? Dunno why people use it.Having searched a little further I have been able to locate a few scripts thatuses this in my bin folders. Common for those scripts are that they are shscripts and not bash scripts. Looking at 'man sh' you find no -z or -n but they are in 'man bash'.I think it's safe to say that .bashrc is a bash script and to make it evenmore amusing (or whatever) Kevin does use both -z and -n a little furtherdown in his script. All true. I do translations like this when I want to make it clear what's going on. I worry that in the future seeing a test on $PS1 will baffle me, even if I wrote it. So I create a variable whose name indicates the motivation. I'm never going to save enough time optimizing a .bashrc script to pay for one minutes' worth of floundering later on. I have no defense for the variance in coding style. I didn't notice it so I didn't change it. I may still not do so -- I don't see the point. It's a matter of taste. ++ kevin -- Kevin O'Gorman, PhD
Re: [gentoo-user] SSH hosed, only rubble remains
Sunday 28 May 2006 18:21 skrev Kevin O'Gorman: if [ x != x$PS1 ] ; then SHELL_LOGIN=1 else # Probably scp; empty string is false SHELL_LOGIN= fi if [ -n $SHELL_LOGIN ] [...] IMHO it seems kind of lame to use one shell variable to create another instead of just using the one that is already there... Also shouldn't: if [ x != x$PS1 ] be equivalent to: if [ -z $PS1 ] ? -- Bo Andresen pgpP3j2fvgiUj.pgp Description: PGP signature
Re: [gentoo-user] SSH hosed, only rubble remains
Tuesday 30 May 2006 06:26 skrev Bo Ørsted Andresen: if [ -z $PS1 ] That of course should have been negated... if [ -n $PS1 ] -- Bo Andresen pgpnSDqa93h5t.pgp Description: PGP signature
Re: [gentoo-user] SSH hosed, only rubble remains
On Tue, 2006-05-30 at 06:26 +0200, Bo Ørsted Andresen wrote: Also shouldn't: if [ x != x$PS1 ] be equivalent to: if [ -z $PS1 ] I see this [ x != x$BLAH ] test all over the place, especially in the /etc/init.d scripts. Maybe -z is not standardised or something? Dunno why people use it. -- Iain Buchanan iaindb at netspace dot net dot au It is contrary to reasoning to say that there is a vacuum or space in which there is absolutely nothing. -- Descartes -- gentoo-user@gentoo.org mailing list
Re: [gentoo-user] SSH hosed, only rubble remains
Tuesday 30 May 2006 06:48 skrev Iain Buchanan:
I see this [ x != x$BLAH ] test all over the place, especially in
the /etc/init.d scripts. Maybe -z is not standardised or something?
Dunno why people use it.
You do?? I don't:
$ grep \[a-z]\ /etc/init.d/*
/etc/init.d/halt.sh:if [[ ${cmd} == u ]]; then
/etc/init.d/xdm:# How this basically works, is the a runlevel is a additional
/etc/init.d/xdm:# runlevel never gets changed to this runlevel. Along with the
a
--
Bo Andresen
pgpBF9dz7TafM.pgp
Description: PGP signature
Re: [gentoo-user] SSH hosed, only rubble remains
Tuesday 30 May 2006 06:48 skrev Iain Buchanan: I see this [ x != x$BLAH ] test all over the place, especially in the /etc/init.d scripts. Maybe -z is not standardised or something? Dunno why people use it. Having searched a little further I have been able to locate a few scripts that uses this in my bin folders. Common for those scripts are that they are sh scripts and not bash scripts. Looking at 'man sh' you find no -z or -n but they are in 'man bash'. I think it's safe to say that .bashrc is a bash script and to make it even more amusing (or whatever) Kevin does use both -z and -n a little further down in his script. -- Bo Andresen pgpOokfUvsjw4.pgp Description: PGP signature
Re: [gentoo-user] SSH hosed, only rubble remains
On Tue, 2006-05-30 at 07:10 +0200, Bo Ørsted Andresen wrote: Tuesday 30 May 2006 06:48 skrev Iain Buchanan: I see this [ x != x$BLAH ] test all over the place, especially in the /etc/init.d scripts. Maybe -z is not standardised or something? Dunno why people use it. Having searched a little further I have been able to locate a few scripts that uses this in my bin folders. Common for those scripts are that they are sh scripts and not bash scripts. Looking at 'man sh' you find no -z or -n but they are in 'man bash'. Ah, I was looking in /etc/init.d wondering why I couldn't find it :) I have bad RAM in my head. I guess sh scripts can be run by sh and bash, and probably other --sh variants. Not that that helps with this topic, I was just thinking aloud :) -- Iain Buchanan iaindb at netspace dot net dot au If you are a police dog, where's your badge? -- Question James Thurber used to drive his German Shepherd crazy. -- gentoo-user@gentoo.org mailing list
Re: [gentoo-user] SSH hosed, only rubble remains
On 5/27/06, John Jolet [EMAIL PROTECTED] wrote: That does not work for ssh/scp sessions.I usually test $PS1 to tell if it's really a shell -- the variable does not even exist for an scp session, although .bashrc gets called.can you give us an example of what your .bashrc looks like? Well, the whole thing is kinda long, but the part I was fooling with lately now looks like this, and partly automates the use of ssh-agent for my (very frequent) use of ssh from home to some machines at work. The problem was probably either the echo commands or that this actually proceeds within a subshell. if [ x != x$PS1 ] ; then SHELL_LOGIN=1 else # Probably scp; empty string is false SHELL_LOGIN= fi if [ -n $SHELL_LOGIN ] then if [ -z $SSH_AGENT_PID ] then # not yet running in ssh-agent ssh-agent /bin/bash r=$? echo Done with ssh-agent sleep 1 exit $r else # this is an ssh-agent subshell echo You may want to run ssh-add. fi fi -- Kevin O'Gorman, PhD
Re: [gentoo-user] SSH hosed, only rubble remains
On May 28, 2006, at 11:21 AM, Kevin O'Gorman wrote: On 5/27/06, John Jolet [EMAIL PROTECTED] wrote: That does not work for ssh/scp sessions. I usually test $PS1 to tell if it's really a shell -- the variable does not even exist for an scp session, although .bashrc gets called. can you give us an example of what your .bashrc looks like? Well, the whole thing is kinda long, but the part I was fooling with lately now looks like this, and partly automates the use of ssh-agent for my (very frequent) use of ssh from home to some machines at work. The problem was probably either the echo commands or that this actually proceeds within a subshell. if [ x != x$PS1 ] ; then SHELL_LOGIN=1 else # Probably scp; empty string is false SHELL_LOGIN= fi if [ -n $SHELL_LOGIN ] then if [ -z $SSH_AGENT_PID ] then # not yet running in ssh-agent ssh-agent /bin/bash r=$? echo Done with ssh-agent sleep 1 exit $r else # this is an ssh-agent subshell echo You may want to run ssh-add. fi fi -- Kevin O'Gorman, PhD well, you could comment out the echo commands and try it. personally, I try to stay away from things happening automatically for me. just my preference. I would rename .bashrc to something else, like old.bashrc and do the scp and see if that works. depending on what your needs are, you could also add a second user with the same uid, but a different home directory and use that other user for scp. shrug. not a big fan of ssh_agent (or anything that caches credentials). -- gentoo-user@gentoo.org mailing list
Re: [gentoo-user] SSH hosed, only rubble remains
On 5/28/06, John Jolet [EMAIL PROTECTED] wrote: On May 28, 2006, at 11:21 AM, Kevin O'Gorman wrote: On 5/27/06, John Jolet [EMAIL PROTECTED] wrote: That does not work for ssh/scp sessions.I usually test $PS1 to tell if it's really a shell -- the variable does not even exist for an scp session, although .bashrc gets called. can you give us an example of what your .bashrc looks like? Well, the whole thing is kinda long, but the part I was fooling with lately now looks like this, and partly automates the use of ssh-agent for my (very frequent) use of ssh from home to some machines at work.The problem was probably either the echo commands or that this actually proceeds within a subshell. if [ x != x$PS1 ] ; then SHELL_LOGIN=1 else # Probably scp; empty string is false SHELL_LOGIN= fi if [ -n $SHELL_LOGIN ] then if [ -z $SSH_AGENT_PID ] then # not yet running in ssh-agent ssh-agent /bin/bash r=$? echo Done with ssh-agent sleep 1 exit $r else # this is an ssh-agent subshell echo You may want to run ssh-add. fi fi -- Kevin O'Gorman, PhDwell, you could comment out the echo commands and try it.personally, I try to stay away from things happening automatically for me.just my preference.I would rename .bashrc to somethingelse, like old.bashrc and do the scp and see if that works.depending on what your needs are, you could also add a second userwith the same uid, but a different home directory and use that other user for scp. shrug.not a big fan of ssh_agent (or anythingthat caches credentials). Sorry, I didn't make myself clear. PROBLEM SOLVED, and the .bashrc I quoted works fine. What I had to do was create the SHELL_LOGIN variable, and use it to protect the code that interfered with scp. I normally don't use that kind of automation either, but for security reasons I use a passphrase on my ssh identity, and it's long. Typing it a lot got real old, so I started using ssh_agent, but I use it in a lot of windows, so I'm just trying to balance convenience and security. Some days I do 20 or more scp operations. That's the usual balancing act -- if it's too inconvenient, I'll ditch the security and hope for the best. So this is what I came up with. What I'd really like is a way to get this set up when I log into KDE, so that all the windows I open under that login have an agent. I'm not worried about physical security on this system, but the possibility of a hacker break-in giving automatic access to other hosts. Thus the long passphrase on my private keyrings. I was also reluctant to use ssh-agent, but on reflection I don't see a real vulnerability. I use it on my home system, which is not exposed to others in the usual course of things. If somebody steals the computer, the loss of power un-caches the credentials, so I'm only vulnerable to someone physically sneaking in to *use* my computer and finding me logged in. Very unlikely, because when I leave the house I'm either logged off or my session is locked. I'm simply not a big enough fish for it to be reasonable anyone would do this. Of course, security issues are always a balancing act and you may figure the balance however you like. ++ kevin -- Kevin O'Gorman, PhD
Re: [gentoo-user] SSH hosed, only rubble remains
On 5/27/06, John Jolet [EMAIL PROTECTED] wrote: Password: debug1: packet_send2: adding 32 (len 25 padlen 7 extra_pad 64) debug2: input_userauth_info_req debug2: input_userauth_info_req: num_prompts 0 debug1: packet_send2: adding 48 (len 10 padlen 6 extra_pad 64) debug1: ssh-userauth2 successful: method keyboard-interactive debug3: clear hostkey 0 debug3: clear hostkey 1 debug3: clear hostkey 2 debug1: fd 4 setting O_NONBLOCK debug1: fd 5 setting O_NONBLOCK debug1: channel 0: new [client-session] debug3: ssh_session2_open: channel_new: 0 debug1: send channel open 0 debug1: Entering interactive session. debug2: callback start debug1: ssh_session2_setup: id 0 debug1: Sending command: scp -v -t . debug1: channel request 0: exec debug2: callback done debug1: channel 0: open confirm rwindow 0 rmax 32768 debug2: channel 0: rcvd adjust 131072 okay, so in this instance, you're trying an scp...what happens whenyou do an ssh?and does anything at all show up in the logs on theserver?In the /etc/ssh/sshd_config file, there can be a LogLevelentry.try DEBUG2 or DEBUG3 --gentoo-user@gentoo.org mailing listOkay, I set LogLevel=DEBUG3 and reloaded sshd, but I got no more output than usual: May 27 09:14:55 treat sshd[11739]: Received SIGHUP; restarting. May 27 09:14:55 treat sshd[2352]: Server listening on 0.0.0.0 port 22. May 27 09:15:31 treat sshd[2356]: Connection from 64.166.164.53 port 32776 May 27 09:15:36 treat sshd[2356]: Accepted keyboard-interactive/pam for kevin from 64.166.164.53 port 32776 ssh2 May 27 09:15:36 treat sshd(pam_unix)[2361]: session opened for user kevin by (uid=0) And when it's ssh instead of scp, I get: May 27 09:20:53 treat sshd[2392]: Connection from 64.166.164.53 port 32777 May 27 09:20:57 treat sshd[2392]: Accepted keyboard-interactive/pam for kevin from 64.166.164.53 port 32777 ssh2 May 27 09:20:57 treat sshd(pam_unix)[2402]: session opened for user kevin by (uid=0) May 27 09:21:01 treat sshd[2402]: Connection closed by 64.166.164.53 May 27 09:21:01 treat sshd(pam_unix)[2402]: session closed for user kevin May 27 09:21:01 treat sshd[2402]: Closing connection to 64.166.164.53 Which covers a simple login-logout sequence.-- Kevin O'Gorman, PhD
Re: [gentoo-user] SSH hosed, only rubble remains
Okay, I set LogLevel=DEBUG3 and reloaded sshd, but I got no more output than usual: May 27 09:14:55 treat sshd[11739]: Received SIGHUP; restarting. May 27 09:14:55 treat sshd[2352]: Server listening on 0.0.0.0 port 22. May 27 09:15:31 treat sshd[2356]: Connection from 64.166.164.53 port 32776 May 27 09:15:36 treat sshd[2356]: Accepted keyboard-interactive/pam for kevin from 64.166.164.53 port 32776 ssh2 May 27 09:15:36 treat sshd(pam_unix)[2361]: session opened for user kevin by (uid=0) And when it's ssh instead of scp, I get: May 27 09:20:53 treat sshd[2392]: Connection from 64.166.164.53 port 32777 May 27 09:20:57 treat sshd[2392]: Accepted keyboard-interactive/pam for kevin from 64.166.164.53 port 32777 ssh2 May 27 09:20:57 treat sshd(pam_unix)[2402]: session opened for user kevin by (uid=0) May 27 09:21:01 treat sshd[2402]: Connection closed by 64.166.164.53 May 27 09:21:01 treat sshd(pam_unix)[2402]: session closed for user kevin May 27 09:21:01 treat sshd[2402]: Closing connection to 64.166.164.53 Which covers a simple login-logout sequence. -- Kevin O'Gorman, PhD well, it really looks from both ends like it's working. what is the shell for the given user? in /etc/passwd, if you're using local authentication. -- gentoo-user@gentoo.org mailing list
Re: [gentoo-user] SSH hosed, only rubble remains
On 5/27/6, John Jolet [EMAIL PROTECTED] wrote: Okay, I set LogLevel=DEBUG3 and reloaded sshd, but I got no more output than usual: May 27 09:14:55 treat sshd[11739]: Received SIGHUP; restarting. May 27 09:14:55 treat sshd[2352]: Server listening on 0.0.0.0 port 22. May 27 09:15:31 treat sshd[2356]: Connection from 64.166.164.53 port 32776 May 27 09:15:36 treat sshd[2356]: Accepted keyboard-interactive/pam for kevin from 64.166.164.53 port 32776 ssh2 May 27 09:15:36 treat sshd(pam_unix)[2361]: session opened for user kevin by (uid=0) And when it's ssh instead of scp, I get: May 27 09:20:53 treat sshd[2392]: Connection from 64.166.164.53 port 32777 May 27 09:20:57 treat sshd[2392]: Accepted keyboard-interactive/pam for kevin from 64.166.164.53 port 32777 ssh2 May 27 09:20:57 treat sshd(pam_unix)[2402]: session opened for user kevin by (uid=0) May 27 09:21:01 treat sshd[2402]: Connection closed by 64.166.164.53 May 27 09:21:01 treat sshd(pam_unix)[2402]: session closed for user kevin May 27 09:21:01 treat sshd[2402]: Closing connection to 64.166.164.53 Which covers a simple login-logout sequence. -- Kevin O'Gorman, PhDwell, it really looks from both ends like it's working.what is theshell for the given user?in /etc/passwd, if you're using local authentication. That was the hint I needed. It's /bin/bash, which reminded me I just changed something in .bashrc which outputs a message and does some other stuff which must be confusing scp. In fact, I just confirmed that by commenting it out. Now scp works too. So: PROBLEM SOLVED. Now I just have to figure out how to tailor it some more so the offending code is skipped for 'scp'. That I can do. Thanks for the help. ++ kevin-- Kevin O'Gorman, PhD
Re: [gentoo-user] SSH hosed, only rubble remains
That was the hint I needed. It's /bin/bash, which reminded me I just changed something in .bashrc which outputs a message and does some other stuff which must be confusing scp. In fact, I just confirmed that by commenting it out. Now scp works too. So: PROBLEM SOLVED. Now I just have to figure out how to tailor it some more so the offending code is skipped for 'scp'. That I can do. bash has a built-in variable that tells you what the command wasshould be able to test for scp in your script i've never tried to get that fancy with .bashrc. -- gentoo-user@gentoo.org mailing list
Re: [gentoo-user] SSH hosed, only rubble remains
On 5/27/06, John Jolet [EMAIL PROTECTED] wrote: That was the hint I needed.It's /bin/bash, which reminded me I just changed something in .bashrc which outputs a message and does some other stuff which must be confusing scp.In fact, I just confirmed that by commenting it out.Now scp works too. So: PROBLEM SOLVED. Now I just have to figure out how to tailor it some more so the offending code is skipped for 'scp'.That I can do. bash has a built-in variable that tells you what the commandwasshould be able to test for scp in your scripti'venever tried to get that fancy with .bashrc.-- gentoo-user@gentoo.org mailing listThat does not work for ssh/scp sessions. I usually test $PS1 to tell if it's really a shell -- the variable does not even exist for an scp session, although .bashrc gets called. ++ kevin-- Kevin O'Gorman, PhD
Re: [gentoo-user] SSH hosed, only rubble remains
That does not work for ssh/scp sessions. I usually test $PS1 to tell if it's really a shell -- the variable does not even exist for an scp session, although .bashrc gets called. can you give us an example of what your .bashrc looks like? -- gentoo-user@gentoo.org mailing list
Re: [gentoo-user] SSH hosed, only rubble remains
On 5/25/06, John Jolet [EMAIL PROTECTED] wrote: On May 25, 2006, at 1:07 PM, Kevin O'Gorman wrote: Somewhere along the line, ssh and ssh2 have gotten conflated, confused or just downright broken.I have been running ssh daemon(s) for so long I don't even remember how I set them up.They Just Ran (TM). For a short while, ssh connections to here (home) from work have taken an unusually long time to establish.I thought it was something to do with my domain registration, which was changing at the same time, but that has settled down (I think).And I've been too busy surviving a car crash and attendant medical problems to be exactly on top of the situation. Now I cannot seem to make a connection at all, and I can't make much sense out of the setup I have. First, I have both an /etc/init.d/sshd -- Kevin O'Gorman, PhD hmmm, i imagine you meant there to be more there.if you haveconsole access to the box, tail -f on the messages log whileattempting to do an ssh -v -v -v ip_address from another client.that might tell you something. Yeh. Fumblefingers sent it on its way before it was ready. You got the gist though, it seems. Anyway, I tried what you asked (fortunately I have multiple hosts here). The ssh -v -v -v brokenhost command produces a raft of info. Below I included just what's after entering the password, but I doubt it will help. I need to get the daemon to be similarly prolix. This host fails to complete ssh requests from all comers -- Windows running SSH Secure Shell or Linux or Solaris running whatever ssh they have, so I need the info from this gentoo server. So how do I get that? Password: debug1: packet_send2: adding 32 (len 25 padlen 7 extra_pad 64) debug2: input_userauth_info_req debug2: input_userauth_info_req: num_prompts 0 debug1: packet_send2: adding 48 (len 10 padlen 6 extra_pad 64) debug1: ssh-userauth2 successful: method keyboard-interactive debug3: clear hostkey 0 debug3: clear hostkey 1 debug3: clear hostkey 2 debug1: fd 4 setting O_NONBLOCK debug1: fd 5 setting O_NONBLOCK debug1: channel 0: new [client-session] debug3: ssh_session2_open: channel_new: 0 debug1: send channel open 0 debug1: Entering interactive session. debug2: callback start debug1: ssh_session2_setup: id 0 debug1: Sending command: scp -v -t . debug1: channel request 0: exec debug2: callback done debug1: channel 0: open confirm rwindow 0 rmax 32768 debug2: channel 0: rcvd adjust 131072 ++ kevin -- Kevin O'Gorman, PhD
Re: [gentoo-user] SSH hosed, only rubble remains
On 5/26/06, Kevin O'Gorman [EMAIL PROTECTED] wrote: On 5/25/06, John Jolet [EMAIL PROTECTED] wrote: On May 25, 2006, at 1:07 PM, Kevin O'Gorman wrote: Somewhere along the line, ssh and ssh2 have gotten conflated, confused or just downright broken.I have been running ssh daemon(s) for so long I don't even remember how I set them up.They Just Ran (TM). For a short while, ssh connections to here (home) from work have taken an unusually long time to establish.I thought it was something to do with my domain registration, which was changing at the same time, but that has settled down (I think).And I've been too busy surviving a car crash and attendant medical problems to be exactly on top of the situation. Now I cannot seem to make a connection at all, and I can't make much sense out of the setup I have. First, I have both an /etc/init.d/sshd -- Kevin O'Gorman, PhD hmmm, i imagine you meant there to be more there.if you haveconsole access to the box, tail -f on the messages log whileattempting to do an ssh -v -v -v ip_address from another client.that might tell you something. Yeh. Fumblefingers sent it on its way before it was ready. You got the gist though, it seems. Anyway, I tried what you asked (fortunately I have multiple hosts here). The ssh -v -v -v brokenhost command produces a raft of info. Below I included just what's after entering the password, but I doubt it will help. I need to get the daemon to be similarly prolix. This host fails to complete ssh requests from all comers -- Windows running SSH Secure Shell or Linux or Solaris running whatever ssh they have, so I need the info from this gentoo server. So how do I get that? Password: debug1: packet_send2: adding 32 (len 25 padlen 7 extra_pad 64) debug2: input_userauth_info_req debug2: input_userauth_info_req: num_prompts 0 debug1: packet_send2: adding 48 (len 10 padlen 6 extra_pad 64) debug1: ssh-userauth2 successful: method keyboard-interactive debug3: clear hostkey 0 debug3: clear hostkey 1 debug3: clear hostkey 2 debug1: fd 4 setting O_NONBLOCK debug1: fd 5 setting O_NONBLOCK debug1: channel 0: new [client-session] debug3: ssh_session2_open: channel_new: 0 debug1: send channel open 0 debug1: Entering interactive session. debug2: callback start debug1: ssh_session2_setup: id 0 debug1: Sending command: scp -v -t . debug1: channel request 0: exec debug2: callback done debug1: channel 0: open confirm rwindow 0 rmax 32768 debug2: channel 0: rcvd adjust 131072 ++ kevin I should also have clarified: the contents of /var/log/messages is the same as for an ssh login: just two lines of basic information that the client has been accepted. So what I need is the magic incantation to put in sshd_config. I don't know what it is for sure, but the following appear to be prime suspects, I just don't know what to change them to: # Logging # obsoletes QuietMode and FascistLogging #SyslogFacility AUTH #LogLevel INFO -- Kevin O'Gorman, PhD
[gentoo-user] SSH hosed, only rubble remains
Somewhere along the line, ssh and ssh2 have gotten conflated, confused or just downright broken. I have been running ssh daemon(s) for so long I don't even remember how I set them up. They Just Ran (TM). For a short while, ssh connections to here (home) from work have taken an unusually long time to establish. I thought it was something to do with my domain registration, which was changing at the same time, but that has settled down (I think). And I've been too busy surviving a car crash and attendant medical problems to be exactly on top of the situation. Now I cannot seem to make a connection at all, and I can't make much sense out of the setup I have. First, I have both an /etc/init.d/sshd-- Kevin O'Gorman, PhD
Re: [gentoo-user] SSH hosed, only rubble remains
On May 25, 2006, at 1:07 PM, Kevin O'Gorman wrote: Somewhere along the line, ssh and ssh2 have gotten conflated, confused or just downright broken. I have been running ssh daemon(s) for so long I don't even remember how I set them up. They Just Ran (TM). For a short while, ssh connections to here (home) from work have taken an unusually long time to establish. I thought it was something to do with my domain registration, which was changing at the same time, but that has settled down (I think). And I've been too busy surviving a car crash and attendant medical problems to be exactly on top of the situation. Now I cannot seem to make a connection at all, and I can't make much sense out of the setup I have. First, I have both an /etc/init.d/sshd -- Kevin O'Gorman, PhD hmmm, i imagine you meant there to be more there. if you have console access to the box, tail -f on the messages log while attempting to do an ssh -v -v -v ip_address from another client. that might tell you something. -- gentoo-user@gentoo.org mailing list
