Setup an SSH server

parmegv · 2011-03-01 15:37:26

Hi everybody,

I've been trying to setup my computer with OpenSSH, following the wiki but I have not managed at all. I want to use public cryptography with this), but I always get the same error:

ssh -vvv user@serveraddress
OpenSSH_5.1p1 Debian-5, OpenSSL 0.9.8g 19 Oct 2007
debug1: Reading configuration data /etc/ssh/ssh_config
debug1: Applying options for *
debug2: ssh_connect: needpriv 0
debug1: Connecting to serveraddress [serveraddress] port 22.
debug1: Connection established.
debug1: identity file ~/.ssh/identity type -1
debug1: identity file ~/.ssh/id_rsa type -1
debug3: Not a RSA1 key file ~/.ssh/id_dsa.
debug2: key_type_from_name: unknown key type '-----BEGIN'
debug3: key_read: missing keytype
debug2: key_type_from_name: unknown key type 'Proc-Type:'
debug3: key_read: missing keytype
debug2: key_type_from_name: unknown key type 'DEK-Info:'
debug3: key_read: missing keytype
debug3: key_read: missing whitespace
debug3: key_read: missing whitespace
debug3: key_read: missing whitespace
debug3: key_read: missing whitespace
debug3: key_read: missing whitespace
debug3: key_read: missing whitespace
debug3: key_read: missing whitespace
debug3: key_read: missing whitespace
debug3: key_read: missing whitespace
debug3: key_read: missing whitespace
debug2: key_type_from_name: unknown key type '-----END'
debug3: key_read: missing keytype
debug1: identity file ~/.ssh/id_dsa type 2
debug1: Checking blacklist file /usr/share/ssh/blacklist.DSA-1024
debug1: Checking blacklist file /etc/ssh/blacklist.DSA-1024
ssh_exchange_identification: Connection closed by remote host

I have tried to put permissions OK, doing in the server side "chmod 700 .ssh" and "chmod 600 .ssh/*", but it still does not work.

I read that possibly my ISP would be blocking that port, so I changed the sshd_config to this:

$ less /etc/ssh/sshd_config 
#       $OpenBSD: sshd_config,v 1.82 2010/09/06 17:10:19 naddy Exp $

# This is the sshd server system-wide configuration file.  See
# sshd_config(5) for more information.

# This sshd was compiled with PATH=/usr/bin:/bin:/usr/sbin:/sbin

# The strategy used for options in the default sshd_config shipped with
# OpenSSH is to specify options with their default value where
# possible, but leave them commented.  Uncommented options change a
# default value.

Port 1999
#AddressFamily any
#ListenAddress 0.0.0.0
#ListenAddress ::

# The default requires explicit activation of protocol 1
#Protocol 2

# HostKey for protocol version 1
#HostKey /etc/ssh/ssh_host_key
# 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

# Lifetime and size of ephemeral version 1 server key
#KeyRegenerationInterval 1h
#ServerKeyBits 1024

# Logging
# obsoletes QuietMode and FascistLogging
#SyslogFacility AUTH
#LogLevel INFO

# Authentication:

#LoginGraceTime 2m
PermitRootLogin no
#StrictModes yes
#MaxAuthTries 6
#MaxSessions 10

#RSAAuthentication yes
#PubkeyAuthentication yes
#AuthorizedKeysFile     .ssh/authorized_keys

# For this to work you will also need host keys in /etc/ssh/ssh_known_hosts
#RhostsRSAAuthentication no
# similar for protocol version 2
#HostbasedAuthentication no
# Change to yes if you don't trust ~/.ssh/known_hosts for
# RhostsRSAAuthentication and HostbasedAuthentication
#IgnoreUserKnownHosts no
# Don't read the user's ~/.rhosts and ~/.shosts files
#IgnoreRhosts yes

# To disable tunneled clear text passwords, change to no here!
PasswordAuthentication no
#PermitEmptyPasswords no

# Change to no to disable s/key passwords
ChallengeResponseAuthentication no

# Kerberos options
#KerberosAuthentication no
#KerberosOrLocalPasswd yes
#KerberosTicketCleanup yes
#KerberosGetAFSToken no

# GSSAPI options
#GSSAPIAuthentication no
#GSSAPICleanupCredentials yes

But when I try to connect to that 1999 port it says "Connection refused". It was then when I decided to ask for help specifically for me. I have read a lot of documentation, but nothing solved my problem.

Can anybody help me? Thank you very much

Last edited by parmegv (2011-03-01 18:22:44)

jollysnowman · 2011-03-01 15:57:53

Have you also made sure that your ROUTER is opening that port? I was in the exact same boat as you until I had a facepalm moment and realized that I hadn't set my router to forward the proper port.

jakobm · 2011-03-01 16:04:48

Have you modified the hosts.allow file as specified by the section SSH Allowing others in - ArchWiki?

Besides, check the sshd log ('connection refused' messages).

parmegv · 2011-03-01 16:22:48

jakobm wrote:

Have you modified the hosts.allow file as specified by the section SSH Allowing others in - ArchWiki?
Besides, check the sshd log ('connection refused' messages).

It is OK.

jollysnowman wrote:

Have you also made sure that your ROUTER is opening that port? I was in the exact same boat as you until I had a facepalm moment and realized that I hadn't set my router to forward the proper port.

Por 22 is open, but I have set up a trigger to the port I am currently using instead of 22 and it still does not connect at all.

ewaller · 2011-03-01 17:08:10

debug2: key_type_from_name: unknown key type '-----BEGIN'
debug3: key_read: missing keytype
debug2: key_type_from_name: unknown key type 'Proc-Type:'
debug3: key_read: missing keytype
debug2: key_type_from_name: unknown key type 'DEK-Info:'
debug3: key_read: missing keytype
debug3: key_read: missing whitespace
debug3: key_read: missing whitespace
debug3: key_read: missing whitespace
debug3: key_read: missing whitespace
debug3: key_read: missing whitespace
debug3: key_read: missing whitespace
debug3: key_read: missing whitespace
debug3: key_read: missing whitespace
debug3: key_read: missing whitespace
debug3: key_read: missing whitespace
debug2: key_type_from_name: unknown key type '-----END'
debug3: key_read: missing keytype

I think your "Key" looks looks like a PGP key in-lined in a text file. I am pretty sure that is wrong. How did you generate your keys?

By the way, it looks like you are hitting the sshd server, so all of the routing stuff seems okay. Any clues in the server side logs?
As a side note, please use BBCode code tags around program output in your posts (Be kind to your reader )

Inxsible · 2011-03-01 17:29:02

parmegv, would you please use code tags in your first post. Keeps from making threads a mile long.

https://wiki.archlinux.org/index.php/Fo … s_and_Code

parmegv · 2011-03-01 18:16:59

Inxsible wrote:

parmegv, would you please use code tags in your first post. Keeps from making threads a mile long.

https://wiki.archlinux.org/index.php/Fo … s_and_Code

Done, sorry.

ewaller wrote:

debug2: key_type_from_name: unknown key type '-----BEGIN'
debug3: key_read: missing keytype
debug2: key_type_from_name: unknown key type 'Proc-Type:'
debug3: key_read: missing keytype
debug2: key_type_from_name: unknown key type 'DEK-Info:'
debug3: key_read: missing keytype
debug3: key_read: missing whitespace
debug3: key_read: missing whitespace
debug3: key_read: missing whitespace
debug3: key_read: missing whitespace
debug3: key_read: missing whitespace
debug3: key_read: missing whitespace
debug3: key_read: missing whitespace
debug3: key_read: missing whitespace
debug3: key_read: missing whitespace
debug3: key_read: missing whitespace
debug2: key_type_from_name: unknown key type '-----END'
debug3: key_read: missing keytype
I think your "Key" looks looks like a PGP key in-lined in a text file. I am pretty sure that is wrong. How did you generate your keys?
By the way, it looks like you are hitting the sshd server, so all of the routing stuff seems okay. Any clues in the server side logs?
As a side note, please use BBCode code tags around program output in your posts (Be kind to your reader )

I did see the file with the key and realised that, but I thought SSH would understand it. I generated it like this:

ssh-keygen -t dsa
scp user@remoteClient.com:~/.ssh/id_dsa.pub ~/.ssh/id_dsa_name.pub
mkdir .ssh
cat ~/.ssh/id_dsa_name.pub >> .ssh/authorized_keys

In order to get privileges correct, I did what it is meant to do:

chmod 700 .ssh
chmod 600 .ssh/*

How should I generate the id_dsa, so?

Last edited by parmegv (2011-03-01 18:17:55)

ewaller · 2011-03-01 18:54:18

parmegv wrote:

... I generated it like this:
ssh-keygen -t dsa
scp user@remoteClient.com:~/.ssh/id_dsa.pub ~/.ssh/id_dsa_name.pub
mkdir .ssh
cat ~/.ssh/id_dsa_name.pub >> .ssh/authorized_keys
In order to get privileges correct, I did what it is meant to do:
chmod 700 .ssh
chmod 600 .ssh/*
...

I have personally been tripped up by the wiki. Some clarification:
You generate the key pairs on the client computer.
You then copy the public key to the host computer ? (The is the scp command)
You then log on to the host computer and append the public key to the user's .ssh/authorized computer and then set the permissions (again, on the host with the server)

It looks to me like you created the keys on the host, exported the public key to the client to /home/user, then you did not login in to the client computer, so when you appended the public key to the authorized keys and set permissions, it happened on the local machine. Never-the-less, if you had logged in to the client for the last steps, the keys would have been backwards -- you could have logged into the guest from the host.

parmegv · 2011-03-01 19:16:18

ewaller wrote:

parmegv wrote:
... I generated it like this:
ssh-keygen -t dsa
scp user@remoteClient.com:~/.ssh/id_dsa.pub ~/.ssh/id_dsa_name.pub
mkdir .ssh
cat ~/.ssh/id_dsa_name.pub >> .ssh/authorized_keys
In order to get privileges correct, I did what it is meant to do:
chmod 700 .ssh
chmod 600 .ssh/*
...
I have personally been tripped up by the wiki. Some clarification:
You generate the key pairs on the client computer.
You then copy the public key to the host computer ? (The is the scp command)
You then log on to the host computer and append the public key to the user's .ssh/authorized computer and then set the permissions (again, on the host with the server)
It looks to me like you created the keys on the host, exported the public key to the client to /home/user, then you did not login in to the client computer, so when you appended the public key to the authorized keys and set permissions, it happened on the local machine. Never-the-less, if you had logged in to the client for the last steps, the keys would have been backwards -- you could have logged into the guest from the host.

I thought I did that, but following your instructions from scratch (removing both .ssh folders) I have not achieved anything.

How can I know if my ISP is blocking port 22?

ewaller · 2011-03-01 19:28:50

How can I know if my ISP is blocking port 22?

debug1: Connecting to serveraddress [serveraddress] port 22.
debug1: Connection established.

I assert you are reaching the other computer.

debug3: Not a RSA1 key file ~/.ssh/id_dsa.
debug2: key_type_from_name: unknown key type '-----BEGIN'

I further assert that the computer at the other end, the one that should have the public key, is trying to parse a private key.

parmegv · 2011-03-01 19:40:50

ewaller wrote:

How can I know if my ISP is blocking port 22?
debug1: Connecting to serveraddress [serveraddress] port 22.
debug1: Connection established.
I assert you are reaching the other computer.
debug3: Not a RSA1 key file ~/.ssh/id_dsa.
debug2: key_type_from_name: unknown key type '-----BEGIN'
I further assert that the computer at the other end, the one that should have the public key, is trying to parse a private key.

So this is a matter of word's meaning?
I have my HOST, to which I want to connect from outside, with only an authorized_keys file containing the CLIENT's public key (the computer I want to connect from, to which I have already ssh'd in order to test my HOST installation.

When I generate the key pair in the client, two files are generated: private and public key. It is said to copy the public key to the host, but I do nothing to the private one (which is protected by a passphrase).

What am I missing?

ewaller · 2011-03-01 20:07:53

Here is a working setup connecting from matrix to odin

ewaller@matrix:~[1] 438 %cat .ssh/id_dsa
-----BEGIN DSA PRIVATE KEY-----
...Redacted...
-----END DSA PRIVATE KEY-----
ewaller@matrix:~ 439 %ssh redacted.com -p443
Last login: Tue Mar  1 11:58:21 2011 from ...Redacted...
ewaller@odin:~ 1001 %cat .ssh/authorized_keys

ssh-dss ...Redacted... ewaller@matrix
ewaller@odin:~ 1002 %

I use port 443 because hotels and internet cafes don't block it.

Can you verify that your key configuration looks like this?

parmegv · 2011-03-01 20:16:26

ewaller wrote:

Here is a working setup connecting from matrix to odin
ewaller@matrix:~[1] 438 %cat .ssh/id_dsa
-----BEGIN DSA PRIVATE KEY-----
...Redacted...
-----END DSA PRIVATE KEY-----
ewaller@matrix:~ 439 %ssh redacted.com -p443
Last login: Tue Mar  1 11:58:21 2011 from ...Redacted...
ewaller@odin:~ 1001 %cat .ssh/authorized_keys

ssh-dss ...Redacted... ewaller@matrix
ewaller@odin:~ 1002 %
I use port 443 because hotels and internet cafes don't block it.
Can you verify that your key configuration looks like this?

It does. Perhaps it's all because I am testing my server from a client that is already serving me as a server.

user1@local$ssh user2@externalSSHServer
user2@externalSSHServer$  cat .ssh/id_dsa
-----BEGIN DSA PRIVATE KEY-----
...
-----END DSA PRIVATE KEY-----
user2@externalSSHServer$ ssh user1@local
... errors ...

And in another tab of gnu screen:

user1@local$sudo /etc/rc.d/sshd_config start
 cat .ssh/authorized_keys
ssh-dss ... user2@externalSSHServer ...

Last edited by parmegv (2011-03-01 20:18:46)

ewaller · 2011-03-01 20:23:40

If you want, could you send me a PM with your IP address so that I can try to ssh to that machine. I don't need or want any credentials -- But I will be able to see if the port is up and what the -vv of the key exchange (which will, of course, fail) ??

ewaller · 2011-03-01 22:10:27

ewaller@odin:~[1] 1002 %ssh -vv ...Redacted...
OpenSSH_5.8p1, OpenSSL 1.0.0d 8 Feb 2011
debug1: Reading configuration data /etc/ssh/ssh_config
debug2: ssh_connect: needpriv 0
debug1: Connecting to ...Redacted... ...Redacted...] port 22.
debug1: Connection established.
debug1: identity file /home/ewaller/.ssh/id_rsa type -1
debug1: identity file /home/ewaller/.ssh/id_rsa-cert type -1
debug1: identity file /home/ewaller/.ssh/id_dsa type -1
debug1: identity file /home/ewaller/.ssh/id_dsa-cert type -1
debug1: identity file /home/ewaller/.ssh/id_ecdsa type -1
debug1: identity file /home/ewaller/.ssh/id_ecdsa-cert type -1
ssh_exchange_identification: Connection closed by remote host
ewaller@odin:~[255] 1003 %
Connection to ...Redacted....com closed.
ewaller@matrix:~[255] 440 %ssh -vv ...Redacted...         
OpenSSH_5.8p1, OpenSSL 1.0.0d 8 Feb 2011
debug1: Reading configuration data /etc/ssh/ssh_config
debug2: ssh_connect: needpriv 0
debug1: Connecting to ...Redacted... [...Redacted...] port 22.
debug1: Connection established.
debug1: identity file /home/ewaller/.ssh/id_rsa type -1
debug1: identity file /home/ewaller/.ssh/id_rsa-cert type -1
debug2: key_type_from_name: unknown key type '-----BEGIN'
debug2: key_type_from_name: unknown key type '-----END'
debug1: identity file /home/ewaller/.ssh/id_dsa type 2
debug1: identity file /home/ewaller/.ssh/id_dsa-cert type -1
debug1: identity file /home/ewaller/.ssh/id_ecdsa type -1
debug1: identity file /home/ewaller/.ssh/id_ecdsa-cert type -1
ssh_exchange_identification: Connection closed by remote host
ewaller@matrix:~[255] 441 %

Okay we are even, now you have logged my addresses too
I can see your server from two different IP addresses. The first one had no keys to offer. The second offered my key, which is worthless for talking to your machine. The second one did identify my key as being a dsa key. Going back to your original post, I see that your key was also identified as a dsa key.

So, I went back to my systems. Here is a verbose dump of my connect:

ewaller@matrix:~[255] 441 %ssh -vv ...Redacted....com -p443
OpenSSH_5.8p1, OpenSSL 1.0.0d 8 Feb 2011
debug1: Reading configuration data /etc/ssh/ssh_config
debug2: ssh_connect: needpriv 0
debug1: Connecting to nowwhat.homelinux.com [...Redacted...] port 443.
debug1: Connection established.
debug1: identity file /home/ewaller/.ssh/id_rsa type -1
debug1: identity file /home/ewaller/.ssh/id_rsa-cert type -1
debug2: key_type_from_name: unknown key type '-----BEGIN'
debug2: key_type_from_name: unknown key type '-----END'
debug1: identity file /home/ewaller/.ssh/id_dsa type 2
debug1: identity file /home/ewaller/.ssh/id_dsa-cert type -1
debug1: identity file /home/ewaller/.ssh/id_ecdsa type -1
debug1: identity file /home/ewaller/.ssh/id_ecdsa-cert type -1
debug1: Remote protocol version 2.0, remote software version OpenSSH_5.8
debug1: match: OpenSSH_5.8 pat OpenSSH*
debug1: Enabling compatibility mode for protocol 2.0
debug1: Local version string SSH-2.0-OpenSSH_5.8
debug2: fd 3 setting O_NONBLOCK
debug1: SSH2_MSG_KEXINIT sent
debug1: SSH2_MSG_KEXINIT received
debug2: kex_parse_kexinit: ecdh-sha2-nistp256,ecdh-sha2-nistp384,ecdh-sha2-nistp521,diffie-hellman-group-exchange-sha256,diffie-hellman-group-exchange-sha1,diffie-hellman-group14-sha1,diffie-hellman-group1-sha1
debug2: kex_parse_kexinit: ecdsa-sha2-nistp256-cert-v01@openssh.com,ecdsa-sha2-nistp384-cert-v01@openssh.com,ecdsa-sha2-nistp521-cert-v01@openssh.com,ecdsa-sha2-nistp256,ecdsa-sha2-nistp384,ecdsa-sha2-nistp521,ssh-rsa-cert-v01@openssh.com,ssh-dss-cert-v01@openssh.com,ssh-rsa-cert-v00@openssh.com,ssh-dss-cert-v00@openssh.com,ssh-rsa,ssh-dss
debug2: kex_parse_kexinit: aes128-ctr,aes192-ctr,aes256-ctr,arcfour256,arcfour128,aes128-cbc,3des-cbc,blowfish-cbc,cast128-cbc,aes192-cbc,aes256-cbc,arcfour,rijndael-cbc@lysator.liu.se
debug2: kex_parse_kexinit: aes128-ctr,aes192-ctr,aes256-ctr,arcfour256,arcfour128,aes128-cbc,3des-cbc,blowfish-cbc,cast128-cbc,aes192-cbc,aes256-cbc,arcfour,rijndael-cbc@lysator.liu.se
debug2: kex_parse_kexinit: hmac-md5,hmac-sha1,umac-64@openssh.com,hmac-ripemd160,hmac-ripemd160@openssh.com,hmac-sha1-96,hmac-md5-96
debug2: kex_parse_kexinit: hmac-md5,hmac-sha1,umac-64@openssh.com,hmac-ripemd160,hmac-ripemd160@openssh.com,hmac-sha1-96,hmac-md5-96
debug2: kex_parse_kexinit: none,zlib@openssh.com,zlib
debug2: kex_parse_kexinit: none,zlib@openssh.com,zlib
debug2: kex_parse_kexinit: 
debug2: kex_parse_kexinit: 
debug2: kex_parse_kexinit: first_kex_follows 0 
debug2: kex_parse_kexinit: reserved 0 
debug2: kex_parse_kexinit: ecdh-sha2-nistp256,ecdh-sha2-nistp384,ecdh-sha2-nistp521,diffie-hellman-group-exchange-sha256,diffie-hellman-group-exchange-sha1,diffie-hellman-group14-sha1,diffie-hellman-group1-sha1
debug2: kex_parse_kexinit: ssh-rsa,ssh-dss,ecdsa-sha2-nistp256
debug2: kex_parse_kexinit: aes128-ctr,aes192-ctr,aes256-ctr,arcfour256,arcfour128,aes128-cbc,3des-cbc,blowfish-cbc,cast128-cbc,aes192-cbc,aes256-cbc,arcfour,rijndael-cbc@lysator.liu.se
debug2: kex_parse_kexinit: aes128-ctr,aes192-ctr,aes256-ctr,arcfour256,arcfour128,aes128-cbc,3des-cbc,blowfish-cbc,cast128-cbc,aes192-cbc,aes256-cbc,arcfour,rijndael-cbc@lysator.liu.se
debug2: kex_parse_kexinit: hmac-md5,hmac-sha1,umac-64@openssh.com,hmac-ripemd160,hmac-ripemd160@openssh.com,hmac-sha1-96,hmac-md5-96
debug2: kex_parse_kexinit: hmac-md5,hmac-sha1,umac-64@openssh.com,hmac-ripemd160,hmac-ripemd160@openssh.com,hmac-sha1-96,hmac-md5-96
debug2: kex_parse_kexinit: none,zlib@openssh.com
debug2: kex_parse_kexinit: none,zlib@openssh.com
debug2: kex_parse_kexinit: 
debug2: kex_parse_kexinit: 
debug2: kex_parse_kexinit: first_kex_follows 0 
debug2: kex_parse_kexinit: reserved 0 
debug2: mac_setup: found hmac-md5
debug1: kex: server->client aes128-ctr hmac-md5 none
debug2: mac_setup: found hmac-md5
debug1: kex: client->server aes128-ctr hmac-md5 none
debug1: sending SSH2_MSG_KEX_ECDH_INIT
debug1: expecting SSH2_MSG_KEX_ECDH_REPLY
debug1: Server host key: ECDSA ...Redacted...
debug1: Host '[...Redacted....com]:443' is known and matches the ECDSA host key.
debug1: Found key in /home/ewaller/.ssh/known_hosts:2
debug1: ssh_ecdsa_verify: signature correct
debug2: kex_derive_keys
debug2: set_newkeys: mode 1
debug1: SSH2_MSG_NEWKEYS sent
debug1: expecting SSH2_MSG_NEWKEYS
debug2: set_newkeys: mode 0
debug1: SSH2_MSG_NEWKEYS received
debug1: Roaming not allowed by server
debug1: SSH2_MSG_SERVICE_REQUEST sent
debug2: service_accept: ssh-userauth
debug1: SSH2_MSG_SERVICE_ACCEPT received
debug2: key: /home/ewaller/.ssh/id_rsa ((nil))
debug2: key: /home/ewaller/.ssh/id_dsa (0x85862c8)
debug2: key: /home/ewaller/.ssh/id_ecdsa ((nil))
debug1: Authentications that can continue: publickey,password
debug1: Next authentication method: publickey
debug1: Trying private key: /home/ewaller/.ssh/id_rsa
debug1: Offering DSA public key: /home/ewaller/.ssh/id_dsa
debug2: we sent a publickey packet, wait for reply
debug1: Server accepts key: pkalg ssh-dss blen 435
debug2: input_userauth_pk_ok: fp ec:a0:...Redacted...
debug1: read PEM private key done: type DSA
debug1: Authentication succeeded (publickey).
Authenticated to nowwhat.homelinux.com ([...Redacted...]:443).
debug1: channel 0: new [client-session]
debug2: channel 0: send open
debug1: Requesting no-more-sessions@openssh.com
debug1: Entering interactive session.
debug2: callback start
debug2: client_session2_setup: id 0
debug2: fd 3 setting TCP_NODELAY
debug2: channel 0: request pty-req confirm 1
debug2: channel 0: request shell confirm 1
debug2: callback done
debug2: channel 0: open confirm rwindow 0 rmax 32768
debug2: channel_input_status_confirm: type 99 id 0
debug2: PTY allocation request accepted on channel 0
debug2: channel 0: rcvd adjust 2097152
debug2: channel_input_status_confirm: type 99 id 0
debug2: shell request accepted on channel 0
Last login: Tue Mar  1 12:01:09 2011 from ...Redacted...
ewaller@odin:~ 1001 %

So... I was right your port is open. I was wrong about the Begin, End tags. They are coming from the private key file. Let me ponder this for a bit.

Last edited by ewaller (2011-03-01 22:12:24)

parmegv · 2011-03-04 06:48:37

ewaller wrote:

So... I was right your port is open. I was wrong about the Begin, End tags. They are coming from the private key file. Let me ponder this for a bit.

Anybody has an idea? ewaller, have you thought anything? I got stucked precisely there :s

ewaller · 2011-03-04 07:43:15

Well, I have been pondering it

I've two lines of thought left.

1) Was this a clean installation? I have not seen /etc/ssh/blacklist.* or /usr/share/ssh/blacklist* on my Arch systems. Did you migrate from another distro leaving these parts of the file system? I assumed these are both Arch Linux systems. I ask because your posts demonstrate a good understanding of Linux (newbes don't often use screen) but your post count is low -- Signs you have migrated from elsewhere. (Welcome, by the way)

2) I always tend to use the same user name on both systems. It looks like you have the user1 / user2 stuff set correctly, but double check that.

Lastly, Is your system fully up to date?
I am quickly running out of altitude, airspeed and ideas all at once.

parmegv · 2011-03-05 01:26:47

ewaller wrote:

Well, I have been pondering it
I've two lines of thought left.
1) Was this a clean installation? I have not seen /etc/ssh/blacklist.* or /usr/share/ssh/blacklist* on my Arch systems. Did you migrate from another distro leaving these parts of the file system? I assumed these are both Arch Linux systems. I ask because your posts demonstrate a good understanding of Linux (newbes don't often use screen) but your post count is low -- Signs you have migrated from elsewhere. (Welcome, by the way)

It was a clean installation, actually. I did migrate from another one, I have tried several ones along these years, but always working from a completely new system fs. I will remove those files, and try again. EDIT: I have no files like that! And the other system, the one I try to connect from, is Debian.

ewaller wrote:

2) I always tend to use the same user name on both systems. It looks like you have the user1 / user2 stuff set correctly, but double check that.
Lastly, Is your system fully up to date?
I am quickly running out of altitude, airspeed and ideas all at once.

My system is fully up to date, I always update when I'm at the computer. The only thing I think I have to change about user1/user2 is the sshd_config file, in order to let them login. Anything else (assuming of course I try to connect with the correct user at the ssh command) is not considered.

I do not know really why this does not work, but I am a bit tired since I always have a problem with Arch . It lasts long but when I try to get something enhanced (now I also have problems for the console and my language, Spanish) I get no reward. It's a pity, but if I cannot manage with this SSH issue I'll try with Gentoo, which I think I can manage completely on my own, without a system helping/disturbing

Last edited by parmegv (2011-03-05 08:35:22)

Arch Linux

#1 2011-03-01 15:37:26

Setup an SSH server

#2 2011-03-01 15:57:53

Re: Setup an SSH server

#3 2011-03-01 16:04:48

Re: Setup an SSH server

#4 2011-03-01 16:22:48

Re: Setup an SSH server

#5 2011-03-01 17:08:10

Re: Setup an SSH server

#6 2011-03-01 17:29:02

Re: Setup an SSH server

#7 2011-03-01 18:16:59

Re: Setup an SSH server

#8 2011-03-01 18:54:18

Re: Setup an SSH server

#9 2011-03-01 19:16:18

Re: Setup an SSH server

#10 2011-03-01 19:28:50

Re: Setup an SSH server

#11 2011-03-01 19:40:50

Re: Setup an SSH server

#12 2011-03-01 20:07:53

Re: Setup an SSH server

#13 2011-03-01 20:16:26

Re: Setup an SSH server

#14 2011-03-01 20:23:40

Re: Setup an SSH server

#15 2011-03-01 22:10:27

Re: Setup an SSH server

#16 2011-03-04 06:48:37

Re: Setup an SSH server

#17 2011-03-04 07:43:15

Re: Setup an SSH server

#18 2011-03-05 01:26:47

Re: Setup an SSH server

Board footer