Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > linux.debian.user > #175451 > unrolled thread

ssh doesn't work.

Back to article view | Back to linux.debian.user

Contents

  ssh doesn't work. EenyMeenyMinyMoa <eenymeenyminymoa@gmail.com> - 2016-12-06 05:40 +0100
    Re: ssh doesn't work. Andy Smith <andy@strugglers.net> - 2016-12-06 07:30 +0100
      Re: ssh doesn't work. EenyMeenyMinyMoa <eenymeenyminymoa@gmail.com> - 2016-12-07 16:30 +0100
        Re: ssh doesn't work. Henning Follmann <hfollmann@itcfollmann.com> - 2016-12-07 17:00 +0100
          Re: ssh doesn't work. EenyMeenyMinyMoa <eenymeenyminymoa@gmail.com> - 2016-12-07 18:40 +0100
            Re: ssh doesn't work. Greg Wooledge <wooledg@eeg.ccf.org> - 2016-12-07 19:00 +0100
              Re: ssh doesn't work. EenyMeenyMinyMoa <eenymeenyminymoa@gmail.com> - 2016-12-08 05:20 +0100
            Re: ssh doesn't work. Henning Follmann <hfollmann@itcfollmann.com> - 2016-12-07 19:20 +0100
              Re: ssh doesn't work. Greg Wooledge <wooledg@eeg.ccf.org> - 2016-12-07 19:50 +0100
                Re: ssh doesn't work. Henning Follmann <hfollmann@itcfollmann.com> - 2016-12-07 20:20 +0100
                Re: ssh doesn't work. Antti Talsta <atalsta@nothingtosee.org> - 2016-12-07 20:30 +0100
                  Re: ssh doesn't work. Reco <recoverym4n@gmail.com> - 2016-12-07 21:30 +0100
                    Re: ssh doesn't work. Henning Follmann <hfollmann@itcfollmann.com> - 2016-12-07 21:50 +0100
                      Re: ssh doesn't work. Reco <recoverym4n@gmail.com> - 2016-12-07 23:20 +0100
                        Re: ssh doesn't work. Darac Marjal <mailinglist@darac.org.uk> - 2016-12-08 16:40 +0100
                          Re: ssh doesn't work. Reco <recoverym4n@gmail.com> - 2016-12-08 18:00 +0100
                    Re: ssh doesn't work. Antti Talsta <atalsta@nothingtosee.org> - 2016-12-07 21:50 +0100
                      Re: ssh doesn't work. Reco <recoverym4n@gmail.com> - 2016-12-07 23:20 +0100
                Re: ssh doesn't work. Brian <ad44@cityscape.co.uk> - 2016-12-07 21:30 +0100
                  Re: ssh doesn't work. EenyMeenyMinyMoa <eenymeenyminymoa@gmail.com> - 2016-12-08 05:20 +0100
                    Re: ssh doesn't work. Lisi Reisz <lisi.reisz@gmail.com> - 2016-12-08 11:10 +0100
                      Re: ssh doesn't work. EenyMeenyMinyMoa <eenymeenyminymoa@gmail.com> - 2016-12-10 06:00 +0100
                        Re: ssh doesn't work. Joe <joe@jretrading.com> - 2016-12-10 10:10 +0100
                          Re: ssh doesn't work. Richard Hector <richard@walnut.gen.nz> - 2016-12-11 08:40 +0100
              Re: ssh doesn't work. EenyMeenyMinyMoa <eenymeenyminymoa@gmail.com> - 2016-12-08 06:50 +0100
                Re: ssh doesn't work. emetib <chadbrabec@gmail.com> - 2016-12-08 09:00 +0100
                  Re: ssh doesn't work. Henning Follmann <hfollmann@itcfollmann.com> - 2016-12-08 13:50 +0100
            Re: ssh doesn't work. emetib <chadbrabec@gmail.com> - 2016-12-07 20:20 +0100

Page 1 of 2  [1] 2  Next page →

#175451 — ssh doesn't work.

[Multipart message — attachments visible in raw view] — view raw

Hi.
I'm using jessie and trying to connect from one jessie machine to another
jessie machine by ssh.
I succeeded the following commands at the server machine.
$ ssh -p 9999 testac@localhost
$ ssh -p 9999 -l testac -i ~/.ssh/id_rsa_test localhost

But when I execute either of these commands
$ ssh -p 9999 testac@192.168.0.5
$ ssh -p 9999 -l testac -i ~/.ssh/id_rsa_test 192.168.0.5
, the terminal doesn't resopnd for minutes and finally gives this message.
ssh: connect to host 192.168.0.5 port 9999: Connection timed out

How can I connect?

On the client machine,

$ sudo ifconfig
eth2      Link encap:Ethernet  HWaddr --:--:--:--:--:--
          inet addr:192.168.0.3  Bcast:192.168.0.255  Mask:255.255.255.0
          inet6 addr: ----::----:----:----:----/64 Scope:Link
          UP BROADCAST RUNNING MULTICAST  MTU:1500  Metric:1
          RX packets:278828 errors:0 dropped:0 overruns:0 frame:0
          TX packets:210030 errors:0 dropped:0 overruns:0 carrier:0
          collisions:0 txqueuelen:1000
          RX bytes:316479195 (301.8 MiB)  TX bytes:22264869 (21.2 MiB)
lo        Link encap:Local Loopback
          inet addr:127.0.0.1  Mask:255.0.0.0
          inet6 addr: ::1/128 Scope:Host
          UP LOOPBACK RUNNING  MTU:65536  Metric:1
          RX packets:4694 errors:0 dropped:0 overruns:0 frame:0
          TX packets:4694 errors:0 dropped:0 overruns:0 carrier:0
          collisions:0 txqueuelen:0
          RX bytes:414354 (404.6 KiB)  TX bytes:414354 (404.6 KiB)

$ sudo arp-scan -I eth2 -l
Interface: eth2, datalink type: EN10MB (Ethernet)
Starting arp-scan 1.8.1 with 256 hosts (
http://www.nta-monitor.com/tools/arp-scan/)
192.168.0.1    --:--:--:--:--:--    I-O DATA DEVICE, INC.
192.168.0.5    --:--:--:--:--:--    FOXCONN
2 packets received by filter, 0 packets dropped by kernel
Ending arp-scan 1.8.1: 256 hosts scanned in 1.383 seconds (185.10
hosts/sec). 2 responded

$ tail -5 /etc/ssh/ssh_config
#   RekeyLimit 1G 1h
    SendEnv LANG LC_*
    HashKnownHosts yes
    GSSAPIAuthentication yes
    GSSAPIDelegateCredentials no

$ cat /etc/ssh/sshd_config
# Package generated configuration file
# See the sshd_config(5) manpage for details
# What ports, IPs and protocols we listen for
Port 22
# Use these options to restrict which interfaces/protocols sshd will bind to
#ListenAddress ::
#ListenAddress 0.0.0.0
Protocol 2
# HostKeys for protocol version 2
HostKey /etc/ssh/ssh_host_rsa_key
HostKey /etc/ssh/ssh_host_dsa_key
HostKey /etc/ssh/ssh_host_ecdsa_key
HostKey /etc/ssh/ssh_host_ed25519_key
#Privilege Separation is turned on for security
UsePrivilegeSeparation yes
# Lifetime and size of ephemeral version 1 server key
KeyRegenerationInterval 3600
ServerKeyBits 1024
# Logging
SyslogFacility AUTH
LogLevel INFO
# Authentication:
LoginGraceTime 120
PermitRootLogin no
StrictModes yes
RSAAuthentication yes
PubkeyAuthentication yes
#AuthorizedKeysFile    %h/.ssh/authorized_keys
# Don't read the user's ~/.rhosts and ~/.shosts files
IgnoreRhosts yes
# For this to work you will also need host keys in /etc/ssh_known_hosts
RhostsRSAAuthentication no
# similar for protocol version 2
HostbasedAuthentication no
# Uncomment if you don't trust ~/.ssh/known_hosts for
RhostsRSAAuthentication
#IgnoreUserKnownHosts yes
# To enable empty passwords, change to yes (NOT RECOMMENDED)
PermitEmptyPasswords no
# Change to yes to enable challenge-response passwords (beware issues with
# some PAM modules and threads)
ChallengeResponseAuthentication no
# Change to no to disable tunnelled clear text passwords
PasswordAuthentication no
# Kerberos options
#KerberosAuthentication no
#KerberosGetAFSToken no
#KerberosOrLocalPasswd yes
#KerberosTicketCleanup yes
# GSSAPI options
#GSSAPIAuthentication no
#GSSAPICleanupCredentials yes
X11Forwarding yes
X11DisplayOffset 10
PrintMotd no
PrintLastLog yes
TCPKeepAlive yes
#UseLogin no
#MaxStartups 10:30:60
#Banner /etc/issue.net
# Allow client to pass locale environment variables
AcceptEnv LANG LC_*
Subsystem sftp /usr/lib/openssh/sftp-server
# Set this to 'yes' to enable PAM authentication, account processing,
# and session processing. If this is enabled, PAM authentication will
# be allowed through the ChallengeResponseAuthentication and
# PasswordAuthentication.  Depending on your PAM configuration,
# PAM authentication via ChallengeResponseAuthentication may bypass
# the setting of "PermitRootLogin without-password".
# If you just want the PAM account and session checks to run without
# PAM authentication, then enable this but set PasswordAuthentication
# and ChallengeResponseAuthentication to 'no'.
UsePAM yes


On the server machine,

$ sudo ifconfig
eth1      Link encap:Ethernet  HWaddr --:--:--:--:--:--
          inet addr:192.168.0.5  Bcast:192.168.0.255  Mask:255.255.255.0
          inet6 addr: ----::----:----:----:----/64 Scope:Link
          UP BROADCAST RUNNING MULTICAST  MTU:1500  Metric:1
          RX packets:31176 errors:0 dropped:0 overruns:0 frame:0
          TX packets:20889 errors:0 dropped:0 overruns:0 carrier:0
          collisions:0 txqueuelen:1000
          RX bytes:27252237 (25.9 MiB)  TX bytes:2507801 (2.3 MiB)
          Interrupt:16 Memory:ee000000-ee020000

lo        Link encap:Local Loopback
          inet addr:127.0.0.1  Mask:255.0.0.0
          inet6 addr: ::1/128 Scope:Host
          UP LOOPBACK RUNNING  MTU:65536  Metric:1
          RX packets:2029 errors:0 dropped:0 overruns:0 frame:0
          TX packets:2029 errors:0 dropped:0 overruns:0 carrier:0
          collisions:0 txqueuelen:0
          RX bytes:233342 (227.8 KiB)  TX bytes:233342 (227.8 KiB)

$ sudo arp-scan -I eth1 -l
Interface: eth1, datalink type: EN10MB (Ethernet)
Starting arp-scan 1.8.1 with 256 hosts (
http://www.nta-monitor.com/tools/arp-scan/)
192.168.0.1    --:--:--:--:--:--    I-O DATA DEVICE, INC.
192.168.0.3    --:--:--:--:--:--    Dell Inc
2 packets received by filter, 0 packets dropped by kernel
Ending arp-scan 1.8.1: 256 hosts scanned in 1.385 seconds (184.84
hosts/sec). 2 responded

$ tail -5 /etc/ssh/ssh_config
#   RekeyLimit 1G 1h
    SendEnv LANG LC_*
    HashKnownHosts yes
    GSSAPIAuthentication yes
    GSSAPIDelegateCredentials no

$ cat /etc/ssh/sshd_config
# Package generated configuration file
# See the sshd_config(5) manpage for details
# What ports, IPs and protocols we listen for
Port 9999
# Use these options to restrict which interfaces/protocols sshd will bind to
#ListenAddress ::
#ListenAddress 0.0.0.0
Protocol 2
# HostKeys for protocol version 2
HostKey /etc/ssh/ssh_host_rsa_key
HostKey /etc/ssh/ssh_host_dsa_key
HostKey /etc/ssh/ssh_host_ecdsa_key
HostKey /etc/ssh/ssh_host_ed25519_key
#Privilege Separation is turned on for security
UsePrivilegeSeparation yes
# Lifetime and size of ephemeral version 1 server key
KeyRegenerationInterval 3600
ServerKeyBits 1024
# Logging
SyslogFacility AUTH
LogLevel INFO
# Authentication:
LoginGraceTime 120
PermitRootLogin no
StrictModes yes
RSAAuthentication yes
PubkeyAuthentication yes
#AuthorizedKeysFile    %h/.ssh/authorized_keys
# Don't read the user's ~/.rhosts and ~/.shosts files
IgnoreRhosts yes
# For this to work you will also need host keys in /etc/ssh_known_hosts
RhostsRSAAuthentication no
# similar for protocol version 2
HostbasedAuthentication no
# Uncomment if you don't trust ~/.ssh/known_hosts for
RhostsRSAAuthentication
#IgnoreUserKnownHosts yes
# To enable empty passwords, change to yes (NOT RECOMMENDED)
PermitEmptyPasswords no
# Change to yes to enable challenge-response passwords (beware issues with
# some PAM modules and threads)
ChallengeResponseAuthentication yes
# Change to no to disable tunnelled clear text passwords
PasswordAuthentication yes
# Kerberos options
#KerberosAuthentication no
#KerberosGetAFSToken no
#KerberosOrLocalPasswd yes
#KerberosTicketCleanup yes
# GSSAPI options
#GSSAPIAuthentication no
#GSSAPICleanupCredentials yes
X11Forwarding yes
X11DisplayOffset 10
PrintMotd no
PrintLastLog yes
TCPKeepAlive yes
#UseLogin no
#MaxStartups 10:30:60
#Banner /etc/issue.net
# Allow client to pass locale environment variables
AcceptEnv LANG LC_*
Subsystem sftp /usr/lib/openssh/sftp-server
# Set this to 'yes' to enable PAM authentication, account processing,
# and session processing. If this is enabled, PAM authentication will
# be allowed through the ChallengeResponseAuthentication and
# PasswordAuthentication.  Depending on your PAM configuration,
# PAM authentication via ChallengeResponseAuthentication may bypass
# the setting of "PermitRootLogin without-password".
# If you just want the PAM account and session checks to run without
# PAM authentication, then enable this but set PasswordAuthentication
# and ChallengeResponseAuthentication to 'no'.
UsePAM yes
Allowusers testac


Cheers,
EenyMeenyMinyMoa

[toc] | [next] | [standalone]

#175453

Hi,

On Tue, Dec 06, 2016 at 01:33:07PM +0900, EenyMeenyMinyMoa wrote:
> But when I execute either of these commands
> $ ssh -p 9999 testac@192.168.0.5
> $ ssh -p 9999 -l testac -i ~/.ssh/id_rsa_test 192.168.0.5
> , the terminal doesn't resopnd for minutes and finally gives this message.
> ssh: connect to host 192.168.0.5 port 9999: Connection timed out

The settings you've shown seem correct but the above output implies
a lack of connectivity. Have you checked there is no firewall
preventing port 9999 TCP communication?

To list rules:

# iptables -nL 

If that comes up empty, some basic connectivity checks (ping
192.168.0.5 from client) may be useful.

Cheers,
Andy

-- 
https://bitfolk.com/ -- No-nonsense VPS hosting

"I'd be happy to buy all variations of sex to ensure I got what I wanted."
 — Gary Coates (talking about cabling)

[toc] | [prev] | [next] | [standalone]

#175514

[Multipart message — attachments visible in raw view] — view raw

Thank you for your reply, Andy.

ufw was enabled on the server machine.
Because I don't have enough knoledge about iptables, I did
$ sudo ufw allow proto tcp from 192.168.0.3 to any port 9999
on the server machine.
Then I successfully connected from the client machine by ssh.

And next I want to do ssh with authentication key instead of password.
I've been struggling for hours.
I rewrited /etc/ssh/sshd_config.
On the client machine,

PasswordAuthentication no
AuthorizedKeysFile    %h/.ssh/authorized_keys
UsePAM no

On the server machine,

PasswordAuthentication no
AuthorizedKeysFile    %h/.ssh/authorized_keys
UsePAM no

Then I tried, but
Password:
still appeared.

$ ssh -v -p 9999 testac@192.168.0.5
OpenSSH_6.7p1 Debian-5+deb8u3, OpenSSL 1.0.1t  3 May 2016
debug1: Reading configuration data /etc/ssh/ssh_config
debug1: /etc/ssh/ssh_config line 19: Applying options for *
debug1: Connecting to 192.168.0.5 [192.168.0.5] port 9999.
debug1: Connection established.
debug1: key_load_public: No such file or directory
debug1: identity file /home/emmm/.ssh/id_rsa type -1
debug1: key_load_public: No such file or directory
debug1: identity file /home/emmm/.ssh/id_rsa-cert type -1
debug1: key_load_public: No such file or directory
debug1: identity file /home/emmm/.ssh/id_dsa type -1
debug1: key_load_public: No such file or directory
debug1: identity file /home/emmm/.ssh/id_dsa-cert type -1
debug1: key_load_public: No such file or directory
debug1: identity file /home/emmm/.ssh/id_ecdsa type -1
debug1: key_load_public: No such file or directory
debug1: identity file /home/emmm/.ssh/id_ecdsa-cert type -1
debug1: key_load_public: No such file or directory
debug1: identity file /home/emmm/.ssh/id_ed25519 type -1
debug1: key_load_public: No such file or directory
debug1: identity file /home/emmm/.ssh/id_ed25519-cert type -1
debug1: Enabling compatibility mode for protocol 2.0
debug1: Local version string SSH-2.0-OpenSSH_6.7p1 Debian-5+deb8u3
debug1: Remote protocol version 2.0, remote software version OpenSSH_6.7p1
Debian-5+deb8u3
debug1: match: OpenSSH_6.7p1 Debian-5+deb8u3 pat OpenSSH* compat 0x04000000
debug1: SSH2_MSG_KEXINIT sent
debug1: SSH2_MSG_KEXINIT received
debug1: kex: server->client aes128-ctr umac-64-etm@openssh.com none
debug1: kex: client->server aes128-ctr umac-64-etm@openssh.com none
debug1: sending SSH2_MSG_KEX_ECDH_INIT
debug1: expecting SSH2_MSG_KEX_ECDH_REPLY
debug1: Server host key: ECDSA
--:--:--:--:--:--:--:--:--:--:--:--:--:--:--:--
debug1: Host '[192.168.0.5]:9999' is known and matches the ECDSA host key.
debug1: Found key in /home/emmm/.ssh/known_hosts:1
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,keyboard-interactive
debug1: Next authentication method: publickey
debug1: Offering RSA public key: emmm@jessie
debug1: Authentications that can continue: publickey,keyboard-interactive
debug1: Trying private key: /home/emmm/.ssh/id_rsa
debug1: Trying private key: /home/emmm/.ssh/id_dsa
debug1: Trying private key: /home/emmm/.ssh/id_ecdsa
debug1: Trying private key: /home/emmm/.ssh/id_ed25519
debug1: Next authentication method: keyboard-interactive
Password:
debug1: Authentication succeeded (keyboard-interactive).
Authenticated to 192.168.0.5 ([192.168.0.5]:9999).
debug1: channel 0: new [client-session]
debug1: Requesting no-more-sessions@openssh.com
debug1: Entering interactive session.
debug1: Sending environment.
debug1: Sending env LANG = ja_JP.UTF-8
The programs included with the Debian GNU/Linux system are free software;
the exact distribution terms for each program are described in the
individual files in /usr/share/doc/*/copyright.
Debian GNU/Linux comes with ABSOLUTELY NO WARRANTY, to the extent
permitted by applicable law.
Last login: Thu Dec  8 08:28:43 2016 from 192.168.0.3
testac@jessie2:~$

I rewrited /etc/ssh/sshd_config on the server again 'cause my key is 2048
bit.

ServerKeyBits 2048

Then tried again.

$ ssh -v -p 9999 testac@192.168.0.5
OpenSSH_6.7p1 Debian-5+deb8u3, OpenSSL 1.0.1t  3 May 2016
debug1: Reading configuration data /etc/ssh/ssh_config
debug1: /etc/ssh/ssh_config line 19: Applying options for *
debug1: Connecting to 192.168.0.5 [192.168.0.5] port 9999.
debug1: Connection established.
debug1: key_load_public: No such file or directory
debug1: identity file /home/emmm/.ssh/id_rsa type -1
debug1: key_load_public: No such file or directory
debug1: identity file /home/emmm/.ssh/id_rsa-cert type -1
debug1: key_load_public: No such file or directory
debug1: identity file /home/emmm/.ssh/id_dsa type -1
debug1: key_load_public: No such file or directory
debug1: identity file /home/emmm/.ssh/id_dsa-cert type -1
debug1: key_load_public: No such file or directory
debug1: identity file /home/emmm/.ssh/id_ecdsa type -1
debug1: key_load_public: No such file or directory
debug1: identity file /home/emmm/.ssh/id_ecdsa-cert type -1
debug1: key_load_public: No such file or directory
debug1: identity file /home/emmm/.ssh/id_ed25519 type -1
debug1: key_load_public: No such file or directory
debug1: identity file /home/emmm/.ssh/id_ed25519-cert type -1
debug1: Enabling compatibility mode for protocol 2.0
debug1: Local version string SSH-2.0-OpenSSH_6.7p1 Debian-5+deb8u3
debug1: Remote protocol version 2.0, remote software version OpenSSH_6.7p1
Debian-5+deb8u3
debug1: match: OpenSSH_6.7p1 Debian-5+deb8u3 pat OpenSSH* compat 0x04000000
debug1: SSH2_MSG_KEXINIT sent
debug1: SSH2_MSG_KEXINIT received
debug1: kex: server->client aes128-ctr umac-64-etm@openssh.com none
debug1: kex: client->server aes128-ctr umac-64-etm@openssh.com none
debug1: sending SSH2_MSG_KEX_ECDH_INIT
debug1: expecting SSH2_MSG_KEX_ECDH_REPLY
debug1: Server host key: ECDSA
--:--:--:--:--:--:--:--:--:--:--:--:--:--:--:--
debug1: Host '[192.168.0.5]:9999' is known and matches the ECDSA host key.
debug1: Found key in /home/emmm/.ssh/known_hosts:1
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,keyboard-interactive
debug1: Next authentication method: publickey
debug1: Offering RSA public key: emmm@jessie
debug1: Authentications that can continue: publickey,keyboard-interactive
debug1: Trying private key: /home/emmm/.ssh/id_rsa
debug1: Trying private key: /home/emmm/.ssh/id_dsa
debug1: Trying private key: /home/emmm/.ssh/id_ecdsa
debug1: Trying private key: /home/emmm/.ssh/id_ed25519
debug1: Next authentication method: keyboard-interactive
debug1: Authentications that can continue: publickey,keyboard-interactive
debug1: No more authentication methods to try.
Permission denied (publickey,keyboard-interactive).

Restoring /etc/ssh/sshd_config by

ServerKeyBits 1024

was not helpful.
How can I do ssh with authentication key instead of password?

Cheers,
EenyMeenyMinyMoa


2016-12-06 15:22 GMT+09:00 Andy Smith <andy@strugglers.net>:

> Hi,
>
> On Tue, Dec 06, 2016 at 01:33:07PM +0900, EenyMeenyMinyMoa wrote:
> > But when I execute either of these commands
> > $ ssh -p 9999 testac@192.168.0.5
> > $ ssh -p 9999 -l testac -i ~/.ssh/id_rsa_test 192.168.0.5
> > , the terminal doesn't resopnd for minutes and finally gives this
> message.
> > ssh: connect to host 192.168.0.5 port 9999: Connection timed out
>
> The settings you've shown seem correct but the above output implies
> a lack of connectivity. Have you checked there is no firewall
> preventing port 9999 TCP communication?
>
> To list rules:
>
> # iptables -nL
>
> If that comes up empty, some basic connectivity checks (ping
> 192.168.0.5 from client) may be useful.
>
> Cheers,
> Andy
>
> --
> https://bitfolk.com/ -- No-nonsense VPS hosting
>
> "I'd be happy to buy all variations of sex to ensure I got what I wanted."
>  — Gary Coates (talking about cabling)
>
>

[toc] | [prev] | [next] | [standalone]

#175516

On Thu, Dec 08, 2016 at 12:27:53AM +0900, EenyMeenyMinyMoa wrote:
> Thank you for your reply, Andy.
> 
Please be so nice and trim your post to be meaningful and concise. Don't
just slapp something on the top.


> ufw was enabled on the server machine.
> Because I don't have enough knoledge about iptables, I did
> $ sudo ufw allow proto tcp from 192.168.0.3 to any port 9999
> on the server machine.
> Then I successfully connected from the client machine by ssh.
> 
> And next I want to do ssh with authentication key instead of password.
> I've been struggling for hours.
> I rewrited /etc/ssh/sshd_config.
> On the client machine,
> 
> PasswordAuthentication no
> AuthorizedKeysFile    %h/.ssh/authorized_keys
> UsePAM no
> 
> On the server machine,
> 
> PasswordAuthentication no
> AuthorizedKeysFile    %h/.ssh/authorized_keys
> UsePAM no
> 
> Then I tried, but
> Password:
> still appeared.
> 


Please revert to your original configs. Key login works be default and
requires no change.

first generate a key:
ssh-keygen

By default it creats both id_rsa and id_rsa.pub in your ~/.ssh directory.
id_rsa contains the private key and it should remain on the client machine
in your ~/.ssh directory.
Transfer the id_rsa.pub to the server you want to logon to.there append it
to 
cat id_rsa.pub >> <homedirectory of user>/.ssh/authorized_keys

now you should be able to ssh into that server with pk authorization.

If that works you can go on and disable the password authorization by
setting on the server sshd config

PasswordAuthentication no

-H

[toc] | [prev] | [next] | [standalone]

#175518

[Multipart message — attachments visible in raw view] — view raw

Thank you for the quick response, Henning.

2016-12-08 1:07 GMT+09:00 Henning Follmann <hfollmann@itcfollmann.com>:
> Please revert to your original configs. Key login works be default and
> requires no change.

By reverting to my original configs :
PasswordAuthentication yes
I was able to ssh.

$ ssh -p 9999 testac@192.168.0.5
testac@192.168.0.5's password:
Last login: Thu Dec  8 10:56:31 2016 from 192.168.0.3

>
> first generate a key:
> ssh-keygen
>
> By default it creats both id_rsa and id_rsa.pub in your ~/.ssh directory.
> id_rsa contains the private key and it should remain on the client machine
> in your ~/.ssh directory.

I already did as the debug output in my last email showed.

> Transfer the id_rsa.pub to the server you want to logon to.there append it
> to
> cat id_rsa.pub >> <homedirectory of user>/.ssh/authorized_keys
>

Sorry. I forgot writing about having done this.

> debug1: Authentications that can continue: publickey,keyboard-interactive
> debug1: Trying private key: /home/emmm/.ssh/id_rsa
> debug1: Trying private key: /home/emmm/.ssh/id_dsa
> debug1: Trying private key: /home/emmm/.ssh/id_ecdsa
> debug1: Trying private key: /home/emmm/.ssh/id_ed25519
> debug1: Next authentication method: keyboard-interactive

I'm now going to comprehend the debugging output.
On the client ssh tried to use my private key, but failed?

> now you should be able to ssh into that server with pk authorization.
>
> If that works you can go on and disable the password authorization by
> setting on the server sshd config
>
> PasswordAuthentication no

By changing only this line of sshd config, the result is

$ ssh -p 9999 testac@192.168.0.5
Permission denied (publickey,keyboard-interactive).
$ ssh -p 9801 -l testac -i ~/.ssh/id_rsa_for_test 192.168.0.5
Permission denied (publickey,keyboard-interactive).

I'll try further and am consulting
http://unix.stackexchange.com/questions/36540/why-am-i-still-getting-a-password-prompt-with-ssh-with-public-key-authentication
and so on.

$ ls -ls /home/testac/.ssh
total 12
4 -rwx------ 1 u1 u1 776 Dec  8 11:05 authorized_keys
4 -rw-r--r-- 1 u1 u1 388 Dec  6 11:57 id_rsa_test.pub
4 -rwx------ 1 u1 u1 444 Dec  6 20:46 known_hosts

Cheers,
EenyMeenyMinyMoa

[toc] | [prev] | [next] | [standalone]

#175519

On Thu, Dec 08, 2016 at 02:37:09AM +0900, EenyMeenyMinyMoa wrote:
> $ ls -ls /home/testac/.ssh
> total 12
> 4 -rwx------ 1 u1 u1 776 Dec  8 11:05 authorized_keys
> 4 -rw-r--r-- 1 u1 u1 388 Dec  6 11:57 id_rsa_test.pub
> 4 -rwx------ 1 u1 u1 444 Dec  6 20:46 known_hosts

Which machine is that -- the client, or the server?

Check those things on the server, and also check:
ls -ld / /home /home/testac /home/testac/.ssh

Also make sure that "u1" is the actual owner of /home/testac.
The discrepancy between the username shown by ls -l and the name
of the home directory does not inspire confidence.

[toc] | [prev] | [next] | [standalone]

#175541

[Multipart message — attachments visible in raw view] — view raw

Hi,

2016-12-08 2:52 GMT+09:00 Greg Wooledge <wooledg@eeg.ccf.org>:
> On Thu, Dec 08, 2016 at 02:37:09AM +0900, EenyMeenyMinyMoa wrote:
>> $ ls -ls /home/testac/.ssh
>> total 12
>> 4 -rwx------ 1 u1 u1 776 Dec  8 11:05 authorized_keys
>> 4 -rw-r--r-- 1 u1 u1 388 Dec  6 11:57 id_rsa_test.pub
>> 4 -rwx------ 1 u1 u1 444 Dec  6 20:46 known_hosts
>
> Which machine is that -- the client, or the server?
>

the server.

> Check those things on the server, and also check:
> ls -ld / /home /home/testac /home/testac/.ssh
>
> Also make sure that "u1" is the actual owner of /home/testac.
> The discrepancy between the username shown by ls -l and the name
> of the home directory does not inspire confidence.

I changed the owner of /home/testac and the files on the server. And after
operations obeying

2016-12-08 3:51 GMT+09:00 emetib <chadbrabec@gmail.com>:
> On Wednesday, December 7, 2016 at 11:40:04 AM UTC-6, EenyMeenyMinyMoa
wrote:
>>
>> $ ls -ls /home/testac/.ssh
>> total 12
>> 4 -rwx------ 1 u1 u1 776 Dec  8 11:05 authorized_keys
>> 4 -rw-r--r-- 1 u1 u1 388 Dec  6 11:57 id_rsa_test.pub
>> 4 -rwx------ 1 u1 u1 444 Dec  6 20:46 known_hosts
>>
> check the perms on ~/.ssh
> should be 700, dwrx------
>
> and your authorized_keys should be 644, -rw-r--r--

$ sudo ls -la /home/testac/.ssh/
total 20
drwx------ 2 testac testac 4096 Dec  8 07:57 .
drwxr-xr-x 4 testac testac 4096 Dec  8 07:49 ..
-rw-r--r-- 1 testac testac  776 Dec  8 11:05 authorized_keys
-rw-r--r-- 1 testac testac  388 Dec  6 11:57 id_rsa_for_test.pub
-rwx------ 1 testac testac  444 Dec  6 20:46 known_hosts

and tried.

$ ssh -p 9999 testac@192.168.0.5

Then a dialog box prompting me to enter my private key appeared.
After entering it, I could login.
Already at this stage(PasswordAuthentication yes), the prompt
testac@192.168.0.5's password:
didn't appear.
Next I changed /etc/ssh/ssh_config on the server

PasswordAuthentication no

and after executing

$ sudo systemctl restart ssh

, then I could successfully login too.
Thank you everyone!

Cheers,
EenyMeenyMinyMoa

[toc] | [prev] | [next] | [standalone]

#175520

On Thu, Dec 08, 2016 at 02:37:09AM +0900, EenyMeenyMinyMoa wrote:
> Thank you for the quick response, Henning.
> 
Sorry, you have to stop this. Now!
I think it is great that you want to learn how to use ssh. It is an
important skill for admins and users.
However you are approaching it the wrong way. Your set up is too
complicated and you poke around in  the dark.

Set up two machines. install ssh and the server on those machines.
Create identical named accounts on both.

Then connect. 
Then understand!
Only after you understand, make ONE! change at the time.
repeat.

Also changing the port to a nonstandard port is not a safety measure. Not a
reasonable at least. Unless there is some sane reason (like the network
operator prevents using port 22) keep it!

You made too many changes without even understanding what these changes do.
The likelihood that you end up with an insecure setup is high this way.





-H




-- 
Henning Follmann           | hfollmann@itcfollmann.com

[toc] | [prev] | [next] | [standalone]

#175522

On Wed, Dec 07, 2016 at 01:23:23PM -0500, Henning Follmann wrote:
> Also changing the port to a nonstandard port is not a safety measure. Not a
> reasonable at least. Unless there is some sane reason (like the network
> operator prevents using port 22) keep it!

I disagree with this.  Changing the port at least decreases the number
of brute force attacks against you, which saves resources (bandwidth, CPU)
that are otherwise wasted by the attackers.

I understand that you mean "it will not stop a dedicated professional
attacker who really, really wants to get into your computer".  And that's
true.  But it does help against the random script kiddies and attacks of
opportunity.

[toc] | [prev] | [next] | [standalone]

#175525

On Wed, Dec 07, 2016 at 01:49:34PM -0500, Greg Wooledge wrote:
> On Wed, Dec 07, 2016 at 01:23:23PM -0500, Henning Follmann wrote:
> > Also changing the port to a nonstandard port is not a safety measure. Not a
> > reasonable at least. Unless there is some sane reason (like the network
> > operator prevents using port 22) keep it!
> 
> I disagree with this.  Changing the port at least decreases the number
> of brute force attacks against you, which saves resources (bandwidth, CPU)
> that are otherwise wasted by the attackers.
> 
This is security by obscurity, which has some serious issues.
First it hides obvious issues. If you see high traffic on port 9999 noone
in the NOC knows what that is. If it is on port 22 they know it's ssh.

Also have a sensible plan in place (and the documentation with it).
So if I have admins in the US and in Germany, I only let ip from that
origin connect to port 22.

And also IDS (e.g. fail2ban) help you cutting those waste cpu cycles down.

And the best part about this, any issue will be obvious. And  obscurity
is the enemy of security.


> I understand that you mean "it will not stop a dedicated professional
> attacker who really, really wants to get into your computer".  And that's
> true.  But it does help against the random script kiddies and attacks of
> opportunity.
> 

And to protect against the "professionals" allow only pk authentication
when the service is on any public network.

-H


-- 
Henning Follmann           | hfollmann@itcfollmann.com

[toc] | [prev] | [next] | [standalone]

#175526

[Multipart message — attachments visible in raw view] — view raw

On Wed, Dec 07, 2016 at 01:49:34PM -0500, Greg Wooledge wrote:

> Changing the port at least decreases the number of brute force attacks
> against you, which saves resources (bandwidth, CPU) that are otherwise
> wasted by the attackers.

How about fail2ban for that?

-- 
Antti Talsta

[toc] | [prev] | [next] | [standalone]

#175528

	Hi.

On Wed, 7 Dec 2016 21:14:51 +0200
Antti Talsta <atalsta@nothingtosee.org> wrote:

> On Wed, Dec 07, 2016 at 01:49:34PM -0500, Greg Wooledge wrote:
> 
> > Changing the port at least decreases the number of brute force attacks
> > against you, which saves resources (bandwidth, CPU) that are otherwise
> > wasted by the attackers.
> 
> How about fail2ban for that?

How fail2ban can help against an army of bots trying one single
password per bot?

Reco

[toc] | [prev] | [next] | [standalone]

#175529

On Wed, Dec 07, 2016 at 11:28:53PM +0300, Reco wrote:
> 	Hi.
> 
> On Wed, 7 Dec 2016 21:14:51 +0200
> Antti Talsta <atalsta@nothingtosee.org> wrote:
> 
> > On Wed, Dec 07, 2016 at 01:49:34PM -0500, Greg Wooledge wrote:
> > 
> > > Changing the port at least decreases the number of brute force attacks
> > > against you, which saves resources (bandwidth, CPU) that are otherwise
> > > wasted by the attackers.
> > 
> > How about fail2ban for that?
> 
> How fail2ban can help against an army of bots trying one single
> password per bot?
> 
That actually works well. Usually it's multiple attempts from one ip.
fail2ban catches exactly that. And then blacklists that ip.

-H

-- 
Henning Follmann           | hfollmann@itcfollmann.com

[toc] | [prev] | [next] | [standalone]

#175534

On Wed, 7 Dec 2016 15:54:46 -0500
Henning Follmann <hfollmann@itcfollmann.com> wrote:

> On Wed, Dec 07, 2016 at 11:28:53PM +0300, Reco wrote:
> > 	Hi.
> > 
> > On Wed, 7 Dec 2016 21:14:51 +0200
> > Antti Talsta <atalsta@nothingtosee.org> wrote:
> > 
> > > On Wed, Dec 07, 2016 at 01:49:34PM -0500, Greg Wooledge wrote:
> > > 
> > > > Changing the port at least decreases the number of brute force attacks
> > > > against you, which saves resources (bandwidth, CPU) that are otherwise
> > > > wasted by the attackers.
> > > 
> > > How about fail2ban for that?
> > 
> > How fail2ban can help against an army of bots trying one single
> > password per bot?
> > 
> That actually works well. Usually it's multiple attempts from one ip.
> fail2ban catches exactly that. And then blacklists that ip.

Probably it is so. It's been awhile since I ran publicly accessible
sshd on port 22 with password authentication enabled.

Personally I prefer a bunch of simple iptables rules to fail2ban
though. After all, why bother running a userspace tool, if you can
force the kernel itself to do the job?

Reco

[toc] | [prev] | [next] | [standalone]

#175568

On Thu, Dec 08, 2016 at 01:18:38AM +0300, Reco wrote:
>On Wed, 7 Dec 2016 15:54:46 -0500
>Henning Follmann <hfollmann@itcfollmann.com> wrote:
>
>> On Wed, Dec 07, 2016 at 11:28:53PM +0300, Reco wrote:
>> > 	Hi.
>> >
>> > On Wed, 7 Dec 2016 21:14:51 +0200
>> > Antti Talsta <atalsta@nothingtosee.org> wrote:
>> >
>> > > On Wed, Dec 07, 2016 at 01:49:34PM -0500, Greg Wooledge wrote:
>> > >
>> > > > Changing the port at least decreases the number of brute force attacks
>> > > > against you, which saves resources (bandwidth, CPU) that are otherwise
>> > > > wasted by the attackers.
>> > >
>> > > How about fail2ban for that?
>> >
>> > How fail2ban can help against an army of bots trying one single
>> > password per bot?
>> >
>> That actually works well. Usually it's multiple attempts from one ip.
>> fail2ban catches exactly that. And then blacklists that ip.
>
>Probably it is so. It's been awhile since I ran publicly accessible
>sshd on port 22 with password authentication enabled.
>
>Personally I prefer a bunch of simple iptables rules to fail2ban
>though. After all, why bother running a userspace tool, if you can
>force the kernel itself to do the job?

Could you share with the group what "simple iptables rules" you use? I 
presume that iptables, by itself, can't replicate the idea of "block 
after X failures in Y minutes", but presumably you're using some kind of 
rate limiting, instead?

>
>Reco
>

-- 
For more information, please reread.

[toc] | [prev] | [next] | [standalone]

#175570

	Hi.

On Thu, 8 Dec 2016 15:37:45 +0000
Darac Marjal <mailinglist@darac.org.uk> wrote:

> On Thu, Dec 08, 2016 at 01:18:38AM +0300, Reco wrote:
> >On Wed, 7 Dec 2016 15:54:46 -0500
> >Henning Follmann <hfollmann@itcfollmann.com> wrote:
> >
> >> On Wed, Dec 07, 2016 at 11:28:53PM +0300, Reco wrote:
> >> > 	Hi.
> >> >
> >> > On Wed, 7 Dec 2016 21:14:51 +0200
> >> > Antti Talsta <atalsta@nothingtosee.org> wrote:
> >> >
> >> > > On Wed, Dec 07, 2016 at 01:49:34PM -0500, Greg Wooledge wrote:
> >> > >
> >> > > > Changing the port at least decreases the number of brute force attacks
> >> > > > against you, which saves resources (bandwidth, CPU) that are otherwise
> >> > > > wasted by the attackers.
> >> > >
> >> > > How about fail2ban for that?
> >> >
> >> > How fail2ban can help against an army of bots trying one single
> >> > password per bot?
> >> >
> >> That actually works well. Usually it's multiple attempts from one ip.
> >> fail2ban catches exactly that. And then blacklists that ip.
> >
> >Probably it is so. It's been awhile since I ran publicly accessible
> >sshd on port 22 with password authentication enabled.
> >
> >Personally I prefer a bunch of simple iptables rules to fail2ban
> >though. After all, why bother running a userspace tool, if you can
> >force the kernel itself to do the job?
> 
> Could you share with the group what "simple iptables rules" you use? I 
> presume that iptables, by itself, can't replicate the idea of "block 
> after X failures in Y minutes", but presumably you're using some kind of 
> rate limiting, instead?

Sure. It's in archives somewhere already, but:

iptables -A INPUT -p tcp -m tcp --dport 22 -m conntrack --ctstate NEW \
-m hashlimit --hashlimit-upto 1/hour --hashlimit-burst 8 \
--hashlimit-mode srcip --hashlimit-name ssh \
--hashlimit-htable-expire 65536 -m comment --comment "HTTPS Blocker" \
 -j ACCEPT

iptables -A INPUT -p tcp -m tcp --dport 22 --tcp-flags SYN,RST,ACK SYN \
-m comment --comment "HTTPS Blocker" -j DROP

Back in the day I was not that lazy for building kernel modules I used
TARPIT instead of DROP.


PS From the previous discussion of this very topic I was pointed that
such iptables configuration is unsuitable for certain 'Modern Desktop
Environment'. Therefore this iptables configuration should be used on
'understand what I'm doing' basis.

Reco

[toc] | [prev] | [next] | [standalone]

#175530

[Multipart message — attachments visible in raw view] — view raw

On Wed, Dec 07, 2016 at 11:28:53PM +0300, Reco wrote:

> How fail2ban can help against an army of bots trying one single
> password per bot?

It doesn't.
 
-- 
Antti Talsta

[toc] | [prev] | [next] | [standalone]

#175535

On Wed, 7 Dec 2016 22:46:16 +0200
Antti Talsta <atalsta@nothingtosee.org> wrote:

> On Wed, Dec 07, 2016 at 11:28:53PM +0300, Reco wrote:
> 
> > How fail2ban can help against an army of bots trying one single
> > password per bot?
> 
> It doesn't.

My point exactly. Using sshd on non-standard port does, as bots are too
stupid to try anything other than tcp:22 on ipv4 for ssh brute-force.

Does not invalidate other virtues of using fail2ban though.

Reco

[toc] | [prev] | [next] | [standalone]

#175527

On Wed 07 Dec 2016 at 13:49:34 -0500, Greg Wooledge wrote:

> On Wed, Dec 07, 2016 at 01:23:23PM -0500, Henning Follmann wrote:
> > Also changing the port to a nonstandard port is not a safety measure. Not a
> > reasonable at least. Unless there is some sane reason (like the network
> > operator prevents using port 22) keep it!
> 
> I disagree with this.  Changing the port at least decreases the number
> of brute force attacks against you, which saves resources (bandwidth, CPU)
> that are otherwise wasted by the attackers.

I agree with this. Having ssh on a port other than 22 does decrease the
*visibility* of probes to port 22. A user would in all probabilty see
nothing and would have a warm, fuzzy feeling. Job done; nothing to see.

However, while it might save resources it does not make the ssh service
any safer. Henning Follmann is correct, it is not a safety measure. To
be a safety measure it would have to guard against something which is
inherently defective in ssh itself. There is no such known defect in
ssh which makes random password probing more likely to succeed than
non-random probing.

> I understand that you mean "it will not stop a dedicated professional
> attacker who really, really wants to get into your computer".  And that's
> true.  But it does help against the random script kiddies and attacks of
> opportunity.

Whatever you understand, Henning Follmann said nothing of the sort. You
have put words into his mouth and introduced buzzwords like "dedicated",
"professional" and "attacker". You give the impression that someone who
really wants to get into your computer via ssh can do so. 

That is not correct. There is no way *anyone* can get into your ssh
account protected by a good password. There is no hole in ssh; it does
not exist.

Random script kiddy attacks are of absolutely no consequence. Annoying
perhaps, but no threat whatsoever. In terms of security, changing the
port number for ssh does bugger all.

-- 
Brian.

[toc] | [prev] | [next] | [standalone]

#175540

[Multipart message — attachments visible in raw view] — view raw

Hi,

2016-12-08 5:25 GMT+09:00 Brian <ad44@cityscape.co.uk>:
> Random script kiddy attacks are of absolutely no consequence. Annoying
> perhaps, but no threat whatsoever. In terms of security, changing the
> port number for ssh does bugger all.

What security risk can changing the port number for ssh cause?

Cheers,
EenyMeenyMinyMoa

[toc] | [prev] | [next] | [standalone]

Page 1 of 2  [1] 2  Next page →

Back to top | Article view | linux.debian.user

csiph-web