Loading ...
Sorry, an error occurred while loading the content.

Re: [linux] trying to SSH

Expand Messages
  • horrorvacui@gmx.net
    On Wed, 7 Feb 2007 18:01:40 -0500 ... Why shouldn t it be possible? You can ssh to the machine you re working on same as you can ping it. Actually, you can ssh
    Message 1 of 6 , Feb 7, 2007
    • 0 Attachment
      On Wed, 7 Feb 2007 18:01:40 -0500
      Scott <scottro@...> wrote:

      > On Wed, Feb 07, 2007 at 04:33:10PM -0500, Michael Klinosky wrote:
      > >
      > > _On the daemon machine_? (I'm new to this, so I wouldn't think that
      > > that's possible.) In an Xterm, just like I'd do on the remote - correct?
      >

      Why shouldn't it be possible? You can ssh to the machine you're working
      on same as you can ping it. Actually, you can ssh to your hearts
      content, ssh in on the local machine, then ssh in from within the ssh
      session, then ssh in from the ssh session running within ssh session...

      >
      > > Actually, a linux guru suggested 222 to avoid attacks.
      >
      > Hrrm, I would think that he might have forgotten about rsh, or perhaps
      > figured that since it's almost never used anymore, no one would try that
      > port. I'd pick a different port--I usually just pick a random number
      > higher than any of the well known ports--well known ports are 0-1023.

      I concur, although you may have no intention to use that port for what
      it's intended for, it's a bit messy. A high-port is better for clarity
      or just to avoid misunderstandings.

      >
      > Anyway, try the iptables -L and if it shows that anything is blocked,
      > you can briefly do iptables -F (which will flush your rules and
      > basically disable iptables.)

      Let's not forget the default chain policy. If it's set to drop,
      flushing the chain is going to do the reverse of disabling it. A safer
      thing to do would be to use the distro-supplied script to stop the
      firewall. Or you could simply punch a hole in the firewall:
      iptables -I INPUT -p tcp --dport 222 -j ACCEPT
      ...and, if the OUTPUT chain has rules or a default policy set to deny:
      iptables -I OUTPUT -p tcp --dport 222 -j ACCEPT

      >
      > That is what I would do next, and see if the machine is, by default,
      > blocking port 222.

      Heh, Scott... As the bloke who got me using Archlinux, I'd expect you
      to think about this monkey business Arch uses to pull on you on a newly
      installed machine, by blocking all services via /etc/hosts.deny...

      Michael, check the /etc/hosts.deny for lines likely to block ssh access
      - on my Archlinux machine at work, this looks like:
      ALL: ALL: DENY
      ...which basically means "allow nothing at all" - also, look for lines
      having SSHD in them. If this looks like it's blocking access, you can
      use /etc/hosts.allow to explicitly allow ssh to work, with a line like
      this:
      SSHD: ALL: ALLOW
      ...that might fix it.

      Cheers
      --
      Horror Vacui

      War Is Peace
      Freedom Is Slavery
      Ignorance Is Strength
    • Michael Klinosky
      ... [root@D500 ~]# iptables -L Chain INPUT (policy ACCEPT) target prot opt source destination RH-Firewall-1-INPUT all -- anywhere
      Message 2 of 6 , Feb 7, 2007
      • 0 Attachment
        Scott wrote:
        > Yes, but many of them install a firewall by default. Sometimes, there's
        > information about it during installation, sometimes not. The usual way
        > to check is with
        >
        > iptables -L

        [root@D500 ~]# iptables -L
        Chain INPUT (policy ACCEPT)
        target prot opt source destination
        RH-Firewall-1-INPUT all -- anywhere anywhere

        Chain FORWARD (policy ACCEPT)
        target prot opt source destination
        RH-Firewall-1-INPUT all -- anywhere anywhere

        Chain OUTPUT (policy ACCEPT)
        target prot opt source destination

        Chain RH-Firewall-1-INPUT (2 references)
        target prot opt source destination
        ACCEPT all -- anywhere anywhere
        ACCEPT icmp -- anywhere anywhere icmp any
        ACCEPT esp -- anywhere anywhere
        ACCEPT ah -- anywhere anywhere
        ACCEPT udp -- anywhere 224.0.0.251 udp dpt:mdns
        ACCEPT udp -- anywhere anywhere udp dpt:ipp
        ACCEPT tcp -- anywhere anywhere tcp dpt:ipp
        ACCEPT all -- anywhere anywhere state
        RELATED,ESTABLISHED
        ACCEPT tcp -- anywhere anywhere state NEW
        tcp dpt:ssh
        REJECT all -- anywhere anywhere reject-with
        icmp-host-prohibited

        > Yes, on the machine running sshd, as a user with permission to ssh
        > (usually root does not have permission) just type

        I tried it with my IP addy - now I'll try it with localhost.

        > ssh localhost

        Connection refused

        > ssh -p 222 localhost

        !!!!!!! Got something! :)

        It's asking for key verification (as I was informed it would).

        So, this should be indicative - yes? Is it telling me that the computer
        is properly configed, and the modem/router is the culprit?

        I have Fedora Core 6, with gnome.

        Horror Vacui - regarding /etc/hosts.deny & hosts.allow --
        There are no lines in either file.
      Your message has been successfully submitted and would be delivered to recipients shortly.