Google Groups no longer supports new Usenet posts or subscriptions. Historical content remains viewable.
Dismiss

http://stackoverflow.com/questions/37403396/single-user-only-can-access-over-v2-ssh-rsa-key

39 views
Skip to first unread message

Sri patcha

unread,
May 23, 2016, 10:33:21 PM5/23/16
to
new user only can access SSH connection with RSA key. how enable this in SSHD_CONFIG file.

i tried many ways. do let me know your technique.

Kees Nuyt

unread,
May 24, 2016, 4:41:29 PM5/24/16
to
That's not really a shell problem, but anyway:

PermitEmptyPasswords no
PasswordAuthentication no
ChallengeResponseAuthentication no
IgnoreRhosts yes
RhostsAuthentication no
RhostsRSAAuthentication no
RSAAuthentication yes

# unrelated, but preferred for secure systems:
PermitRootLogin no
AllowGroups <space delimited list of groups you allow>
AllowUsers <space delimited list of users you allow>

# you can even restrict IP ranges:
Match Address 127.0.0.0/8
Match Address 192.168.1.0/24
--
Kees Nuyt

Sri patcha

unread,
May 25, 2016, 2:39:52 AM5/25/16
to
Thanks for your response Kees.

i mad it like Passwd -L user

script " how to login as user and run some script and logout"
can we write this script .. if you have idea . please share some sample to implement

Kees Nuyt

unread,
May 25, 2016, 8:30:41 AM5/25/16
to
On Tue, 24 May 2016 23:39:46 -0700 (PDT), Sri patcha
Don't use password login for that.
Generate a key pair, put the public key in ~/.ssh/authorized_keys
on the server you want to connect to, put the private key in a
file on the client that is used to connect to the server, and use
the ssh -i idenity_file option to point to the private key file,
or use a default file path, like ~/.ssh/id_rsa .
Ideally, the private key should be protected by a password.

References:
man ssh-keygen
man ssh

and search on the web with your favorite search engine.
--
Kees Nuyt

Ian Zimmerman

unread,
May 25, 2016, 2:56:42 PM5/25/16
to
On 2016-05-24 22:40 +0200, Kees Nuyt wrote:

> # unrelated, but preferred for secure systems:
> PermitRootLogin no
> AllowGroups <space delimited list of groups you allow>
> AllowUsers <space delimited list of users you allow>

I'll bite.

What's the value of PermitRootLogin=no? Presumably at least some of the
allowed users have sudo powers.

--
Please *no* private copies of mailing list or newsgroup messages.
Rule 420: All persons more than eight miles high to leave the court.

Kaz Kylheku

unread,
May 25, 2016, 3:59:19 PM5/25/16
to
On 2016-05-25, Ian Zimmerman <i...@buug.org> wrote:
> On 2016-05-24 22:40 +0200, Kees Nuyt wrote:
>
>> # unrelated, but preferred for secure systems:
>> PermitRootLogin no
>> AllowGroups <space delimited list of groups you allow>
>> AllowUsers <space delimited list of users you allow>
>
> I'll bite.
>
> What's the value of PermitRootLogin=no? Presumably at least some of the
> allowed users have sudo powers.

PermitRootLogin no is very similar in spirit to what /etc/securetty
does: prohibiting root login from certain terminals.

The incredible value of this mechanism is that that you can have "G0D"
as a root password, and be sure that no outsiders can (directly)
log in as root even if they happen to guess it.

:)

--
TXR Programming Lanuage: http://nongnu.org/txr
Music DIY Mailing List: http://www.kylheku.com/diy
ADA MP-1 Mailing List: http://www.kylheku.com/mp1

Jim Beard

unread,
May 25, 2016, 8:17:52 PM5/25/16
to
On Wed, 25 May 2016 19:59:11 +0000, Kaz Kylheku wrote:

> On 2016-05-25, Ian Zimmerman <i...@buug.org> wrote:
>> On 2016-05-24 22:40 +0200, Kees Nuyt wrote:
>>
>>> # unrelated, but preferred for secure systems: PermitRootLogin no
>>> AllowGroups <space delimited list of groups you allow>
>>> AllowUsers <space delimited list of users you allow>
>>
>> I'll bite.
>>
>> What's the value of PermitRootLogin=no? Presumably at least some of
>> the allowed users have sudo powers.
>
> PermitRootLogin no is very similar in spirit to what /etc/securetty
> does: prohibiting root login from certain terminals.
>
> The incredible value of this mechanism is that that you can have "G0D"
> as a root password, and be sure that no outsiders can (directly)
> log in as root even if they happen to guess it.

My understanding is, it is possible to have all logins to root saved to a
log that local root himself cannot alter (perhaps on another machine on a
network). That allows identification by inspection of the log of what
user(s) used su or sudo to gain acess to root.

Cheers!

jim b.

--
UNIX is not user-unfriendly; it merely
expects users to be computer-friendly.

Kaz Kylheku

unread,
May 25, 2016, 8:44:07 PM5/25/16
to
And there will be plenty of time to read that log in hard copy
while standing in line in the IT security employment center.

Which of these 19,573 logins to root fucked everything? Oh, which ...

:)

Kees Nuyt

unread,
May 26, 2016, 8:53:07 AM5/26/16
to
On Wed, 25 May 2016 11:55:01 -0700, Ian Zimmerman <i...@buug.org>
wrote:

>On 2016-05-24 22:40 +0200, Kees Nuyt wrote:
>
>> # unrelated, but preferred for secure systems:
>> PermitRootLogin no
>> AllowGroups <space delimited list of groups you allow>
>> AllowUsers <space delimited list of users you allow>
>
> I'll bite.
>
> What's the value of PermitRootLogin=no?
> Presumably at least some of the
> allowed users have sudo powers.

The main reason is, auditors will complain if you don't have it ;)
--
Kees Nuyt

Ian Zimmerman

unread,
May 26, 2016, 12:01:47 PM5/26/16
to
On 2016-05-26 00:14 -0000, Jim Beard wrote:

> On Wed, 25 May 2016 19:59:11 +0000, Kaz Kylheku wrote:
>
> > On 2016-05-25, Ian Zimmerman <i...@buug.org> wrote:
> >> On 2016-05-24 22:40 +0200, Kees Nuyt wrote:
> >>
> >>> AllowGroups <space delimited list of groups you allow>
> >>> AllowUsers <space delimited list of users you allow>
> >>
> >> What's the value of PermitRootLogin=no? Presumably at least some of
> >> the allowed users have sudo powers.
> >
> > PermitRootLogin no is very similar in spirit to what /etc/securetty
> > does: prohibiting root login from certain terminals.
> >
> > The incredible value of this mechanism is that that you can have "G0D"
> > as a root password, and be sure that no outsiders can (directly)
> > log in as root even if they happen to guess it.
>
> My understanding is, it is possible to have all logins to root saved to a
> log that local root himself cannot alter (perhaps on another machine on a
> network). That allows identification by inspection of the log of what
> user(s) used su or sudo to gain acess to root.

But isn't the same true for root (or any other) logins via ssh?

I see only one possible advantage: "root" is on every system, unlike
"joe" or "ian". That gives a slowdown of maybe 1 order of magnitude.
Not much, and a roughly commensurate barrier can be put into place by
only allowing root logins on a nonstandard port.

Sri patcha

unread,
May 27, 2016, 1:15:51 AM5/27/16
to
On Tuesday, May 24, 2016 at 1:41:29 PM UTC-7, Kees Nuyt wrote:
runuser user "command"
user should be accessed though RSA. He can use password. passwd -l User is blocking
But user should have super user access in centoS 5.5.
How i can provide the access user to super user in centOS 5.5. i'm adding user to group and visuo file .even still user dont have su access

can you some one suggest.

Kees Nuyt

unread,
May 27, 2016, 5:04:33 AM5/27/16
to
On Thu, 26 May 2016 22:15:48 -0700 (PDT), Sri patcha
A locked user can't login. What is the error message if user
accesses the system?
ssh -v -v -i keyfile us...@host.domain

> But user should have super user access in centoS 5.5.
> How i can provide the access user to super user in centOS 5.5.
> i'm adding user to group and visuo file .even still user dont have su access
>
> can you some one suggest.

man su
man sudo
man visudo
man sudoers
man passwd

As I said before, this not a shell problem,
and it is off-topic in this newsgroup.
--
Kees Nuyt

Chris Elvidge

unread,
May 27, 2016, 10:18:19 AM5/27/16
to
As Kees says, off topic.
But, look at /etc/pam.d/su to enable su without password.


--

Chris Elvidge, England
0 new messages