# ssh login from wan not login

## Truzzone

Hi to ALL !   :Very Happy: 

I have a strange problem with ssh daemon.

When I try to login from internet to my server with ssh I see this:

```
OpenSSH_4.7p1, OpenSSL 0.9.8g 19 Oct 2007

debug1: Reading configuration data /etc/ssh/ssh_config

debug1: Connecting to xxxxxxxxxxxx [xxxxxxxxxxxxxx] port xxx.

debug1: Connection established.

debug1: permanently_set_uid: 0/0

debug1: identity file /root/.ssh/identity type -1

debug1: identity file /root/.ssh/id_rsa type -1

debug1: identity file /root/.ssh/id_dsa type -1

debug1: Remote protocol version 2.0, remote software version OpenSSH_4.7

debug1: match: OpenSSH_4.7 pat OpenSSH*

debug1: Enabling compatibility mode for protocol 2.0

debug1: Local version string SSH-2.0-OpenSSH_4.7

debug1: SSH2_MSG_KEXINIT sent

debug1: SSH2_MSG_KEXINIT received

debug1: kex: server->client aes128-cbc hmac-md5 none

debug1: kex: client->server aes128-cbc hmac-md5 none

debug1: SSH2_MSG_KEX_DH_GEX_REQUEST(1024<1024<8192) sent

debug1: expecting SSH2_MSG_KEX_DH_GEX_GROUP

debug1: SSH2_MSG_KEX_DH_GEX_INIT sent

debug1: expecting SSH2_MSG_KEX_DH_GEX_REPLY

debug1: Host 'xxxxxxxxxxxxxx' is known and matches the RSA host key.

debug1: Found key in /root/.ssh/known_hosts:3

debug1: ssh_rsa_verify: signature correct

debug1: SSH2_MSG_NEWKEYS sent

debug1: expecting SSH2_MSG_NEWKEYS

debug1: SSH2_MSG_NEWKEYS received

debug1: SSH2_MSG_SERVICE_REQUEST sent

debug1: SSH2_MSG_SERVICE_ACCEPT received

debug1: Authentications that can continue: publickey,password,keyboard-interactive

debug1: Next authentication method: publickey

debug1: Trying private key: /root/.ssh/identity

debug1: Trying private key: /root/.ssh/id_rsa

debug1: Trying private key: /root/.ssh/id_dsa

debug1: Next authentication method: keyboard-interactive

Password:

debug1: Authentication succeeded (keyboard-interactive).

debug1: channel 0: new [client-session]

debug1: Entering interactive session.

#IT'S BLOCK HERE WITHOUT ANY RESPONSE (CTRL+C DON'T WORK)

```

IT'S BLOCK HERE WITHOUT ANY RESPONSE and without prompt (CTRL+C DON'T WORK)

When I try from a PC on lan this is the output:

```
OpenSSH_4.7p1, OpenSSL 0.9.8d 28 Sep 2006

debug1: Reading configuration data /etc/ssh/ssh_config

debug1: Connecting to xxxxxxxxxxxxxx [xxxxxxxxxxxxxx] port xxx.

debug1: Connection established.

debug1: permanently_set_uid: 0/0

debug1: identity file /root/.ssh/identity type -1

debug1: identity file /root/.ssh/id_rsa type -1

debug1: identity file /root/.ssh/id_dsa type -1

debug1: Remote protocol version 2.0, remote software version OpenSSH_4.7

debug1: match: OpenSSH_4.7 pat OpenSSH*

debug1: Enabling compatibility mode for protocol 2.0

debug1: Local version string SSH-2.0-OpenSSH_4.7

debug1: SSH2_MSG_KEXINIT sent

debug1: SSH2_MSG_KEXINIT received

debug1: kex: server->client aes128-cbc hmac-md5 none

debug1: kex: client->server aes128-cbc hmac-md5 none

debug1: SSH2_MSG_KEX_DH_GEX_REQUEST(1024<1024<8192) sent

debug1: expecting SSH2_MSG_KEX_DH_GEX_GROUP

debug1: SSH2_MSG_KEX_DH_GEX_INIT sent

debug1: expecting SSH2_MSG_KEX_DH_GEX_REPLY

debug1: Host 'xxxxxxxxxxxxxxx' is known and matches the RSA host key.

debug1: Found key in /root/.ssh/known_hosts:1

debug1: ssh_rsa_verify: signature correct

debug1: SSH2_MSG_NEWKEYS sent

debug1: expecting SSH2_MSG_NEWKEYS

debug1: SSH2_MSG_NEWKEYS received

debug1: SSH2_MSG_SERVICE_REQUEST sent

debug1: SSH2_MSG_SERVICE_ACCEPT received

debug1: Authentications that can continue: publickey,password,keyboard-interactive

debug1: Next authentication method: publickey

debug1: Trying private key: /root/.ssh/identity

debug1: Trying private key: /root/.ssh/id_rsa

debug1: Trying private key: /root/.ssh/id_dsa

debug1: Next authentication method: keyboard-interactive

Password:

debug1: Authentication succeeded (keyboard-interactive).

debug1: channel 0: new [client-session]

debug1: Entering interactive session.

Last login: xxxxxxxxxxxx from xxxxxxxxxxxxxxx

```

And it's possible to work...

This is a problem of ssh config?

```
grep -v "^#" /etc/ssh/sshd_config

Port xxxx

AddressFamily any

Protocol 2

PermitRootLogin yes

PasswordAuthentication no

UsePAM no

Subsystem       sftp    /usr/lib64/misc/sftp-server

```

or a iptables bad rules?   :Question: 

Best regards,

Truzzone   :Confused: 

----------

## alex.blackbit

do other protocols work correctly?

check the log of sshd.

did you tinker you iptables rules yourself and have enough experience for that?

you can post your rules, maybe someone finds an error.

----------

## Truzzone

The other protocol work without problems...

The output of ssh -vvv client:

```
debug3: tty_make_modes: 60 1

debug3: tty_make_modes: 61 1

debug3: tty_make_modes: 62 0

debug3: tty_make_modes: 70 1

debug3: tty_make_modes: 71 0

debug3: tty_make_modes: 72 1

debug3: tty_make_modes: 73 0

debug3: tty_make_modes: 74 0

debug3: tty_make_modes: 75 0

debug3: tty_make_modes: 90 1

debug3: tty_make_modes: 91 1

debug3: tty_make_modes: 92 0

debug3: tty_make_modes: 93 0

debug2: channel 0: request shell confirm 0

debug2: fd 3 setting TCP_NODELAY

debug2: callback done

debug2: channel 0: open confirm rwindow 0 rmax 32768

```

This is my iptables INPUT config ssh is in 9999 port:

```
iptables -vL

Chain INPUT (policy ACCEPT xxxxM packets, xxxxG bytes)

 pkts bytes target     prot opt in     out     source               destination

acct_int   all  --  tun0   any     anywhere             anywhere

acct_int   all  --  eth0   any     anywhere             anywhere

acct_ext   all  --  lo     any     anywhere             anywhere

acct_ext   all  --  eth1   any     anywhere             anywhere

ACCEPT     tcp  --  eth0   any     anywhere             anywhere            tcp dpt:9999

ACCEPT     udp  --  eth0   any     anywhere             anywhere            udp dpt:9999

ACCEPT     tcp  --  tun0   any     anywhere             anywhere            tcp dpt:9999

ACCEPT     udp  --  tun0   any     anywhere             anywhere            udp dpt:9999

DROP       tcp  --  eth0   any     anywhere             anywhere            tcp dpts:0:1023

DROP       udp  --  eth0   any     anywhere             anywhere            udp dpts:0:1023

```

Any suggestions?

Best regards,

Truzzone   :Confused: 

----------

## Hu

 *Truzzone wrote:*   

> 
> 
> This is my iptables INPUT config ssh is in 9999 port:
> 
> ```
> ...

 

Why are you allowing port 9999 for UDP?  Why is lo classified as an external device?  Does acct_ext allow ssh traffic?  The ACCEPT rules you show only apply to eth0.  Based on your naming, it appears that eth0 is your LAN interface and eth1 is your WAN interface.

 *Truzzone wrote:*   

> 
> 
> Any suggestions?
> 
> 

 

Post the output of iptables-save -c instead.  It is more complete.

----------

## Truzzone

 *Hu wrote:*   

> 
> 
> Why are you allowing port 9999 for UDP?

 

It's a test... but if you confirm that isn't used by ssh I delete it   :Wink:   *Hu wrote:*   

> 
> 
> Why is lo classified as an external device?

 

I don't know   :Confused:   *Hu wrote:*   

> Does acct_ext allow ssh traffic?

 I don't know   :Confused: 

acct_ext and acct_int I haven't set, I see after I upgrade iptables last time...

 *Hu wrote:*   

> The ACCEPT rules you show only apply to eth0.  Based on your naming, it appears that eth0 is your LAN interface and eth1 is your WAN interface.

 

eth0 > Router [WAN]

eth1 > Switch [LAN]

It's necessary to apply ACCEPT rule on lo?   :Question: 

Thanks for your support   :Smile: 

Best regards,

Truzzone   :Confused: 

 *Hu wrote:*   

> 
> 
> Post the output of iptables-save -c instead.  It is more complete.

 

```
iptables-save -c

*raw

:PREROUTING ACCEPT [3437183389:2264923251779]

:OUTPUT ACCEPT [3085033443:1702237121013]

COMMIT

# Completed on Thu Sep  4 11:52:40 2008

# Generated by iptables-save v1.3.5 on Thu Sep  4 11:52:40 2008

*nat

:PREROUTING ACCEPT [166678599:11151218879]

:POSTROUTING ACCEPT [1872094:140387609]

:OUTPUT ACCEPT [95453047:7330263010]

[1837751:150464545] -A POSTROUTING -o eth0 -j MASQUERADE

[20689:3445263] -A POSTROUTING -o tun0 -j MASQUERADE

COMMIT

# Completed on Thu Sep  4 11:52:40 2008

# Generated by iptables-save v1.3.5 on Thu Sep  4 11:52:40 2008

*mangle

:PREROUTING ACCEPT [5637194100:3855443849996]

:INPUT ACCEPT [5067987154:3542679773670]

:FORWARD ACCEPT [569141094:312748717684]

:OUTPUT ACCEPT [5332733623:3124392396279]

:POSTROUTING ACCEPT [5902325770:3437219662942]

COMMIT

# Completed on Thu Sep  4 11:52:40 2008

# Generated by iptables-save v1.3.5 on Thu Sep  4 11:52:40 2008

*filter

:INPUT ACCEPT [1509761070:1055088580384]

:FORWARD DROP [2592:148748]

:OUTPUT ACCEPT [1952893273:1014274066121]

:acct_ext - [0:0]

:acct_int - [0:0]

[30472:4146467] -A INPUT -i tun0 -j acct_int

[405275:77338175] -A INPUT -i eth0 -j acct_int

[28844:6093965] -A INPUT -i lo -j acct_ext

[57809:17488825] -A INPUT -i eth1 -j acct_ext

[863:127787] -A INPUT -i eth0 -p tcp -m tcp --dport 9999 -j ACCEPT

[0:0] -A INPUT -i eth0 -p udp -m udp --dport 9999 -j ACCEPT

[39913:4986982] -A INPUT -i tun0 -p tcp -m tcp --dport 9999 -j ACCEPT

[0:0] -A INPUT -i tun0 -p udp -m udp --dport 9999 -j ACCEPT

[22050:1181571] -A INPUT -i eth0 -p tcp -m tcp --dport 0:1023 -j DROP

[40312:22610818] -A INPUT -i eth0 -p udp -m udp --dport 0:1023 -j DROP

[261425:160336422] -A FORWARD -o tun0 -j acct_int

[269015:31707290] -A FORWARD -i tun0 -j acct_int

[9511008:501404525] -A FORWARD -o eth0 -j acct_int

[13524031:18995063944] -A FORWARD -i eth0 -j acct_int

[0:0] -A FORWARD -o lo -j acct_ext

[0:0] -A FORWARD -i lo -j acct_ext

[13262746:18834733186] -A FORWARD -o eth1 -j acct_ext

[9242133:469702899] -A FORWARD -i eth1 -j acct_ext

[228:9184] -A FORWARD -d 10.0.3.0/255.255.255.0 -i tun0 -j ACCEPT

[0:0] -A FORWARD -d 192.168.1.0/255.255.255.0 -i eth1 -j DROP

[16052145:927730123] -A FORWARD -s 192.168.1.0/255.255.255.0 -i eth1 -j ACCEPT

[22970131:32004835290] -A FORWARD -d 192.168.1.0/255.255.255.0 -i eth0 -j ACCEPT

[829755:108534383] -A FORWARD -s 10.0.3.0/255.255.255.0 -i tun0 -j ACCEPT

[886553:666549540] -A FORWARD -d 10.0.3.0/255.255.255.0 -i eth0 -j ACCEPT

[38715:27306849] -A OUTPUT -o tun0 -j acct_int

[387449:216058604] -A OUTPUT -o eth0 -j acct_int

[28844:6093965] -A OUTPUT -o lo -j acct_ext

[62624:42917552] -A OUTPUT -o eth1 -j acct_ext
```

----------

## JeliJami

try to force pseudo-tty allocation:

```
ssh -t your-ip
```

----------

## Truzzone

 *JeliJami wrote:*   

> try to force pseudo-tty allocation:
> 
> ```
> ssh -t your-ip
> ```
> ...

 

None, always block at:

```
debug2: channel 0: request shell confirm 0

debug2: fd 3 setting TCP_NODELAY

debug2: callback done

debug2: channel 0: open confirm rwindow 0 rmax 32768

```

Best regards,

Truzzone   :Confused: 

----------

## bunder

i'd try turning on UsePAM.

cheers

----------

## Truzzone

Sorry I post the wrong config of ssh, I have always set "usePAM yes", if I set to no I don't login   :Rolling Eyes: 

Best regards,

Truzzone   :Confused: 

----------

## Truzzone

Any suggestions?   :Question: 

I have the same problem when I try to connect with sftp from server to internet host, it block at the end without return with commands:

```
Password: 

debug1: Authentication succeeded (keyboard-interactive).

debug1: channel 0: new [client-session]

debug1: Entering interactive session.

debug1: Sending subsystem: sftp

< the cursor isn't here, I use CTRL+C to kill...

```

It's an iptables rule?   :Question: 

Best regards,

Truzzone   :Confused: 

----------

