Steve Harder-Kucera wrote:
> Hello,
>
> I installed ssh but connection is refused when using rlogin. What do I
> need to do to get that up and running.
>
> I'm needing to get another user able to logon to the Linux box on a
> separate user account. That's the correct function of rlogin, right?
>
>
>

Posted Via Usenet.com Premium Usenet Newsgroup Services
----------------------------------------------------------
** SPEED ** RETENTION ** COMPLETION ** ANONYMITY **
----------------------------------------------------------
http://www.usenet.com

Steve Harder-Kucera wrote:
> Hello,
>
> I installed ssh but connection is refused when using rlogin. What do I
> need to do to get that up and running.
>
> I'm needing to get another user able to logon to the Linux box on a
> separate user account. That's the correct function of rlogin, right?
>
>
>
if the user is going to have a terminal session, then

ssh your-host -l unix-account-name -p port-number

should get you in.

The -p is only needed if the sshd listens to a port other than 22 (the
default).

Posted Via Usenet.com Premium Usenet Newsgroup Services
----------------------------------------------------------
** SPEED ** RETENTION ** COMPLETION ** ANONYMITY **
----------------------------------------------------------
http://www.usenet.com

Steve Harder-Kucera wrote:

> Hello,
>
> I installed ssh but connection is refused when using rlogin. What do I
> need to do to get that up and running.
>
Rlogin is possibly the one protocol that is more insecure than telnet.

> I'm needing to get another user able to logon to the Linux box on a
> separate user account. That's the correct function of rlogin, right?
>
>
>

You need to make sure that the other account is set up on the SSH server
first.
One of the other replies to your message has the command to connect your
SSH server.

Bruce S.

--
Replace the by by blueyonder.

On Sat, 08 Sep 2007 23:27:00 +0000, Bruce Stewart wrote (Brilliantly I
might add):

> Rlogin is possibly the one protocol that is more insecure than telnet.

I would be using this on my local network only. Does that make the
security issue less of a problem?

Otherwise, what is the best way to allow other users on my network to open
individual sessions with a graphical interface?

--
Mutant Bluegrass That Rocks
http://www.thepickadillos.com

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On 09 Sep 2007 01:52:49 GMT,
Steve Harder-Kucera wrote:
> On Sat, 08 Sep 2007 23:27:00 +0000, Bruce Stewart wrote (Brilliantly I
> might add):
>
>> Rlogin is possibly the one protocol that is more insecure than telnet.
>
> I would be using this on my local network only. Does that make the
> security issue less of a problem?
>
> Otherwise, what is the best way to allow other users on my network to open
> individual sessions with a graphical interface?
>

ssh -X username@remotehost

the -X will export the X protocol via ssh.

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.6 (GNU/Linux)

iD8DBQFG45wYd90bcYOAWPYRAmZfAKDCfXgWrl2diR7YeXxYSS G2NJ3qNgCg6bLg
y4qnJoP4bF3QqFKsiloc8rw=
=Egvb
-----END PGP SIGNATURE-----

--
Jim Richardson http://www.eskimo.com/~warlock
As practiced by computer science, the study of programming is an unholy
mixture of mathematics, literary criticism, and folklore.
-- B. A. Sheil, 1981

On 09 Sep 2007 01:52:49 GMT, Steve Harder-Kucera wrote:
>
> I would be using this on my local network only. Does that make the
> security issue less of a problem?

If there is a Micro$not node running on the LAN, you want to consider
treating the LAN as hostile as the Internet.

Can you guaranteed no one can run a sniffer and catch your login and
password as that data passes accross the LAN.

On Sat, 08 Sep 2007 20:01:50 +0000, Steve Harder-Kucera wrote:

> Hello,
>
> I installed ssh but connection is refused when using rlogin. What do I
> need to do to get that up and running.
>
> I'm needing to get another user able to logon to the Linux box on a
> separate user account. That's the correct function of rlogin, right?

Rlogin is obsolete, ssh performs all of it's functions and more. To
connect to a box with ssh on it all you have to do is

ssh system_name
(where the system_name is the IP address or resolves to the IP address).

You can either use password authentication or RSA authentication. In my
opinion you should always use RSA authentication because it's more secure
and it's easier (i.e. if you've set up RSA authentication you can not
only login to the machine without a password, you can also do scp, rsync,
and remote execution, without a password).

To set up RSA authentication you'll need to put the public keys of the
authorized users into either /etc/ssh/authorized_keys or ~/.ssh/
authorized_keys depending on how you set up ssh.

The easiest way to set up ssh is to use webmin, http://www.webmin.com.
The ssh module in webmin is incredibly easy to use, it will layout all of
the ssh options in front of you so you can set it up without having to
know anything about ssh.

General Schvantzkoph, on 09/09/2007 02:00 PM said:
>
> Rlogin is obsolete, ssh performs all of it's functions and more. To
> connect to a box with ssh on it all you have to do is
>
> ssh system_name (where the system_name is the IP address or resolves
> to the IP address).
>
> You can either use password authentication or RSA authentication. In
> my opinion you should always use RSA authentication because it's more
> secure and it's easier (i.e. if you've set up RSA authentication you
> can not only login to the machine without a password, you can also do
> scp, rsync, and remote execution, without a password).
>

Indeed. You can also diable password-based authentication completely on
the SSH server. If your SSH server is Internet-facing, this is actually
something that I would completely recommend. I have run a server on the
Internet for a while now, and I am finding that getting people to pick
strong enough passwords to keep baddies out is next to impossible to do.
However, if you make them use PKI authentication, like using RSA keys,
you significantly reduce the chance that the SSH server is going to be
compromised through a brute-force password attack.

I don't know what the average Internet server endures as far as getting
these attacks, but I know that the attempt is made on my server at least
weekly. Now that password authentication is disabled completely,
though, the chances of compromise are lower. I don't doubt for a minute
though that these same bot networks that do portscans and SSH attacks
also have enough machines to look for private keys transmitted in the
clear, and so they probably can compromise a key-only server if they get
the right key.

-- Mike

--
Michael B. Trausch http://www.trausch.us/
Pidgin 2.1.1 and plugins for Ubuntu Feisty!
(And Thunderbird 2.0.0.6, too!) http://www.trausch.us/pidgin

On 09 Sep 2007, in the Usenet newsgroup alt.os.linux.ubuntu, in article
<46e351f1$0$27170$742ec2ed@news.sonic.net>, Steve Harder-Kucera wrote:

>On Sat, 08 Sep 2007 23:27:00 +0000, Bruce Stewart wrote (Brilliantly I
>might add):
>
>> Rlogin is possibly the one protocol that is more insecure than telnet.

I dunno - there are a whole bunch of the Berkeley 'r' commands that can
be major security disasters - care to try 'rsh'? ;-)

>I would be using this on my local network only. Does that make the
>security issue less of a problem?

The reason these older network protocols (rlogin, telnet, ftp, even such
things as pop3) are a problem is that they run unencrypted over the
network. (rsh is worse - in that authentication is based solely on
username and IP address.) The original Ethernet networking is a party
line telephone, where everyone on the wire can listen in to the
conversation which includes username and password. Modern 'switched'
networks are somewhat less prone to packet sniffing, but are in no way
_immune_ from sniffers located at "the right" place (or from a network
administrator like me who has the 'keys' to the switch as part of my job).

Do you explicitly trust EVERYONE who may be able to access those packets?
Most people don't want to take the risk, which is why the Secure Sockets
Layer stuff was developed.

>Otherwise, what is the best way to allow other users on my network to
>open individual sessions with a graphical interface?

To do what? What kind of session?

Old guy

On Sun, 09 Sep 2007 14:11:28 -0400, Michael Trausch wrote:

> General Schvantzkoph, on 09/09/2007 02:00 PM said:
>>
>> Rlogin is obsolete, ssh performs all of it's functions and more. To
>> connect to a box with ssh on it all you have to do is
>>
>> ssh system_name (where the system_name is the IP address or resolves to
>> the IP address).
>>
>> You can either use password authentication or RSA authentication. In my
>> opinion you should always use RSA authentication because it's more
>> secure and it's easier (i.e. if you've set up RSA authentication you
>> can not only login to the machine without a password, you can also do
>> scp, rsync, and remote execution, without a password).
>>
>>
> Indeed. You can also diable password-based authentication completely on
> the SSH server. If your SSH server is Internet-facing, this is actually
> something that I would completely recommend. I have run a server on the
> Internet for a while now, and I am finding that getting people to pick
> strong enough passwords to keep baddies out is next to impossible to do.
> However, if you make them use PKI authentication, like using RSA keys,
> you significantly reduce the chance that the SSH server is going to be
> compromised through a brute-force password attack.
>
> I don't know what the average Internet server endures as far as getting
> these attacks, but I know that the attempt is made on my server at least
> weekly. Now that password authentication is disabled completely,
> though, the chances of compromise are lower. I don't doubt for a minute
> though that these same bot networks that do portscans and SSH attacks
> also have enough machines to look for private keys transmitted in the
> clear, and so they probably can compromise a key-only server if they get
> the right key.
>
> -- Mike

The whole idea of public key encryption is that it doesn't matter if
someone intercepts the public key, it's not possible to derive the
private key (which is never sent) from the public key. Breaking RSA is
beyond the capabilities of current computers. I suppose the NSA might
have figured out a way to break it, if they have they aren't telling, but
you can be assured that no hacker has the ability to break it.

I get port scanned about once a day. One way to avoid them is to put ssh
on a non-standard port. The scanners only attack port 22 so if you use a
different port they won't find you. If you require RSA authentication
they won't be successful but it's less annoying if they don't find you at
all.

General Schvantzkoph, on 09/09/2007 09:33 PM said:
>>
>> I don't know what the average Internet server endures as far as getting
>> these attacks, but I know that the attempt is made on my server at least
>> weekly. Now that password authentication is disabled completely,
>> though, the chances of compromise are lower. I don't doubt for a minute
>> though that these same bot networks that do portscans and SSH attacks
>> also have enough machines to look for private keys transmitted in the
>> clear, and so they probably can compromise a key-only server if they get
>> the right key.
>>
>> -- Mike
>
> The whole idea of public key encryption is that it doesn't matter if
> someone intercepts the public key, it's not possible to derive the
> private key (which is never sent) from the public key. Breaking RSA is
> beyond the capabilities of current computers. I suppose the NSA might
> have figured out a way to break it, if they have they aren't telling, but
> you can be assured that no hacker has the ability to break it.
>

I am well aware of that. That is why I said that they probably look for
private keys that are transmitted in the clear. A public key would be
useless to them. Once the private key is intercepted, though, it's game
over.

>
> I get port scanned about once a day. One way to avoid them is to put ssh
> on a non-standard port. The scanners only attack port 22 so if you use a
> different port they won't find you. If you require RSA authentication
> they won't be successful but it's less annoying if they don't find you at
> all.
>

Moving from 22 will not hide you from a port scan. It will hide you
from bots that are too stupid to hit you with a port scan, though.

-- Mike

--
Michael B. Trausch http://www.trausch.us/
Pidgin 2.1.1 and plugins for Ubuntu Feisty!
(And Thunderbird 2.0.0.6, too!) http://www.trausch.us/pidgin

On 9 Sep 2007 18:00:01 GMT
General Schvantzkoph wrote:

> The easiest way to set up ssh is to use webmin, http://www.webmin.com.

I've never used this tool before, but downloaded it to give it a whirl.
It is incredibly powerful, and manages just about anything you can
imagine on the machine, and the network.

I'll have to play around with it more, but thanks for the tip!

--
Joe - Registered Linux User #449481

"Hate is baggage, life is too short to go around pissed off all the
time..."
- Danny, American History X

>
> Moving from 22 will not hide you from a port scan. It will hide you
> from bots that are too stupid to hit you with a port scan, though.
>
> -- Mike

Fortunately those bots are the only thing that is going to scan most
people's systems. Unless your site is important enough to attract a
focused attack the only thing that will ever scan your site is a dumb bot
that will only probe standard ports. My point about using a non-standard
port is that it will clean up your /var/log/messages file. I have two ssh
servers, one for my customers which is on port 22, and one for my partner
and me which is on a high port. The one on port 22 is scanned at least
once a day, sometimes more, the one on the high port has never been
scanned. BTW the reason my customer server is on port 22 is because I've
found that large company firewalls won't allow an ssh connection to a non-
standard port, I've had several customers that couldn't access ssh on
ports other than 22.

On 10 Sep 2007, in the Usenet newsgroup alt.os.linux.ubuntu, in article
, General Schvantzkoph wrote:

>> Moving from 22 will not hide you from a port scan. It will hide you
>> from bots that are too stupid to hit you with a port scan, though.

Most port scans use something along the lines of nmap. Ever looked at
what nmap scans? Look at the '-p ' option on the nmap
man page.

>Fortunately those bots are the only thing that is going to scan most
>people's systems.

I also see the occasional real live skript kiddiez - you can tell them
because of the typing mistakes they make.

>My point about using a non-standard port is that it will clean up your
>/var/log/messages file.

Agree

>BTW the reason my customer server is on port 22 is because I've found
>that large company firewalls won't allow an ssh connection to a non-
>standard port, I've had several customers that couldn't access ssh on
>ports other than 22.

I've seen that mentioned before (and I suspect most of the previous
sightings of this statement are from you), but I haven't seen statements
from company firewall administrators. Firewall rules rarely can tell if
a connection is encrypted or not. What I have seen is rules that block
port ranges - encrypted or not. Some companies (ours is one) block
access to all residential IP ranges.

Old guy

Moe Trin wrote:

> >My point about using a non-standard port is that it will clean up
> >your /var/log/messages file.
>
> Agree

It may or may not. I've set up or administered hundreds of SSH servers
over the years and seen it go both ways. It's certainly not any
guarantee at all, and if you're depending on nonstandard port
assignment rather securing the daemon you're being foolish indeed.
OTOH, if your server is secure and properly managed there's absolutely
no reason to waste time and effort moving it to a nonstandard port.

Disable root log in always, disallow passwords in favor of keys
wherever possible, and "clean up your logs" with something like this...

ACCEPT tcp -- anywhere anywhere tcp dpt:ssh state NEW limit: avg 3/min burst 3

I see on average maybe half a dozen log entries regarding SSH log in
failures every few days with this single directive. And it's
guaranteed to work against the bots when nonstandard port assignments
aren't. In fact, I've seen nonstandard ports hammered on more than
standard ports simply because once they're discovered it's easy to
assume that the administrator in charge of that server might be
clueless and relying on obfuscation rather than brains for security. ;-)